As of version 4.0, VNS3 now allows both NAT-T and Native IPsec endpoints on the same VNS3 Controller concurrently.

Versions prior to 4.0 required all connections to either use NAT-T or Native IPsec.


What's the difference? 

  • Native IPsec uses ESP, Protocol 50 (not to be confused with port 50) as a wrapper for encrypted tunnel traffic.
  • NAT-T uses UDP port 4500 instead.


When should you use each?

  • If your network gateway is on the "Internet edge" or is behind a device that can do protocol forwarding, you can forward ESP, protocol 50, to your IPsec device and use Native IPsec.
  • If your network gateway isn't on the "Internet edge" and cannot protocol forward, you'd use NAT-T to encapsulate the IPsec traffic on UDP port 4500.


NOTE: NAT-T has nothing to do with nat-ing your traffic. It only specifies whether the encrypted IPsec packets are UDP 4500 or ESP.


How-to in 4.0
When you set up a new IPsec endpoint, you can check a box to enable NAT-T. The default setting is for Native IPsec. If you need a mix of NAT-T and Native IPsec connections, simply add each connection and configure appropriately; there is no need to launch additional VNS3 controllers.



For VNS3 version 3.5.3 and older: 


Native IPsec / NAT-T is a device-wide setting.  All of the connections to a particular VNS3 Controller must be either Native IPsec or NAT-Traversal.  


This is one of the first decisions you must make in VNS3 Controller configurations, as you cannot change it once endpoints have been defined.

 


What if I am using a version of VNS3 prior to 4.0 and have multiple customers, data centers, etc who want to use NAT-T and Native IPsec? 


To connect to both Native IPsec and NAT-T based connections in VNS3 <4.0, set up two peered VNS3 Controllers. One Controller configured for NAT-T, and the other Controller configured for Native IPsec. This way you can bring both types of connections into the same topology.


See more on IPsec troubleshooting and use the IPsec endpoint guide.