10-27-2010 05:21 AM - edited 02-21-2020 04:56 PM
NAT Traversal performs two tasks: it detects if both ends support NAT-T and NAT-Discovery that detects NAT devices along the transmission path.
NAT-D payload is a hash of the original IP and port. Devices exchange two NAT-D packets, one with source IP and port, and another with destination IP and port. So the receiving device recalculates the hash and compares it with the existing, if they don't match a NAT device exists.
NAT-T encapsulate IPSec packets in UDP packets with port 4500, providing information to PAT device for translation.
Lets say that we have the network in that picture with PAT running on the router, how PAT device make unique global identifier if both clients use the same NAT-T global UDP 4500 port ?
How NAT-T realy works in that case?
thanks,
john
Solved! Go to Solution.
10-28-2010 09:31 AM
No, it will never work for AH through NAT/PAT device as it will break the hash.
IETF article in 2004:
"Turns out, though, that by defining a mechanism to encapsulate ESP (but not AH) inside UDP, it’s possible to forward IPsec traffic through a NAT without it getting rejected. Each side sends some discovery packets to the other to determine if there is a local NAT present and if both sides are capable of performing NAT traversal (NAT-T)."
"As of this writing, NAT-T is still an Internet draft. The authors continue to make minor changes to improve functionality and interoperability. NAT-T is not defined for AH because there’s no way to effectively work around the AH integrity violation problem."
10-27-2010 09:15 AM
There are 2 types of PAT, ie: static PAT or dynamic PAT.
If only 1 site has PAT device, and assuming that this site initiates the connection, it will work with both dynamic and static PAT.
If both sites has PAT device in front of the VPN terminating devices, then one site needs to have static PAT to allow inbound connection. Dynamic PAT only works for outbound connection, therefore the following scenarios of PAT would work:
- Both sites with static PAT
- One site with static PAT and ther other site can have dynamic PAT (and the dynamic PAT ends needs to initiate the connection).
Hope that makes sense.
10-27-2010 02:01 PM
So one site must have static NAT or PAT. I didn't know that you can configure static PAT.
But the question still exists, how the device with PAT makes unique identifier for both users if NAT-T sets source and destination UDP ports 4500 ?
I didn't get how NAT-T works with that part.
10-28-2010 04:55 AM
When packet with source and destination port of 500 is sent through a PAT device, the PAT device will change the source port from 500 to a random high port, while keeping the destination port of 500. When a different IPSec NAT-T session passes through the PAT device, it will change the source port from 500 to a different random high port, and so on. The NAT device needs to be IPSec aware NAT, hence the negotiation for port 4500 will be automatic.
Here is the RFC for the IPSec aware NAT (NAT-Traversal) for your reference:
http://datatracker.ietf.org/doc/rfc3947/
(It includes the full explaination of the negotiation for your reference)
10-28-2010 07:15 AM
i think i got it !
ESP encrypts all critical information along with TCP\UDP ports. So, ESP does not use UDP port, it is an IP protocol in the same sense that UDP and TCP are IP protocols. if the PAT device allows only TCP and UDP traffic, ESP packets are dropped. IKE uses UDP port 500, but not ESP.
NAT-T encapsulates ESP packets to UDP with Source and Destination ports 4500. So, ESP packets can be translated from PAT router.
If client A sends a packet, the packet will have the form:
src: 192.168.1.5:4500 dst: 205.151.255.10:4500 - > src: 205.151.254.10:600 dst: 205.151.255.10:4500
If client B sends a packet, the packet will have the form:
src: 192.168.1.6:4500 dst: 205.151.255.10:4500 - > src: 205.151.254.10:601 dst: 205.151.255.10:4500
the response from the server will have the form to each Client:
src: 10.0.1.5:80 dst: 205.151.254.10:600 - > src: 205.151.255.10:4500 dst: 205.151.254.10:600
src: 10.0.1.5:80 dst: 205.151.254.10:601 - > src: 205.151.255.10:4500 dst: 205.151.254.10:601
I belive thats it....
Thanks,
John
10-28-2010 08:25 AM
Yes, you are absolutely correct.
The reason why ESP does not pass through PAT device is because ESP is a protocol, not a TCP or UDP protocol that has ports. PAT needs port to be able to translate with port.
This is how the IP packet is encapsulated:
Clear text packet will be encrypted with ESP packet, then it will be encapsulated into UDP/4500.
AH will not work through PAT device because AH only provides hashing and when the packet is encapsulated into UDP/4500 it will break the hashing, hence only ESP protocol of the IPSEC encapsulating it into UDP/4500 (NAT-T) will work through PAT device.
Hope that makes more sense.
10-28-2010 08:46 AM
Xmm...Right, AH won't work with PAT even with NAT-T, so if there is one Dynamic PAT and one Static NAT//PAT device we must use only ESP with NAT-T.
Does AH work if there is a dynamic or static NAT device?
Is there any way to implement AH with NAT/PAT ?
I'm not sure if it will work in transport mode.....
Also i know that NAT-T adds Original IP header(before NAT) into IKE messages with NAT-OH(Origial Header) field, but i don't know if AH can use it somehow for calculation of hashes.
10-28-2010 09:31 AM
No, it will never work for AH through NAT/PAT device as it will break the hash.
IETF article in 2004:
"Turns out, though, that by defining a mechanism to encapsulate ESP (but not AH) inside UDP, it’s possible to forward IPsec traffic through a NAT without it getting rejected. Each side sends some discovery packets to the other to determine if there is a local NAT present and if both sides are capable of performing NAT traversal (NAT-T)."
"As of this writing, NAT-T is still an Internet draft. The authors continue to make minor changes to improve functionality and interoperability. NAT-T is not defined for AH because there’s no way to effectively work around the AH integrity violation problem."
10-28-2010 09:53 AM
So that's one good reason why you can use AH and ESP both or separately.
I have one more question, AH and NAT is a problem for Remote-Access VPN, but for site-to-site VPN there is no problem because the IPsec tunnel terminates after NAT/PAT between the two routers and AH uses the public IPs to calculate hashes, am i right?
Thanks,
john
10-28-2010 09:41 PM
Whether it's IPSec for remote vpn client or site-to-site vpn, you can't use AH as the crypto policy if the VPN tunnel passes through PAT device as it is not supported. Both IPSec vpn client and site-to-site vpn uses the same concept, ie: Phase 1 - ISAKMP and Phase 2 - IPSEC, hence there isn't any difference, as AH is authentication (using hash) to provide integrity and it breaks the hash, while ESP is encryption technology which is different to authentication/hashing.
10-29-2010 04:18 AM
I understand... for AH source IP is an immutable field and if this change, hash values don't match.
By definition VPNs are used to connect remote sites through internet. NAT needed to translate private IPs to routable public IPs for the internet. If that so, In which cases we can use AH ?
Only if we use true public IPs or to create IPSec tunnel through local LAN? That makes no sense.
10-29-2010 04:41 AM
Hi john,
With AH you have no ciphering, only integrity check. ESP can do integrity check as well, but AH validate the whole packet, including the outer ip packet, which means that if you modify IP or other parameters the ah integrity code will be broke. There no real interest using AH + ESP because ESP has integrity check functions as well (but do not check the outer ip header), and AH + ESP = More overhead.
Now, in a ipsec site to site tunnel, the tunnel is meant to end on the internet router on the corp, which is normally the nat router, so IPSEC traffic is nat exempted.
You can use AH if you do not want encryption, but still integrity check, or if you want to authenticate outer packet. Note that outer packet is for tunnel mode ipsec, in transport mode, the original ip header is not authenticated by ESP, so in local networks where you use IPSEC in transport mode, AH can be in some case relevant.
Hope this is clear.
10-29-2010 09:29 AM
hi,
So we can use AH in the routers of the picture for site-to-site VPN even if they have NAT, but we won't have encryption. Also we can use AH in transport mode to local networks for packet authentication, integrity e.t.c.
This generates another question and maybe another thread ! I hope i am not becoming tedious...
Can you give me an example, in which cases we use the following?
From your previous answer i conclude that we use rarely AH+ESP.
I know the difference between IPSec tunnel vs Transport mode, but i don't know which combination to choose in each case.
Theoretically it's simple, but in practice it's much more difficult. I'm little comfused.
Thanks,
John
10-29-2010 05:23 PM
To be simple, transport when your packet are routable (so stay in local network for most case),
tunnel when they're not routable (private packet crossing the internet). For when to use AH/ESP, it really depends on what level of security you need/are allowed to use. But note that you can deactivate ciphering with ESP-NULL Transform, and that AH is very rarely used, and found some topics on IETF on which they speak about deprecating it:
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
10-31-2010 09:36 AM
hi,
I understand now, thanks for your help.
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