An option to disable NAT-T
I'd like to ask if it would be possible to add an option to disable NAT-T floating to port UDP 4500.
I fully understand the reasons behind automatic NAT discovery and moving to UDP 4500 once a NAT is detected, or even forcing this behavior in config. It makes sense and simplifies things when some tricky firewalls are included so it should be the default.
On the other hand, there are also situations where one or both hosts can be natted behind firewalls, but those firewalls are fully under admin's control and properly configured to forward ESP and UDP 500 to ipsec hosts. In those cases, it feels wrong to be forced to UDP encapsulation that is not needed for anything and is just creating additional overhead and lowering payload MTU.
I've been using this configuration for few years with Cisco IOS devices and older strongSwan versions with Pluto - both of those allow to define whenever NAT-T should be used or not. Currently, I am trying to move to strongSwan 5.x release to utilize new swanctl interface and I was kinda puzzled that NAT-T is actually enforced.
For the record, the situation I am talking about is classic net2net IKEv1 setup, I am not really sure if my suggestions also applies to IKEv2.
Perhaps the most simple solution would be to add "connections.<conn>.encap" option "never" to swanctl.conf, and if set, NAT-T would not activate.
Thank you for your consideration and thanks for developing this great piece of software.
#1 Updated by Marek Cerny over 5 years ago
Just to be sure, I've checked the RFCs and I believe that this feature request is in fact RFC-compliant. This applies to IKEv1, not IKEv2.
According to rfc3947, section 5.1:
If there is no NAT box between, there is no point in wasting bandwidth by adding UDP encapsulation of packets. Thus, UDP-Encapsulation SHOULD NOT be used.
and yet, strongSwan offers encap=yes to override this and enforce UDP ecapsulation when we really want it.
So, moving to the opposite scenario:
If there is a NAT box between hosts, normal tunnel or transport encapsulations may not work. In this case, UDP-Encapsulation SHOULD be used.
it feels logical to also provide an override method to disable UDP encapsulation when it's not needed/desired - because as the other paragraph says, there is no point in wasting bandwidth.
#3 Updated by Paul Donohue 4 months ago
I just ran into this with IKEv2. It would be nice if NAT-T could be disabled.
My use case is probably unusual:
I have multiple internet connections with separate IP spaces. I do not NAT when using the primary connection, but I do NAT when using a backup connection (to avoid needing to configure dynamic routing and dynamic source address selection on all of my internet-facing systems). I only have one strongSwan server (and no other IPsec servers/clients), and I have configured stateless/static NAT for ESP traffic on the backup connection, so NAT-T is not technically required when using the backup connection with NAT.
In addition to the unnecessary overhead of NAT-T ... One of the remote IPsec servers I am connecting to also runs strongSwan (so NAT-T cannot be explicitly disabled on either side), but it has a firewall blocking UDP 4500 (that cannot be easily changed for various non-technical reasons). So, when using my primary connection everything works (since NAT-T is not negotiated), but on the backup connection it fails (since NAT-T is negotiated but then blocked by the firewall).
As an alternative to disabling NAT-T, my particular use case could also be handled by allowing the NATD source IP payloads to be explicitly configured (such that strongSwan sends multiple IPs and the remote system does not detect NAT if any of those IPs are used). For example, strongSwan is capable of sending all of the IPs configured on an interface, and I could configure both the primary and backup IPs on my interface, but I can't find a way to bypass or override the routing table source IP lookup so that strongSwan actually sends all of the addresses: