Getting the hang of PIX OS, just one question

millworx

So I've spent this lovely holiday weekend playing around and getting the hang of PIX OS. got site to site VPNs working great. Now I am getting around to remote access VPN's.

The PIX is running and I can ping out from the pix to the outside. And I can connect to the PIX from Cisco VPN Client no problem.

Heres the issue's. PC's connected to the switch connected to the inside interface cannot ping out to external hosts. (google, yahoo, etc.)

Second issue. WHen I connect to the PIX via Cisco VPN client on my laptop I get an IP from the PIX but I cannot ping internal PCs like the webserver ,etc. I do have an access list set that should allow it, but I get nothing.

Here is my config, I'm sure it's something simple.

PIX Version 7.1(2) 
!
hostname pixfirewall
domain-name default.domain.invalid
enable password 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0
 nameif outside
 security-level 0
 ip address 1.1.1.2 255.255.255.0 
!
interface Ethernet1
 nameif inside
 security-level 100
 ip address 172.16.1.1 255.255.255.0 
!
interface Ethernet2
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Ethernet3
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Ethernet4
 shutdown
 no nameif
 no security-level
 no ip address
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
dns server-group DefaultDNS
 domain-name default.domain.invalid
access-list 120 extended permit ip 172.16.1.0 255.255.255.0 10.1.1.0 255.255.255.0 
access-list 101 extended permit ip 172.16.1.0 255.255.255.0 10.1.1.0 255.255.255.0 
pager lines 24
mtu outside 1500
mtu inside 1500
ip local pool ippool 10.1.1.11-10.1.1.21 mask 255.255.255.0
no failover
icmp permit any outside
icmp permit any inside
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list 101
nat (inside) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
group-policy vpnclient internal
group-policy vpnclient attributes
 vpn-idle-timeout 30
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value 120
username cisco password ffIRPGpDSOJh9YLq encrypted privilege 15
username jasonm password L8IZ1O/aBRhyJBxq encrypted privilege 15
http server enable
http 192.168.2.100 255.255.255.255 outside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set vpnset esp-3des esp-sha-hmac 
crypto dynamic-map dynmap 10 set transform-set vpnset
crypto dynamic-map dynmap 10 set reverse-route
crypto map myvpn 20 ipsec-isakmp dynamic dynmap
crypto map myvpn interface outside
isakmp identity address 
isakmp enable outside
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
isakmp nat-traversal  20
tunnel-group vpnclient type ipsec-ra
tunnel-group vpnclient general-attributes
 address-pool ippool
 default-group-policy vpnclient
tunnel-group vpnclient ipsec-attributes
 pre-shared-key *
telnet timeout 5
ssh timeout 5
console timeout 0

johnwest43

I ll have to dig deeper on the vpn issue but i believe the reason you cant ping google.com from inside is. all ICMP messages are blocked by the pix by default from outside to inside. You will have to configure an ACL that allows at a minimum echo-replies In the outside interface. I usually write an icmp object group that includes echo-reply, time exceeded and unreachable. Then reference it in an ACL and then apply it to the outside interface. (in interface outside). You can also just use a separate acl for each type of ICMP message you want to allow into your network.

this is just a maybe on the VPN issue....

crypto dynamic-map dyn-map 10 match address ACL55
access-list ACL55 permit ip any 10.1.1.0 255.255.255.0

this is just a guess , i am running 6.3 at home right now and 8.1 at work but at work we use ssl so i don't have easy vpn setup at work.

millworx

johnwest43 wrote: »

I ll have to dig deeper on the vpn issue but i believe the reason you cant ping google.com from inside is. all ICMP messages are blocked by the pix by default from outside to inside. You will have to configure an ACL that allows at a minimum echo-replies In the outside interface. I usually write an icmp object group that includes echo-reply, time exceeded and unreachable. Then reference it in an ACL and then apply it to the outside interface. (in interface outside). You can also just use a separate acl for each type of ICMP message you want to allow into your network.

this is just a maybe on the VPN issue....

crypto dynamic-map dyn-map 10 match address ACL55
access-list ACL55 permit ip any 10.1.1.0 255.255.255.0

this is just a guess , i am running 6.3 at home right now and 8.1 at work but at work we use ssl so i don't have easy vpn setup at work.

I added and applied the access-list to the dynamic map. no change
Maybe its a bug with GNS3. I've gone over every configuration on cisco and this looks correct.

millworx

Im starting to think it may be a routing issue, because when my client is connected via VPN to the PIX im trying to ping internal resources i.e 172.16.1.100 but I get a destination host unreachable from my local router. So its not sending traffic destined for internal hosts through the VPN tunnel

issuing a route print on my computer i see no route for 172.16.1.0.

So still a little lost. Manually setting up a hosts file on all the laptops is not an option. It should be easier than this.... I thought "crypto dynamic-map dynmap 10 set reverse-route" would have taken care of this.

Also issueing a show route on the pix I do see a route 10.1.1.11 255.255.255.255 in the routing table so the PIX does know the route to the host connected. But the host doesn't know the way back.

Then again I may have everything right and this could be a GNS3 bug? thoughts?