Do I have to pick between Native IPsec or NAT-Traversal? What if my connections require both?

Follow

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.

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

Have more questions? Submit a request

Comments