cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1270
Views
0
Helpful
5
Replies

A question about NAT-T

nevereturn
Level 1
Level 1

Hi All,

I have a question about NAT-T. Topology is below:

===VPN site1===ISP===NAT device===VPN site2====

PS: 1. The NAT device is provided by ISP (like TP-Link home edition) and I don’t have permission to manage it, such as allowing a specific UDP port for inbound flow. It just works as PAT and translate all internal IP address to the physical outside interface’s IP address.
2. Both two VPN sites are Cisco Routers.

My question is:

If the VPNsite2 initiates VPN connection, how will the VPNsite1 device traverse the NAT device?

For example, the NAT device translates the VPNsite2 packet from origin source port from UDP 4500 to UDP 10001, will VPNsite1 use UDP 10001 as destination port when sending the VPN flow back?

As we all know, if VPNsite1 still uses UDP 4500 as the destination port, the packet won’t traverse the ISP NAT device in this case.

The reason why I ask this question is that when I use a Cisco router to work as the ISP NAT device for test, the Cisco router translates the source UDP port from 4500 to 4500, not a random port. As a result, it doesn’t suit this scenario.

By the way, is this a by-default behavior of Cisco route (not changing the source port for UDP 4500)?

If I haven’t posted enough information on this issue, please feel free to let me post it.

Thanks in advance

5 Replies 5

Jennifer Halim
Cisco Employee
Cisco Employee

You do not have to worry about what source port it translate the IPSEC VPN to as it is handled by the IPSec protocol itself during the negotiation. It can detect that there is a NAT device in between the 2 VPN peers, and automatically uses UDP/4500 for ESP (Phase 2).

Hi Jennifer,

Thanks for your reply.

In this case, the two negotiationVPN site use source and destination port as UDP 4500. In my opinion, the middle NAT device doesn't care it. It just translates the source UDP port as usual, such as from UDP 4500 to UDP 10001. I just want an answer with my first question.

Yes or NO?

Or, is there any special mechanism at IPSEC level or device level that makes sure that the VPN back flow can traverse the middle NAT device (just like TP-Link Home Edition)?

Thanks in advance.

All NAT-T does is to encapsulate the ESP packet to UDP/4500, because ESP is a protocol and it can't pass through a NAT device, that is why you would need to encapsulate it to UDP/4500, so if it passes through a NAT device, it has a port for PATing.

The NAT-T will be confirmed by both VPN peers during negotiation, so both end knows to use NAT-T (UDP/4500) instead of ESP. So to answer your question, yes, there is a special mechanism at IPSec level (ie: NAT-T during IKE exchanges) for both end to use UDP/4500 so it can flow back using UDP/4500.

Thanks for your reply.

I understand that two VPN sites will detected that there is a NAT device between them and use UDP 4500 for subsequent flow.

What I concern is about the middle stupid PAT device that treats the subsequent VPN flow after negotiation.

Obviously, it doesn't know UDP 4500 is for NAT-T VPN flow. It treats UDP 4500 flow as normal flow and change the soure port. As a result, if VPNsite1 still uses UDP 4500 as the destination port to send the packet back, the packet won’t traverse the middle stupid PAT device in this case.

Thanks in advance

LOL, the middle PAT device will definitely send the packet back as it is the same flow.

Site 2 will initiate the translation/PAT, and the return traffic will be part of the same flow for UDP/4500.

Just like you are PATing any other traffic, it knows about that traffic and will translate it back accordingly.