From: David Tran (davidtran_mclean@yahoo.com)
Date: Thu May 24 2007 - 07:27:45 ART
Hi,
This explaination is very well written from a person who understands IPSec
with NAT-T. You should be commended for this.
This was the exactly explained to me when I have the following scenario:
R1---Firewall----R2 (R1 and R2 runs IOS 12.2(15)T17
I have a L2L IPSec VPN between R1 and R2 and the Firewall is a Checkpoint
firewall and that I have "crypto ipsec nat-t udp-encapsulation" commands, which
is on by default, on both R1 and R2. For testing purposes, I allow udp/500,
udp/4500 and ESP (proto 50) through the Checkpoint firewall.
Suprisingly, when I run tcpdump on the firewall, I see that the router uses
ESP instead of UDP/4500 (NAT-t). At other times, it uses udp/4500. I sent
the debug on both routers and tcpdump on the checkpoint firewall to Cisco
for analysis but Cisco TAC do not have an answer and that was three months
ago. Things are working so this issue is not a priority for me right now.
In summary, what you said earlier is completely accurate. However, it may not
behave that way in production environments. This is especially true when the
firewall between R1 and R2 is not a Cisco Pix/ASA firewall.
David
pankaj ahuja <networksecurityconsultant@gmail.com> wrote: Hello All,
This is my first post for the group. It looks like there is some confusion
going on regarding NAT Traversal. Here is an explanation as per my
understanding due to my 22 month experience working as a Cisco TAC engineer
for the VPN team :
UDP 500 is what is used for IKE phase 1 negotiation. Lets assume that we're
trying to build a Lan to Lan tunnel between 2 Cisco Devices and we have a
Nat device sitting in line somewhere in between. Now when the negotiation
begins the receiving end peer verifies if the IP address mentioned in the
packet is same as the source IP of the packet received. Which obviously
will be different in case the packet was Natted along the Path. So untill
this NAT broke IPsec functionality and thats where NAT T comes in to
picture.
If both devices are configured to use NAT T. then they choose to use NAT T.
Now NAT T simply encapsulate their packets with another UDP header which is
destined for port 4500. This helps coz now when the encapsulated packet goes
through the NAT device the source IP of the outer encapsulation changes to
the NAT IP, whereas the source IP of the actual packet is still the same IP
thus when the receiving end verifies the IP mentioned in the content of the
packet with the source of packet it will match this time.
The receiving end knows coz both ends had negotiated to use NAT T and thus
when it receives the packet it decapsulates the outer header of the packet
to retrieve the original packet. This way the exchanges occur without
breaking the IPsec functionality.
Please feel free to ask any questions or doubts you may have. Also if you
have anything to add to this.
Pankaj
CCIE Security (Written)
Now will start preparing for LAB.
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART