10-10-2002 05:44 PM - edited 02-21-2020 12:06 PM
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
10-10-2002 06:22 PM
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!
01-31-2003 02:29 PM
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.
01-31-2003 04:50 PM
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
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide