Hi gents as some of you know I'm still figthing with vpn client in one of my companies, it seems I found some things in the client log, and I compare the config with one of vpn that work and it seems the only thing left is nat-traversal. Is nat traversal necesary when you have an ip address out of the inside ip range, and you have a no_nat_acl for the vpn tunneling? Can nat traversal give me problems with the tunnels already working? Thanks for your consideration, I'm quite new in this issues and I hope I can do with a little of your help.
The nat-traversal has nothing to do with your IP's or where it sits in the range and has nothing to do with your other VPN tunnels. Nat-Traversal tells the Pix to allow remote VPN users that are behind a pat'd address which protocol to use and if enabled on the Pix (or concentrator) is negotiated when the client connects. You can turn it on anytime and will not affect any users or other tunnels, the Pix command is "isakmp nat-traversal 20"
It has been 6+ months since I looked at the specificiations, so I might be misremembering, but if I recall correctly then there is a case in which enabling nat-traversal can interfere with existing tunnels (the next time they are negotiated.)
If I recall correctly, nat-traversal negotiation involves sending a trial packet with a known source port of UDP 4500, to a known destination port of UDP 4500. If the remote end sees the source port as something other than UDP 4500 then it knows that PAT has taken place, and it informs the sender to encapsulate ESP and AH packets within UDP. The encapsulation will have a random source port and a fixed destination port of UDP 4500 on the receiving security gateway.
This process can result in a non-functional tunnel in the instance where the filters or firewalls inbetween the two endpoints allow packets with UDP 4500 source and UDP 4500 destination, but do not allow packets with random UDP source and UDP 4500 destination, but would still allow ESP packets. The failure situation pretty much requires policy-based routing to be taking place. It would be difficult for this scenario to pop up when the existing tunnel uses AH and is functional, but it -could- happen. [Like they say, "You can make software fool-proof, but you can't make software DamnFool-proof."]
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.