03-07-2005 03:20 AM - edited 02-21-2020 01:38 PM
Hi All,
I have a PIX 515E. I am trying to connect thorugh cisco VPN client from my laptop to the Firewall.
It connects(creates the tunnel) and gets the IP address from the pool defined in the PIX.Shows the LAN and VPN connectivity icon.But not able to ping any of the machines inside the LAN.
can anybody help.
03-07-2005 03:29 AM
Hi,
PIX handles icmp in rather special way: it denies incoming icmp by default. Will you plese try to configure simple ACL (permit icmp any any) and apply it to your PIX lan interface (in).
Best regards,
Antonin
03-07-2005 04:17 AM
Hi Antonin ,
Thanks for the reply. I will do that but not oply ping but even I tryied to ping,telnet,ftp,tracert and same from the other side too (LAN).
Thanks
vinay
03-07-2005 04:35 AM
Hi,
Then will you please check that you have configured "sysopt connection permit-ipsec" command, static routing and proper ACL.
Should you decide to post your configuration I will be happy to check.
Best regards,
Antonin
03-07-2005 04:36 AM
Hi Vinay,
Check for "sysopt connection permit-ipsec"
and also cehck thr routes on destination firewall, if routing is an issue.
kindly update this post with the PIX config, if possible
regards
aashish C
03-07-2005 05:10 AM
Hi Aashish,
Thanks for the reply.
"sysopt connection permit-ipsec" is already there.
vinay
03-07-2005 06:19 AM
I have seen this issue before, and to resolve it I added an access-list to the inside interface to allow allow icmp echo-replies from the internal network to the VPN pool adresses. When I experienced the issue, I checked the firewall logs which were showing the icmp echo-replies being dropped by access-list applied to the inside interface.
I hope this is helpfull to your situation.
Regards,
Jayson
03-15-2005 07:29 AM
Hi there,
I had that problem once.
The main issue is that i was connecting to the firewall behind a machine performing NAT.
If this is your case, you need to activate the ISAKMP nat-transversal.
Like you, i also was able to establish the VPN tunnel, but no traffic was flowing.
The other possibility is that your crypto access-list is incorrect. The access-list applied to Nat (inside) 0 is misconfigured.
Check those 2 options
Regards
Nuno
03-17-2005 02:09 PM
I have read the replies and I have to say I don't think those are the answers.
Access-Lists should not matter, as you are NOT considering "tunnel traffic" in your External access lists once the tunnel is established.
For instance, once inside the tunnel you can browse a Windows Share, yet your external access-list does not permit TCP 445 or any of the other NetBIOS ports. It works because now that "interesting" traffic has been encrypted and is traversing the tunnel encrypted, external ACL's are no longer applied to the tunnel traffic. It comes and goes unnoticed by the external traffic rules of the PIX. After all, it is no longer external traffic. It is internal.
I set up client VPNs to PIX firewalls all the time and I have never had to use the IPSEC NAT TRAVERSAL command to permit pinging from one client network to the other. Even if the two networks have the same network address.
You have to remember that the PIX issues to the IPSEC client a logical address to use when on the trusted network. This address takes the place of any network addresses on the client for all VPN traffic, therefore conflicts are not possible in the client scenario (although this can be an issue on point to point tunnels).
Normally when I see problems of this nature it is because either
A. The VPN client is being given an address that is on the SAME network as the inside network. (The address should be different than the actual internal network, for instance if your network inside the PIX is 192.168.1.0/24 then make your tunnel traffic 192.168.2.0/24)
B. NAT is being applied to the IP address block assigned to the VPN Client.
This second issue is more common. Network Engineers forget to create an Access List and forget to apply the "NO NAT" or "NAT ZERO" statement to it, which would permit the traffic coming in from the tunnel to bypass NAT.You don't want to NAT this traffic.
Be sure you have a separate access list created, say access-list 103. Lets also say your internal network addresses are 10.10.10.x., so you apply the 10.20.20.x network to the VPN Clients. Do this using the IP Pool Statement
ip local pool VPNUSERS 10.20.20.1-10.20.20.20
Then you create an access-list to isolate traffic from the tunnel to the inside network.
access-list 102 permit ip 10.10.10.0 255.255.255.0 10.20.20.0 255.255.255.0
Finally apply the NAT ZERO command to the traffic designated for the IPSEC tunnel. This will turn OFF NAT for the traffic coming in through the tunnel using the new internal assigned IP block of 10.20.20.0/24.
nat (inside) 0 access-list 102
Now your Clients using the VPN will come in using a network different from your client network but permitted via access-list direct access to the inside network and will be able to ping any Layer 3 object on your network that responds to ICMP requests.
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