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.