PIX as gateway device & internal routing issues..

[olivea2]

I have a configuration with a PIX 515 running 6.3 code and I can establish a tunnel connection but run into the same problem of not being able to ping any device on internal LAN. I have been over this configuration quite a few time is there something I am missing?

**********************************

access-list fromoutside permit tcp any host X.X.X1 eq smtp

access-list fromoutside permit tcp any host X.X.X2 eq www

access-list fromoutside permit tcp any host X.X.X2 eq pop3

access-list fromoutside permit tcp any host X.X.X2 eq smtp

access-list fromoutside permit tcp any host X.X.X3 eq pcanywhere-data

access-list fromoutside permit tcp any host X.X.X3 eq 5632

access-list fromoutside permit tcp any host X.X.X4 eq 3389

access-list fromoutside permit tcp any host X.X.X3 eq telnet

access-list fromoutside permit udp any any eq isakmp

access-list fromoutside permit udp any any eq 4500

access-list fromoutside permit esp any any

access-list fromoutside permit icmp any any echo-reply

access-list 109 permit ip X.X.X.0.0 255.255.255.0 172.16.1.0 255.255.255.0

ip local pool ippool 172.16.1.0-172.16.1.100

nat (inside) 0 access-list 109

sysopt connection permit-ipsec

crypto ipsec transform-set RTP-TRANSFORM esp-3des esp-md5-hmac

crypto ipsec transform-set Eclipse esp-3des esp-sha-hmac

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

crypto dynamic-map dynmap 50 set transform-set RTP-TRANSFORM

crypto dynamic-map Mobilemap 20 set transform-set RemoteConnect

isakmp identity address

isakmp policy 5 authentication pre-share

isakmp policy 5 encryption des

isakmp policy 5 hash md5

isakmp policy 5 group 2

isakmp policy 5 lifetime 86400

vpngroup 4xclient address-pool ippool

vpngroup 4xclient dns-server X.X.X.0.10

vpngroup 4xclient default-domain testcompany.com

vpngroup 4xclient split-tunnel 109

vpngroup 4xclient idle-time 1800

vpngroup 4xclient password ********

[aacole]

The part you have posted seems ok, a couple of issues spring to mind with this problem.

The first item to check (assuming the tunnel is up)is the tunnel, can you see packets traversing each way over the tunnel?

Look at show crypto ipsec sa, there are packet counters for encrypted and decrypted traffic, decrypted is from the client end.

If your not getting any decrypted packets, then packets are not being received from the client, possibly a split tunnel issue.

If your getting decrypted but no encrypted packets then that would suggest that the target host has no route back to the client pool network via the inside address of the PIX.

Any help?

[olivea2]

Pings initiated from either side are encrypted however that decryption never occurs with the associated peer. So I think you are very correct with the route to the IP pool. I attempted to apply a default route first to inside interface w/no success and next to the default gateway with w/no success.

[jackko]

i guess the acl "fromoutside" is being applied on the outside interface of the router. if so, you need to permit ippool for inbound access.

e.g.

access-list fromoutside permit icmp 172.16.1.0 0.0.0.255

further, the acl 109 seems inaccurate as the mask should be 0.0.0.255 rather than 255.255.255.0.

[olivea2]

The ACL that's being applied is being applied to outside interface on the pix, so the inverse mask I don't believe is applicable to this situation.

[jackko]

of course not, i was thinking about router that has wildcard mask.

so how are you going with the issue after applying the acl?

[thamdani]

Hi ,

Have u applied any access list on the inside interface on the Pix.If yes please make sure that you are allowing the icmp.

Run the following command on the firewall while doing the cotineous ping across the VPN.

debug icmp trace

un all [to stop the debug]

look for the echo-request and echo-rely from-to the host.

If you only see the echo request and no rely then the rely is not coming back from the inside host and you need to make sure uf that inside host has a route back pointing to pix as it was suggested before.

Also i will suggest to add the following command to isakmp .

isakmp nat-traversal 20

This is required if your user is trying to VPN from behind any firewall.

Hope this helps.

Tanveer

[olivea2]

All that time studying CSVPN an I forgot about that. I applied and ACL to the internal interface allowing traffic from the IP Pool to the inside network and I was able to ping all of the devices, in addition after moving my connection behind the firewall the NAT-T command helped even further. Just need to verify but it appears to be resolved at this point. Thanks to everyone for the assistance.