Description
This article discusses about the nat traversal options available under the phase 1 settings of an IPsec tunnel.
Scope
FortiGate.
Solution
Network Address Translation (NAT) is a way to convert private IP addresses to publicly routable Internet addresses and vice versa. When an IP packet passes through a NAT unit, the source or destination address in the IP header is modified. FortiGate units support NAT version 1 (encapsulate on port 500 with non-IKE marker), version 3 (encapsulate on port 4500 with non-ESP marker), and compatible versions.
NAT cannot be performed on IPsec packets in ESP tunnel mode because the packets do not contain a port number. As a result, the packets cannot be de multiplexed.
To work around this, the FortiGate provides a way to protect IPsec packet headers from NAT modifications. When the Nat-traversal option is enabled, outbound encrypted packets are wrapped inside a UDP IP header that contains a port number. This extra encapsulation allows NAT units to change the port number without modifying the IPsec packet directly.
Another benefit of forcing NAT-T even if NAT is not involved between both IPSEC Gateways, is in situations where the ISP is performing Traffic Shaping for ESP protocol. When NAT-T is forced the ESP encapsulated payload is encapsulated once more with UDP 4500, and the ISP only sees UDP traffic.
To provide the extra layer of encapsulation on IPsec packets, the Nat-traversal option must be enabled whenever a NAT unit exists between two FortiGate VPN peers or a FortiGate unit and a dial up client such as FortiClient.
On the receiving end, the FortiGate unit or FortiClient removes the extra layer of encapsulation before decrypting the packet:
config vpn ipsec phase1-interface
edit "tunnel-name"
set interface "wan1"
set ike-version 2
set peertype any
set net-device enable
set proposal aes256-sha1
set nattraversal enable default setting is “enable”
set psksecret <secret>
next
end
NAT Traversal.
The following nattraversal options are available under phase1 settings of an IPsec tunnel:
(tunnel-name) # set nattraversal
enable <----- Enable IPsec NAT traversal.
disable <----- Disable IPsec NAT traversal.
forced <----- Force IPsec NAT traversal on. The IKE Phase 1 tunnel(s) need to be flushed for the configuration to take effect.
Select Enable if a NAT device exists between the local FortiGate and the remote VPN peer. The local FortiGate and the remote VPN peer must have the same NAT traversal setting (both enabled or disabled) to connect reliably.
It has been observed while establishing an IPsec tunnel between FortiGate and another vendor unit that either the tunnel does not get established or traffic does not flow through an IPsec tunnel.
Since each vendor has their own IPsec tunnel implementation, IPsec can be forced to use NAT traversal in such cases. If NAT is set to force, the FortiGate will use a port value of zero when constructing the NAT discovery hash for the peer. This causes the peer to think it is behind a NAT device, and it will use UDP encapsulation for IPsec, even if no NAT is present. This approach maintains interoperability with any IPsec implementation that supports the NAT-T RFC.
If nat traversal is set to forced, the following output will be shown.
get vpn ipsec tunnel details | grep nat
nat traversal mode: silent
Note:
Forced NAT-Traversal does not mean FortiGate will send the SA_INIT packet at the first stage of IKE negotiation in the UDP 4500 packet. This only means it is forced to use UDP encapsulation for IPsec, even if no NAT is present.
The FortiGate still sends this negotiation in UDP port 500 at the initial negotiation stage and switches to UDP 4500 when NAT is detected. So, the NAT gateway needs to allow both ports 500 and 4500 if any rule is configured there.
It is important to understand that IPSEC is a combination of the Control Plane over UDP port 500, and data plane over ESP or UDP 4500 if NAT-T is enabled.
Verification:
To verify if NAT-traversal is used, especially with the default option 'enabled', the command 'diag vpn ike gateway list name <phase1-name>' can be used.
Below is an example:
FortiGate # diag vpn ike gateway list name tunnel-name
vd: root/0
name: tunnel-name
version: 1
interface: mgmt 3
addr: 10.10.10.80:4500 -> 10.11.35.33:4500 < NAT-traversal is used
tun_id: 10.11.35.33/::10.11.35.33
remote_location: 0.0.0.0
network-id: 0
created: 358991s ago
peer-id: 10.11.35.33
peer-id-auth: no
nat: peer
IKE SA: created 1/5 established 1/5 time 0/8/10 ms
IPsec SA: created 1/9 established 1/9 time 0/5/10 ms
id/spi: 16345 41889aud0eefb64b/fbf1e8bube49f2da
direction: responder
status: established 14561-14561s ago = 10ms
proposal: aes128-sha256
key: eaa33b880b8d51-6c827cdd0a286f
lifetime/rekey: 86400/71568
DPD sent/recv: 00000000/00000000
peer-id: 10.11.35.33
FortiGate # diag vpn ike gateway list name tunnel-name
vd: root/0
name: tunnel-name
version: 1
interface: mgmt 3
addr: 10.10.10.80:500 -> 10.11.35.33:500 < NAT-traversal NOT used
tun_id: 10.11.35.33/::10.11.35.33
remote_location: 0.0.0.0
network-id: 0
created: 3s ago
peer-id: 10.11.35.33
peer-id-auth: no
IKE SA: created 1/1 established 1/1 time 0/0/0 ms
IPsec SA: created 1/1 established 1/1 time 0/0/0 ms
id/spi: 16818 732b3aa02d5f2b/5594da7afc42ba
direction: initiator
status: established 3-3s ago = 0ms
proposal: aes128-sha256
key: 449b0a7f4e9ce689-3a91ffb1f4ad8bfd
lifetime/rekey: 86400/86096
DPD sent/recv: 00000000/00000000
peer-id: 10.11.35.33
Related documents:
Technical Tip: How to flush a VPN tunnel
Defining IKE negotiation parameters
