If you are creating a hub-and-spoke configuration or an Internet-browsing configuration, you may have already started defining some of the required Phase 2 parameters. If so, edit the existing definition to complete the configuration.
Specifying the Phase 2 parameters
- Go to VPN > IPsec Tunnels and create the new custom tunnel or edit an existing tunnel.
- Open the Phase 2 Selectors panel (if it is not available, you may need to click the Convert to Custom Tunnel button).
- Enter a Name for the Phase 2 configuration, and select a Phase 1 configuration from the drop-down list.
- Select Advanced.
- Include the appropriate entries as follows:
|Phase 2 Proposal||Select the encryption and authentication algorithms that will be used to change data into encrypted code.
Add or delete encryption and authentication algorithms as required. Select a minimum of one and a maximum of three combinations. The remote peer must be configured to use at least one of the proposals that you define.
It is invalid to set both Encryption and Authentication to null.
Select a symmetric-key algorithms:
|Authentication||You can select either of the following message digests to check the authenticity of messages during an encrypted session:
NULL — Do not use a message digest.
MD5 — Message Digest 5.
SHA1 — Secure Hash Algorithm 1 - a 160-bit message digest.
To specify one combination only, set the Encryption and Authentication options of the second combination to NULL. To specify a third combination, use the Add button beside the fields for the second combination.
For information regarding NP accelerated offloading of IPsec VPN authentication algorithms, please refer to the Hardware Acceleration handbook chapter.
|Enable replay detection||Optionally enable or disable replay detection. Replay attacks occur when an unauthorized party intercepts a series of IPsec packets and replays them back into the tunnel.|
|Enable perfect forward secrecy (PFS)||Enable or disable PFS. Perfect forward secrecy (PFS) improves security by forcing a new Diffie‑Hellman exchange whenever keylife expires.|
|Diffie-Hellman Group||Select one Diffie-Hellman group (1, 2, 5, or 14 through 21). The remote peer or dialup client must be configured to use the same group.|
|Keylife||Select the method for determining when the Phase 2 key expires: Seconds, KBytes, or Both. If you select Both, the key expires when either the time has passed or the number of KB have been processed. The range is from 120 to 172800 seconds, or from 5120 to 2147483648 KB.|
|Autokey Keep Alive||Enable the option if you want the tunnel to remain active when no data is being processed.|
|Auto-negotiate||Enable the option if you want the tunnel to be automatically renegotiated when the tunnel expires.|
|DHCP-IPsec||Select Enable if the FortiGate unit acts as a dialup server and FortiGate DHCP server or relay will be used to assign VIP addresses to FortiClient dialup clients. The DHCP server or relay parameters must be configured separately.
If the FortiGate unit acts as a dialup server and the FortiClient dialup client VIP addresses match the network behind the dialup server, select Enable to cause the FortiGate unit to act as a proxy for the dialup clients.
This is available only for Phase 2 configurations associated with a dialup Phase 1 configuration. It works only on policy-based VPNs.
The Phase 2 SA has a fixed duration. If there is traffic on the VPN as the SA nears expiry, a new SA is negotiated and the VPN switches to the new SA without interruption. If there is no traffic, however, the SA expires (by default) and the VPN tunnel goes down. A new SA will not be generated until there is traffic.
The Autokey Keep Alive option ensures that a new Phase 2 SA is negotiated, even if there is no traffic, so that the VPN tunnel stays up.
By default, the Phase 2 security association (SA) is not negotiated until a peer attempts to send data. The triggering packet and some subsequent packets are dropped until the SA is established. Applications normally resend this data, so there is no loss, but there might be a noticeable delay in response to the user.
If the tunnel goes down, the auto-negotiate feature (when enabled) attempts to re-establish the tunnel. Auto-negotiate initiates the Phase 2 SA negotiation automatically, repeating every five seconds until the SA is established.
Automatically establishing the SA can be important for a dialup peer. It ensures that the VPN tunnel is available for peers at the server end to initiate traffic to the dialup peer. Otherwise, the VPN tunnel does not exist until the dialup peer initiates traffic.
The auto-negotiate feature is available through the Command Line Interface (CLI) via the following commands:
config vpn ipsec phase2
set auto-negotiate enable
Installing dynamic selectors via auto-negotiate
The IPsec SA connect message generated is used to install dynamic selectors. These selectors can now be installed via the auto-negotiate mechanism. When phase 2 has auto-negotiate enabled, and phase 1 has mesh-selector-type set to subnet, a new dynamic selector will be installed for each combination of source and destination subnets. Each dynamic selector will inherit the auto-negotiate option from the template selector and begin SA negotiation. Phase 2 selector sources from dial-up clients will all establish SAs without traffic being initiated from the client subnets to the hub.
Select this option if the FortiGate unit assigns VIP addresses to FortiClient dialup clients through a DHCP server or relay. This option is available only if the Remote Gateway in the Phase 1 configuration is set to Dialup User and it works only on policy-based VPNs.
With the DHCP-IPsec option, the FortiGate dialup server acts as a proxy for FortiClient dialup clients that have VIP addresses on the subnet of the private network behind the FortiGate unit. In this case, the FortiGate dialup server acts as a proxy on the local private network for the FortiClient dialup client. When a host on the network behind the dialup server issues an ARP request that corresponds to the device MAC address of the FortiClient host (when a remote server sends an ARP to the local FortiClient dialup client), the FortiGate unit answers the ARP request on behalf of the FortiClient host and forwards the associated traffic to the FortiClient host through the tunnel.
This feature prevents the VIP address assigned to the FortiClient dialup client from causing possible arp broadcast problems — the normal and VIP addresses can confuse some network switches by two addresses having the same MAC address.