The insufficient number of publicly valid IP addresses has lead to the development of procedures such as IP masquerading or NAT (Network Address Translation), where a whole local network is masked by a single, publicly valid IP address. In this way, all clients in a LAN use the same IP address to exchange data with public networks such as the Internet. The assignment of the incoming and outgoing data packets to the different participants in the network is ensured by connecting the internal IP addresses to corresponding port numbers.
This process has proven its worth and has since become the standard in almost all Internet routers. However, new difficulties arise when the hidden data packets are processed using VPN. As data connections over VPN are highly secured, mechanisms such as authentication and encryption are of great importance here.
Converting internal IP addresses to the gateway's central, publicly valid IP address and converting source and target ports can lead to problems in many applications, for example where the UDP port 500 that is usually used during the IKE negotiation has been changed and the IKE can no longer be successfully completed as a result. The address change using NAT is therefore assessed by a VPN gateway as a security-critical data packet change, the VPN negotiation fails and no connection is made. In fact these problems occur, for example, when you dial in using some mobile telephone networks where the network operator's servers do not support the address conversion in combination with IPsec-based VPNs.
So you can successfully create a VPN connection even in such cases, NAT-T (NAT Traversal) provides a process that can overcome the problems described when handling data packets with changed addresses.
If the VPN uses AH for authentication, then in principle no connection can be established over sections with Network Access Translation, as the AH hash values similarly change when the IP addresses change, and the recipient would classify the data packets as untrustworthy.
The NAT Traversal process eliminates the problems that occur when establishing a VPN connection at the end points of the VPN tunnel. The following scenarios can be distinguished from one another:
- A member of the field staff uses the LANCOMAdvanced VPN Client to dial into the company VPN router without "VPN pass-through" support (i.e. IPsec masking) but with Network Address Translation.
- The two tunnel end points LANCOMAdvanced VPN Client 1 and VPN router 3 support NAT-T and can therefore also establish a VPN connection through the intermediary router.
- Router 2 as a NAT device between the VPN end points performs straight forward NAT address conversion. This router does not require NAT but firewall ports 500 and 4500 must be open in order to enable NAT communication between both tunnel end points.
- In the second example application, the travelling field worker dials in to the network at the headquarters with his notebook 1 and a mobile telephone or modem 2.
- At the headquarters, the VPN router 4 is located behind a terminating router 3, which only provides Internet access with the address conversion.
- The two tunnel end points LANCOMAdvanced VPN Client 1 and VPN router 4 support NAT-T and can therefore establish a VPN connection, as in the first example.
- In the terminating router 2, the firewall ports 500 and 4500 have to be activated, as does port forwarding.
- In both of these cases, the two ends of the connection are the straight-forward NAT routers 2 and 3. The VPN connection is established between the LANCOM Advanced VPN Client 1 and VPN router 4. The two routers 2 and 3 have to permit the NAT-T connection between the two tunnel endpoints in that the firewall ports 500 and 4500 are activated, and port forwarding has to be activated in the terminating router at the headquarters, as well.
To enable this process, both ends of the VPN connection have to work with NAT-T. The process of establishing the VPN connection (reduced to the NAT-T-relevant operations) appears as follows:
- At an early stage of the IKE negotiation, there is a check to see if both ends of the VPN connection are NAT-T-compatible.
- In the second step, there is a check to see if the address is converted to NAT on the section between the two tunnel end points, and at what point in the connection the NAT devices are located.
- To deal with problems with ports that may have changed, all negotiation and data packets are subsequently sent only via UDP port 4500 when a NAT device has been detected. Important: If the device functions as a NAT router between the VPN end points, ensure that UDP ports 500 and 4500 are enabled in the firewall when you use NAT-T! This port is activated automatically if you use the firewall assistant in LANconfig.
If the VPN connections are first created on devices with firmware version 5.20 or above using the VPN assistant and later with the firewall assistant from LANconfig, then no additional firewall settings are required for the NAT router.
- In the diagram below, the data packets are packed again into UDP packets (UDP encapsulation) and are also sent using port 4500. As a result of this additional encapsulation, changing the IP addresses for the VPN negotiation is no longer relevant and the VPN tunnel can be established without any problems. At the other end of the connection, the IP data is released again by the additional UDP header and can be processed by the router without further action.
In order to use this process, both ends of the VPN connection have to use NAT-T.
You will find the button for activating NAT-T in LANconfig under .
Under Telnet or SSH client you will find the settings for activating NAT-T under .
