PIX: Ping VPN host from inside network

I'm trying to enable the inside network to talk to VPN clients and vice-versa on PIX 7.2 code. I'm using PAT and have verified that outbound translation is working. I can ping from my inside

192.168.6.0/24 subnet to external hosts. I also have setup remote VPN and have verified that the clients can authenticate and establish a VPN session. However, I can't get the inside network (192.168.6.0/24) to ping hosts in the vpn subnet pool (192.168.24.0/24) or vice-versa. When I initiate a ping from 192.168.24.1 to 192.168.6.100, I get a Destination Net Unreachable response from some router along the path.

I then did an ICMP capture to see what was going on. This capture shows a successful ping to 4.2.2.2 and then a shows an echo request but no response from 192.168.24.1 (vpn client): 7: 19:31:58.288376 192.168.6.100 > 4.2.2.2: icmp: echo request 8: 19:31:58.316054 4.2.2.2 > 192.168.6.100: icmp: echo reply 11: 19:32:05.340283 192.168.6.100 > 192.168.24.1: icmp: echo request 12: 19:32:10.410653 192.168.6.100 > 192.168.24.1: icmp: echo request 13: 19:32:15.910261 192.168.6.100 > 192.168.24.1: icmp: echo request

The same capture applied to the outside interface shows pings heading out but not coming back: 1: 19:32:59.907225 192.168.6.100 > 192.168.24.1: icmp: echo request 2: 19:33:05.406915 192.168.6.100 > 192.168.24.1: icmp: echo request

Logs shows: %PIX-6-302020: Built ICMP connection for faddr 192.168.24.1/0 gaddr

192.168.6.10 0/512 laddr 192.168.6.100/512 %PIX-6-302021: Teardown ICMP connection for faddr 192.168.24.1/0 gaddr 192.168.6 .100/512 laddr 192.168.6.100/512

Here's a sample of my config:

PIX Version 7.2(1) (note I will be upgrading later from 7.2(1)) ! interface Ethernet0 nameif outside security-level 0 ip address 10.10.10.1 255.255.255.240 (IP made up of course) ! interface Ethernet1 nameif inside security-level 100 ip address 192.168.6.1 255.255.255.0 ! access-list TEST_splitTunnelAcl standard permit any access-list inside_nat0_outbound extended permit ip any 192.168.24.0

255.255.255.0 access-list outside_cryptomap extended permit ip any 192.168.24.0 255.255.255.0 access-list inside_nat_outbound extended permit ip any any access-list outside_access_in extended permit icmp any any echo-reply access-list test extended permit icmp any any ip local pool MFPOOL 192.168.24.1-192.168.24.254 mask 255.255.255.0 icmp permit any inside icmp permit any echo-reply outside global (outside) 1 interface nat (inside) 0 access-list inside_nat0_outbound nat (inside) 1 access-list inside_nat_outbound access-group outside_access_in in interface outside group-policy TEST internal group-policy TEST attributes vpn-tunnel-protocol IPSec split-tunnel-policy tunnelspecified split-tunnel-network-list value TEST_splitTunnelAcl default-domain value TEST.com crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA crypto map outside_map 20 ipsec-isakmp dynamic outside_dyn_map crypto map outside_map interface outside crypto isakmp enable outside crypto isakmp policy 10 authentication pre-share encryption aes-192 hash sha group 5 lifetime 86400 crypto isakmp policy 65535 authentication pre-share encryption 3des hash sha group 2 lifetime 86400 tunnel-group TEST type ipsec-ra tunnel-group TEST general-attributes address-pool MFPOOL default-group-policy TEST tunnel-group TEST ipsec-attributes pre-shared-key *
Reply to
Jeff
Loading thread data ...

Jsut realized something. In the capture I ran against the outside interface it shows the private IP. Shouldn't this be the external interface of the PIX? It appears that maybe it isn't actually getting translated, leaves the pix wiht 192.168.6.100, and then the destination doesn't know where to respond to (hence the dest net unreachable message).

1: 19:32:59.907225 192.168.6.100 > 192.168.24.1: icmp: echo request 2: 19:33:05.406915 192.168.6.100 > 192.168.24.1: icmp: echo request
Reply to
Jeff

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.