Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

VPN Client to PIX. Can ping from inside to client, but not client to inside

I have set up a PIX 515 as a VPN server. Tunnel comes up fine, client is receiving an IP address from the pool. I can ping from an internal host to the client. When I try to ping from the client to an internal host I am not getting the ping replies back at host. When I run a debug icmp trace on the PIX it shows that pings are making it to the internal host but the replies being blocked at the PIX. This has to be a simple fix, except I have pulled my hair out trying to figure out what the fix is.

Here's a copy of the PIX config:

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password eFD4A0mrvsMPvdOj encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

hostname PIX

fixup protocol ftp 21

fixup protocol http 80

fixup protocol h323 1720

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol sip 5060

fixup protocol skinny 2000

names

access-list 100 permit ip 172.16.1.0 255.255.255.0 192.168.1.0 255.255.255.0

access-list 100 permit icmp any any echo-reply

access-list 100 permit icmp any any time-exceeded

access-list 100 permit icmp any any unreachable

pager lines 24

logging on

logging trap 2

logging host inside 192.168.1.3

interface ethernet0 auto

interface ethernet1 auto

mtu outside 1500

mtu inside 1500

ip address outside X.X.X.X X.X.X.X 255.255.255.0

ip address inside 192.168.1.1 255.255.255.0

ip local pool CLIENTPOOL 172.16.1.10-172.16.1.19

pdm history enable

arp timeout 14400

access-group 100 in interface outside

global (outside) 1 interface

nat (inside) 0 access-list 100

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si

p 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

sysopt security fragguard

sysopt connection permit-ipsec

no sysopt route dnat

crypto ipsec transform-set LABTUNNEL esp-des esp-md5-hmac

crypto dynamic-map DYNOMAP 10 set transform-set LABTUNNEL

crypto map VPNPEER 20 ipsec-isakmp dynamic DYNOMAP

crypto map VPNPEER interface outside

isakmp enable outside

isakmp identity address

isakmp client configuration address-pool local CLIENTPOOL outside

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

vpngroup XXXXXXX address-pool CLIENTPOOL

vpngroup XXXXXXX split-tunnel 100

vpngroup XXXXXXX idle-time 1800

vpngroup XXXXXXX password XXXXXX

telnet timeout 5

ssh timeout 5

dhcpd lease 3600

dhcpd ping_timeout 750

terminal width 80

Cryptochecksum:ccf1c85f9a3ccb5fb6349fe1fb231eb6

3 REPLIES
New Member

Re: VPN Client to PIX. Can ping from inside to client, but not c

Eureka!!! I got it!!!! Forgot to add the other access list to allow the internal network to access the ip pool subnet on the client end. I guess that explains why the ICMP replies were not making it back to the client. Duh!!

access-list 100 permit ip 192.168.1.0 255.255.255.0 172.16.1.0 255.255.255.0

I need a cold one!

New Member

Re: VPN Client to PIX. Can ping from inside to client, but not c

Could it be that adding this command to acl 100 eliminated returning traffic from the NAT process? Without it, the packets returning to your remote client were being Nat-ed, which would definitely not work.

dan.kline@networksvcs.net

New Member

Re: VPN Client to PIX. Can ping from inside to client, but not c

Hi

It's good practice to seperate out your acls, having different ones for different jobs, rather than just use one otherwise you can run into problems. For instance, as well as having it for nat bypass and split tunnelling, you have acl 100 inbound on your outside interface, and you dont need to permit the vpn clients' subnet to have inbound access here, nor vice versa, for the vpn to work. For example you should rather configure - for nat bypass:

access-list no_nat permit ip

nat 0 access-list no_nat

for split-tunnelling:

access-list split permit ip

vpngroup split-tunnel split

and if you have need to limit you outbound access via an acl you must permit the traffic here aswell:

access-list acl_in permit ip

access-group acl_in in interface inside

Regards

Kev

83
Views
0
Helpful
3
Replies