VPN Tunnel establised between VPN 4.8 Client and 525 PIX but cannot ping

[michael.george]

When there is no tunnel established, the client can ping all devices locally/remotely. However when the tunnel is established and the client picks up its expected IP address from the pool of addresses, the client can ping neither locally/remotely.

Debug icmp trace on the PIX shows inside devices replying to the client's pings yet the client

does not seem to recieve these replies and shows request timed out.

The VPN client also shows only sent data.

I am guessing there is a routing/natting problem somewhere?

Would really appreciate some help on this? Ask some q's if my problem is too vague.

Many thanks in advance!!

[attrgautam · Accepted solution]

Would it possible to show the config of the PIX with public IP addresses masked ? Some things to be checked

--> ISAKMP Nat traversal

--> Windows firewall

--> syspot permit

[michael.george]

Ok I have taken a lot of the config out and made up some ip addresses to give you the basic idea of what I am trying to do.

A few other things I should point out:-

The PIX also has a VPN tunnel connection with another PIX that is working fine.

The vpn client tunnel intiates but then stops connectivity to anything (Yet a 'show isakmp sa' on the PIX shows the vpn client tunnel is up and running).

When the client is not using the vpn, the client is able to ping the 10.50.50.0 subnet. (I have enabled windows firewall for echo reply and open rules on the PIX)

When there is no VPN active, Natting is required for the 172.16.0.0 range and 6.0.0.0 range but natting is not required for the 10.50.50.0 subnet. (Hence the rules for no natting the 6 and 172 subnet for the vpn pool range)

The purpose for the VPN is to maintain a secure connection but to also access the 6 and 172 subnet on the inside of the PIX.

I am very new to VPN's so I am hopeful I have made a simple error somewhere?

If more info is needed, let me know.

Your help is much appreciated!

P.S. nothing major but a mistake I made in the altered textfile should say:

route inside 10.50.50.0 255.255.255.0 CORESWITCH 1

thanks again!!

[attrgautam]

crypto map southend-statmap client configuration address initiate

crypto map southend-statmap client configuration address respond

Can u add these commands and check.

[michael.george]

Thanks for that. I seem to have it working now :o)

I realised as well I had an internal routing issue which may have been part of the problem.

Just out of interst, I am now seeing encrypted packets sent and received which is great. However when I look under 'windows network connections' and check the cisco VPN adaptor, it shows no packets sent or received and also shows the default gateway as the same ip address as the VPN client IP address. It also has default subnet mask eg for 10 address, it shows 255.0.0.0. Is this normal? It seems to be working ok so I assume so.

Also, since getting the VPN up and running. Although I can access internal servers on the inside network of the PIX eg proxy server to access the internet, I am unable use windows remote desktop.

eg. If my vpn client IP was 10.10.10.10 and I wanted to RDP to the VPN client machine from another pc, one that was at the end of the tunnel (inside interface of the PIX), how would I go about doing this? do I need to tell the inside network where 10.10.10.10 exists and do I even RDP to the VPN client address or should I RDP to the remote LAN address of the VPN client?

Thanks again for your help!!

[attrgautam]

Well You can telnet the IP Picked up by the client but if doesnt work then probably it must be due to some MTU issue on the path (thanks to IPSec header).

Just to know, how did u solve the issue ?

[michael.george]

Hi, sorry about this very late reply, I have not been able to get back to sorting the VPN for a little while as I have been away.

Well I had a comedy of errors really before...

I had route inside for the vpn client pool at one point which I quickly removed.

We also have different 'internet' connections from our site and certain default routes for certain subnets were pointing out to different internet connections and that stopped the vpn client accessing those subnets on the different internet connections. I haven't had time to do testing but I am wondering if I need to add a route on the our core switch basically saying anything on the internal network destined for the vpn client i pool/subnet, head to the PIX that is running the vpn tunnel for that client? Either way, its not a problem as all the devices the vpn clients requires, it can now access.

For the no-nat subnets for access to the internal network, I was configuring the pix using the remote ip's subnet rather than the vpn client's ip pool/subnet. So basically when I got the tunnel finally working, the vpn client could only access certain subnets and not the hidden ones on the inside of the internal network.

Another possible error although I haven't tested if this makes a difference, is I set the vpn client pool/subnet the same as the remote clients ip subnet rather than a unique pool of addresses for the internal network to talk to.

The last silly thing which was what I asked in my last reply, was about Windows Remote Desktop Connection. I just realised yet another very silly mistake and you mentioned it before, Windows firewall.

Now everything seems to work ok, I guess it is normal for the cisco VPN adaptor to show no packets sent or received and also shows the default gateway as the same ip address as the VPN client IP address

with a default mask of either class A. B or C.

It's always easy when you know. Now I just need to give my Boss the good news.

Thanks again for your hints and tips.