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.
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).
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)?
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.
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :