Project

General

Profile

NAT Traversal (NAT-T) » History » Version 9

Tobias Brunner, 05.07.2017 14:41
Some updates and clarifications

1 9 Tobias Brunner
h1. NAT Traversal (NAT-T)
2 1 Martin Willi
3 9 Tobias Brunner
{{title(NAT Traversal (NAT-T))}}
4 1 Martin Willi
5 9 Tobias Brunner
The IKEv2 protocol includes NAT traversal (NAT-T) in the core standard, but it's optional to implement. strongSwan implements it and does not require any special configuration. The @NAT_DETECTION_SOURCE/DESTINATION_IP@ notifications included in the @IKE_SA_INIT@ exchange indicate the peer's NAT-T capability and allow detecting which peer, if any, is behind a NAT device. If a NAT situation is detected, the client switches to UDP port 4500 to send the @IKE_AUTH@ request (only if it used port 500 initially, see below regarding custom ports) and UDP encapsulation will be activated for IPsec SAs.
6 1 Martin Willi
7 9 Tobias Brunner
NAT-T cannot be disabled in the charon IKE daemon.  If you don't like the automatic port floating to UDP/4500 due to the [[MobIke|MOBIKE protocol]], which happens even if no NAT situation exists, then you can disable MOBIKE by disabling the _mobike_ option in your connection definition.
8 1 Martin Willi
9 9 Tobias Brunner
h2. UDP Encapsulation of ESP
10 1 Martin Willi
11 9 Tobias Brunner
Because ESP packets are unidirectional NAT devices can't map them like they do with e.g. TCP/UDP packets by using the ports in those headers. Some NAT devices have a feature, often called something like "IPsec passthrough", that detects IKE traffic from a single host behind the NAT and will forward incoming plain ESP packets to that host. But that won't work with multiple clients behind the same NAT that use the same server. To allow multiple clients UDP encapsulation is used. Adding a UDP header to the ESP packets allows NAT devices to treat them like the IKE packets (or any other UDP packets) and to maintain port mappings to forward the packets from/to the correct hosts behind the NAT.
12 1 Martin Willi
13 9 Tobias Brunner
The UDP encapsulated ESP packets are sent on the same ports used for IKE traffic. To distinguish them from IKE packets the latter are modified so they contain four zero bytes right after the UDP header where the SPI is located in ESP packets (known as "non-ESP marker"). This means that the UDP socket/port (4500 by default) has to handle traffic differently than the default IKE socket/port. This has some implications when using a custom server port (see below).
14 1 Martin Willi
15 9 Tobias Brunner
UDP encapsulation may also be forced, even if no NAT situation is detected, by using the _forceencaps_ and _encap_ options in [[ConnSection|ipsec.conf]] and [[swanctl.conf]], respectively. If enabled, the daemon will send a fake @NAT_DETECTION_SOURCE_IP@ notify payload so it looks to the peer as if there is a NAT situation.
16 9 Tobias Brunner
17 9 Tobias Brunner
h2. NAT-T Keepalives
18 9 Tobias Brunner
19 9 Tobias Brunner
strongSwan starts sending keepalive packets if it is behind a NAT to keep the mappings in the NAT device intact. The interval for these small packets (a single @0xff@ byte after the UDP header) may be configured with the _charon.keep_alive_ [[strongswan.conf]] option (set to 0 to disable sending keepalives, e.g. behind a static DNAT aka port forwarding).
20 9 Tobias Brunner
21 9 Tobias Brunner
h2. Custom Server Ports
22 9 Tobias Brunner
23 9 Tobias Brunner
As described above, if UDP encapsulation is used the ESP packets are sent on the ports already used for IKE traffic. Because there is no port switch when using a custom port (for simplicity, the client uses only one port, configured either in _rightikeport_ or _remote_port_), and due to the addition of non-ESP markers when using ports != 500, traffic must usually go via NAT-T port.  Therefore, when setting a custom port on the server the right option is _charon.port_nat_t_, the _charon.port_ option is not relevant in this scenario (i.e. that socket/port will not be used). When sending traffic to that port a non-ESP marker has to be added. strongSwan adds one if neither source, nor destination port is 500. This means the client can't use port 500 for its default IKE socket, so it will already add a non-ESP marker when sending the initial @IKE_SA_INIT@ request. This can be achieved by setting _charon.port_ on the client to either 0 (so a random port is allocated) or any number != 500 if that port is not used by any other process. The client will, however, switch to the second source port configured via _charon.port_nat_t_ if a NAT is detected or MOBIKE is enabled, so setting both to 0 usually makes most sense for mobile clients that connect to a custom server port (but using port 4500 as source is usually also not a problem).
24 9 Tobias Brunner
25 9 Tobias Brunner
h2. IKEv1
26 9 Tobias Brunner
27 9 Tobias Brunner
Before strongSwan version:5.0.0, NAT discovery and traversal for IKEv1 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 version: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 (and some of its early drafts) without having to enable it explicitly (it can't be disabled either, though).