IPSEC ports/protocol numbers and UDP ports with NAT

I'm watching an INE video for IPSEC VPN's, specifically the section about IPSEC Control Plane vs Data Plane.

In the video the instructor is talking about that IPSEC uses port 500 (for AH and ESP) in the Control plane and Protocol number 50 and 51 for ESP and AH. But when the tunnel is going through NAT use sues different ports. It uses port 4500 for both the Control and Data Plane.

So I'm a bit confused as how this works. UDP port work at Layer 4, so so far moving the data from 4500 to 500 is clear, but why is port 4500 allowed and 4500 disallowed. That seem weird to me. It's like when you're trying to smuggle something over the border, but when you transfer to another car, this is going to work.

Also the part about the Data plane is not clear. Instead of using Protocol numbers (Layer 3) it moves the data to UDP 4500 (Layer 4). I'm not following how this works and why it works.

Find more posts tagged with

Comments

lrb

Only ISAKMP uses UDP port 500 for the initial key exchange, and this is not for the encryption of actual user data. IPsec is and it doesn't use ports.

If you think about how NAT works, and specifically PAT/PNAT/overloading, the translating device overloads based on the source port address. But how does this work for IPsec because IPsec doesn't use source ports? This is where NAT-T for IPsec comes in, and this is where you the UDP port 4500 comes from.

When two devices are about to establish an IPsec VPN they do the normal ISAKMP thing and also indicate that they support NAT-T. If they both do, they can detect whether address translation is occurring between the two devices by each side sending the hash of their local socket (ip address, source port). When each side receives this hash, they each compute the same hash of the (source IP, source port) in the IP header from the receiver and compare the result to the hash. If they mismatch, NAT must be occurring somewhere in the middle.

If they two devices are RFC3947-compliant, they immediately switch to encapsulating the data into UDP with the port number 4500 for the remainder of the exchange and post-setup (i.e. sending normal application data). At the end when IPsec is up and working, you will notice an extra header in the stack which will be UDP. This is required so that the NAT device can overload based on the source port.

You can see on an existing pair of IPsec SAs whether NAT-T is in use.

[COLOR=#000000][FONT=Courier New]R1#show crypto ipsec sa[/FONT][/COLOR]

[COLOR=#000000][FONT=Courier New]interface: FastEthernet0/0[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]    Crypto map tag: CMAP, local addr 10.1.2.1[/FONT][/COLOR]

[COLOR=#000000][FONT=Courier New]   protected vrf: (none)[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]   local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]   remote ident (addr/mask/prot/port): (10.3.3.0/255.255.255.0/0/0)[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]   <SNIP>[/FONT][/COLOR]

[COLOR=#000000][FONT=Courier New]     inbound esp sas:[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]      spi: 0x7048BE76(1883815542)[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        transform: esp-aes esp-sha-hmac ,[/FONT][/COLOR]
[COLOR=#D100FF][FONT=Courier New][B]        in use settings ={Tunnel UDP-Encaps, }[/B][/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        conn id: 1, flow_id: SW:1, crypto map: CMAP[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        sa timing: remaining key lifetime (k/sec): (4580629/2937)[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        IV size: 16 bytes[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        replay detection support: Y[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        Status: ACTIVE[/FONT][/COLOR]

[B][COLOR=#000000][FONT=Courier New]     inbound ah sas:[/FONT][/COLOR]

[COLOR=#000000][FONT=Courier New]     inbound pcp sas:[/FONT][/COLOR][/B]

[COLOR=#000000][FONT=Courier New]     outbound esp sas:[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]      spi: 0x51614C36(136533099[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_cool.gif[/IMG][/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        transform: esp-aes esp-sha-hmac ,[/FONT][/COLOR]
[COLOR=#D100FF][FONT=Courier New][B]        in use settings ={Tunnel UDP-Encaps, }[/B][/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        conn id: 2, flow_id: SW:2, crypto map: CMAP[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        sa timing: remaining key lifetime (k/sec): (4580629/292[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_cool.gif[/IMG][/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        IV size: 16 bytes[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        replay detection support: Y[/FONT][/COLOR]
[COLOR=#000000][FONT=Courier New]        Status: ACTIVE[/FONT][/COLOR]

[COLOR=#000000][FONT=Courier New]     outbound ah sas:[/FONT][/COLOR]

[COLOR=#000000][FONT=Courier New]     outbound pcp sas:[/FONT][/COLOR]

Hope that helped!

theodoxa

Without NAT, all negotiations use UDP 500.
With NAT, the first 2 exchanges use UDP 500 and then (starting with certificate exchange), they use UDP 4500 from there on out.

Device A --> Device B (UDP 500)
Device A <-- Device B (UDP 500)
Device A --> Device B (UDP 500)
Device A <-- Device B (UDP 500)
Device A --> Device B (UDP 4500 - Device A Sends its Certificate)
Device A <-- Device B (UDP 4500 - Device B Sends its Certificate)
...

lrb

Unless the two devices are using aggressive mode

FrankGuthrie

What happens with the protocol numbers? Doesn't the packet need to identify the payload. So does the protocol number change? Is this change to protocol 17 for UDP?

theodoxa

lrb wrote: »

Unless the two devices are using aggressive mode

True...

FrankGuthrie

What changes when they use aggressive mode?

lrb

The IKE phase 1 is shortened to a three message exchange, but the identity of the initiator (e.g. IP address, hostname) is sent in the first message and is sent in the clear.

It's big use case is when you have dynamic IP addresses on one or both of the peers

FrankGuthrie

lrb wrote: »

The IKE phase 1 is shortened to a three message exchange, but the identity of the initiator (e.g. IP address, hostname) is sent in the first message and is sent in the clear.

It's big use case is when you have dynamic IP addresses on one or both of the peers

But what does this have to do with the UDP ports?

lrb

If you're using aggressive mode with NAT-T, then the second and third message are encapsulated in UDP to complete the three-message phase 1.

Maybe have a read over RFC3947 and it will answer all of your questions to do with this feature.

https://tools.ietf.org/html/rfc3947