ipsec tunnel problem

[wmaruya]

The situation is:

Pix 506e-----Nokia 330------Linksys VPN Router

I_________________________I

ipsec tunnel

The linksys vpn router is making the connection to the cisco pix. A tunnel does get established but no information is passing through. The nokia 330 is a third party. They use nat and providing me with a private address inside. They also assigned me a public address on the outside of the nokia box too. Just by forwarding anything that comes to the outside of the nokia box to the inside, should I still be able to establish a working and funtional ipsec tunnel? A tunnel is created, but unable to ping the other side of the pix 506e.

Any suggestions?

Thanks in advance.

[Philip D'Ath]

Trying to run site to site IPSec tunnels through NAT is begging for heart ache. Add to that, you have different vendors.

Any chance of doing this a different way?

[wmaruya]

Then connection between the Linksys and the Nokia is a free connection. I think that is the problem. But it is free. If I can't get this working by next week I will need to get my own connection.

Thanks

[gfullage]

As long as the Nokia has a static one-to-one mapping for the PIX address, and the LinkSys has that NAT'd address as it's IPSec peer, AND you're only doing ESP and not AH, then you should be fine.

Is the Nokia doing any firewalling at all? Make sure you're allowing UDP port 500 (ISAKMP) and IP Protocol 50 (ESP) through it. Remember that the tunnel is built with ISAKMP packets, so they're obviously getting through OK, but then all data is sent in ESP packets, so they may be being blocked somewhere.

Have you also made sure the encrypted packets are NOT NAT'd by the PIX with a "nat (inside) 0 ..." statement that matches your crypto ACL traffic?

Are you able to check the stats on both the LinkSys and the PIX after you do a ping and see if either device is sending and/or receiving encrypted packets? Use the "sho cry ipsec sa" command on the PIX and look at the packets encap and decap counters. Don't know what the corresponding command is on the LinkSys but it should have something similar. This should give you an indication of where the fault lies.

And last but defintely not least, keep in mind that you won't be able to ping the inside interface of the PIX over the tunnel. You can't ping a PIX interface address when you come in over nother interface, even over a VPN. You'll have to try pinging a host behind the PIX to test this properly, but make sure that host has a default route pointing to the PIX inside interface.