UPDATE: VNS3 4.0 and newer
The new VNS3 4.0 version now allows both NAT-T and Native IPsec endpoints on the same VNS3 Controller.
What's the difference?
- Native IPsec enabled communicates on Protocol 50 (not port 50)
- NAT-T enabled communicates on UDP 4500
When should you use each?
- If your network gateway is on the "Internet edge" or is behind a device that can do protocol forwarding, Native IPsec uses Custom Protocol 50 (not port 50)
- If your network gateway isn't on the "Internet edge" and cannot protocol forward (different from port forward) you'd use NAT-T to encapsulate traffic on UDP port 4500
NOTE: NAT-T has nothing to do with nat-ing your traffic. It specifies whether the communication happens via UDP 4500 or Protocol 50.
How to in 4.0
When you set up a new IPsec endpoint, you can check the box to enable NAT-T. Default settings will be for Native IPsec connections. If you need multiple NAT-T and Native IPsec connections, simply add each connection individually rather than launch another VNS3 Controller.
For VNS3 version 3.5.2 and older:
Native IPsec / NAT-T is a devices wide setting. All of the connections to a VNS3 Controller must be either Native IPsec or NAT-Traversal.
This is one of the first decisions you must make in VNS3 Controller configurations.
What if I 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, set up 2 peered VNS3 Controllers. Both VNS3 Controllers should be peered together and supporting the overlay network. One Controller will be configured for NAT-T and the other Controller will be configured for Native IPsec. This way you can bring both connections into the same overlay network.