NAT Traversal (NAT-T) » History » Version 7
Noel Kuntze, 16.02.2016 23:57
h1. NAT Traversal
Before [[5.0.0]], NAT discovery and traversal had to be enabled by setting _nat_traversal=yes_ in the [[ConfigSetupSection|config setup]] section of [[IpsecConf|ipsec.conf]]. Otherwise strongSwan 4.x's IKEv1 pluto daemon would not accept incoming IKE packets with a UDP source port different from 500. Since [[5.0.0]] IKEv1 traffic is handled by the charon daemon which supports NAT traversal according to "RFC 3947":http://tools.ietf.org/html/rfc3947 without enabling it explicitly.
The IKEv2 protocol includes NAT traversal in the core standard, but it's optional to implement. strongSwan implements it, and there is no configuration involved. The @NAT_DETECTION_SOURCE/DESTINATION_IP@ notifications included in the @IKE_SA_INIT@ exchange indicate the peers NAT-T capability and if a NAT situation is detected, UDP encapsulation is activated for IPsec.
strongSwan starts sending keep-alive packets if it is behind a NAT router to keep the mappings on the NAT device intact.
NAT traversal cannot be disabled in the charon daemon. If you don't like automatic port floating to UDP/4500 due to the MOBIKE protocol (RFC 4555) which happens even if no NAT situation exists then you can disable MOBIKE by adding
to ipsec.conf in the connection definition.