cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
36238
Views
36
Helpful
16
Replies

How NAT-T works with IPSec?

ioanniatr
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

16 Replies 16

Jennifer Halim
Cisco Employee
Cisco Employee

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.

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.

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)

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

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.

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.

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

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

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.

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.

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.

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?

  • AH in transport
  • AH in tunnel
  • ESP in transport
  • ESP in tunnel

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

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

hi,

I understand now, thanks for your help.