NAT traversal

Network Address Translation (NAT) is a way to convert private IP addresses to publicly routable Internet addresses and vise versa. When an IP packet passes through a NAT device, 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 demultiplexed. To work around this, the FortiGate unit 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 devices to change the port number without modifying the IPsec packet directly.

To provide the extra layer of encapsulation on IPsec packets, the Nat-traversal option must be enabled whenever a NAT device exists between two FortiGate VPN peers or a FortiGate unit and a dialup client such as FortiClient. On the receiving end, the FortiGate unit or FortiClient removes the extra layer of encapsulation before decrypting the packet.

Additionally, you can force IPsec to use NAT traversal. If NAT is set to Forced, 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.

NAT keepalive frequency

When a NAT device performs network address translation on a flow of packets, the NAT device determines how long the new address will remain valid if the flow of traffic stops (for example, the connected VPN peer may be idle). The device may reclaim and reuse a NAT address when a connection remains idle for too long.

To work around this, when you enable NAT traversal specify how often the FortiGate unit sends periodic keepalive packets through the NAT device in order to ensure that the NAT address mapping does not change during the lifetime of a session. To be effective, the keepalive interval must be smaller than the session lifetime value used by the NAT device.

The keepalive packet is a 138-byte ISAKMP exchange.

Dead Peer Detection

Sometimes, due to routing issues or other difficulties, the communication link between a FortiGate unit and a

VPN peer or client may go down. Packets could be lost if the connection is left to time out on its own. The FortiGate unit provides a mechanism called Dead Peer Detection (DPD), sometimes referred to as gateway detection or ping server, to prevent this situation and reestablish IKE negotiations automatically before a connection times out: the active Phase 1 security associations are caught and renegotiated (rekeyed) before the Phase 1 encryption key expires.

By default, Dead Peer Detection sends probe messages every five seconds by default (see dpdretryinterval in the FortiGate CLI Reference). If you are experiencing high network traffic, you can experiment with increasing the ping interval. However longer intervals will require more traffic to detect dead peers which will result in more traffic.

In the web-based manager, the Dead Peer Detection option can be enabled when you define advanced Phase 1 options. The config vpn ipsec phase1 CLI command supports additional options for specifying a retry count and a retry interval.

For more information about these commands and the related config router gwdetect CLI command, see the FortiGate CLI Reference.

For example, enter the following CLI commands to configure dead peer detection on the existing IPsec Phase 1 configuration called test to use 15 second intervals and to wait for 3 missed attempts before declaring the peer dead and taking action.

config vpn ipsec phase1-interface edit <value> set dpd [disable | on-idle | on-demand]

set dpd-retryinveral 15 set dpd-retrycount 3 next

end

The default for vpn ipsec phase1 dpd is on-idle when the type is

dynamic to encourage dialup server configurations to more pro-actively delete tunnels if the peer goes away.

DPD scalability

On a dial-up server, if a multitude of VPN connections are idle, the increased DPD exchange could negatively impact the performance/load of the daemon. For this reason, an option is available in the CLI to send DPD passively in a mode called “on-demand”.

Syntax

Set DPD to on-demand to trigger DPD when IPsec traffic is sent but no reply is received from the peer.

config vpn ipsec phase1-interface edit <value> set dpd [disable | on-idle | on-demand]

next

end

Certificate key size control

Proxy will choose the same SSL key size as the HTTPS server. If the key size from the server is 512, the proxy will choose 1024. If the key size is bigger than 1024, the proxy will choose 2048.

As a result, the firewall ssl-ssh-profile commands certname-rsa, certname-dsa, and certname-ecdsa have been replaced with more specific key size control commands under vpn certificate setting.

CLI syntax

config vpn certificate setting set certname-rsa1024 <name> set certname-rsa2048 <name> set certname-dsa1024 <name> set certname-dsa2048 <name> set certname-ecdsa256 <name> set certname-ecdsa384 <name>

end

Quantum resistant IKEv2 SA negotiation

An IKEv2 extension is available that changes the key generation mechanism to include a Post-quantum Preshared Key.

 

Using XAuth authentication

The addition of PPK in the calculation means that even if a quantum computer can break the Diffie-Hellman calculation to derive the DH-generated secret key, the inclusion of the PPK in the key generation algorithm means that the attacker is still unable to derive the keys used to authenticate the IKE SA negotiation (and so cannot impersonate either party in the negotiation) nor the keys used in negotiating an IPsec SA (or IKE SA).

Syntax

config vpn ipsec phase1-interface edit <name> set ike-version 2 set type dynamic

set ppk {disable | allow | require}

set ppk-secret <ASCII string or hexadecimal encoded with a leading 0x> set ppk-identity <string>

next

end config user local edit <name> set type password

set ppk-secret <ASCII string or hexadecimal encoded with a leading 0x>

next

end

For troubleshooting, diagnose vpn ike ga list can indicate whether PPK was negotiated.

• The ‘PPK’ at the gateway level indicates whether PPK was negotiated during the initial IKE SA negotiation. l The ‘PPK’ at the IKE SA level indicates whether PPK was negotiated on this IKE SA.
• The ‘child’ at the IKE SA level indicates whether the IKE SA is an initial IKE SA or whether it is a child IKE SA. The above has ‘child: no’ and so it is initial IKE SA.