doubts about nat-traversal

doubts about nat-traversal
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
doubts about nat-traversal Sako 02-06-2006
Posted by Sako on February 6, 2006, 10:24 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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.


Posted by Brian V on February 6, 2006, 12:59 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

> 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"



Posted by Walter Roberson on February 7, 2006, 5:54 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
> 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."]


other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map