Configuring L2TP over IPSec Using the Web UI

Configure an L2TP over IPSec Policy

1. Choose Network > L2TP over IPSec.
2. Configure the basic parameters of the IPSec policy.

   Parameter	Description
   Policy Name	Specify a name for the IPSec policy.
   Local Interface	Select an interface from the drop-down list on which the IPSec policy is to be applied. This interface can be a physical interface or a tunnel interface. The physical interface must be the interface the connects the local end to the peer gateway, and it is usually the WAN interface of the device. The local end uses this interface to establish a tunnel to the peer gateway.
   Local Address	Select an IP address for the local gateway to establish a tunnel to the peer gateway. If the Local Interface has several local IP addresses, select an IP address accessible from the peer gateway. In a hot standby network, select a virtual IP address for the local interface.
   Peer Address	Specify the IP address or domain name of the peer gateway, for example, 1.1.1.1 or test1.com. In common practices, the IP address or domain name must be specified to restrict the access from other gateways. Leave this parameter unspecified if the peer gateway does not have a fixed IP address or domain name. In this case, the local gateway cannot initiate negotiations.

   

   The link to [Add Security Policy] is provided on the web UI. You can click the link to access the Add Security Policy page and rapidly create a security policy based on the configured IPSec policy to permit tunnel negotiation packets. In addition, the Add Security Policy page support Switch Source and Destination and OK and Copy for configuring security policies for forward and return traffic.

3. Configure tunnel authentication.

   There are three IPSec tunnel authentication modes, and some of their parameter values are different.

   • Pre-shared key

     Parameter	Description
     Authentication Type	Pre-shared key
     Key Type	There are two options. Select one based on the requirement of IPSec tunnel peers for the pre-shared key: Identical: All tunnel peers use the same pre-shared key. Different: Each tunnel peer exclusively uses a pre-shared key. If an Identical pre-shared key is disclosed, all tunnels using this key are at risk of data leaks. The Different key type does not have this problem. The Different key type is recommended for a P2MP tunnel. That is, each tunnel peer uses a unique pre-shared key.
     Identical
     Pre-shared key	This parameter is available if Key Type is set to Identical. Enter the pre-agreed key.
     Local ID	The local ID identifies the local gateway for authentication by the peer gateway. The type and value must be the same as those of the Peer ID of the peer device. If you select Pre-shared key in Authentication Type, this parameter has the following options: IP Address: If this option is selected, the IP address specified in Local Address is used as the local ID. Name: If this option is selected, the local gateway name is used as the default ID. You can specify another name. User-FQDN: If this option is selected, the local gateway name is used as the default ID. You can specify another name. ESN: If this option is selected, the local gateway ESN is used as the local ID. You cannot specify another name.
     Peer ID	The peer ID identifies the peer device. Obtain this parameter value from the administrator of the peer device. The type and value must be the same as the Local ID value set on the peer device. If the device accepts requests from any peer IDs, select Any. If the device does not specify ID types and requires only matched strings, select Any Type.
     Different
     Default Key	The multi-key mode supports two modes of setting a pre-shared key. The pre-shared key is set based on the tunnel peer ID. In this mode, various tunnels use different pre-shared keys. Multiple tunnel peers share a default key. In a multi-key scenario, most users expect various peers to use different pre-shared keys. However, there are also exceptions in which users expect multiple peers to use one pre-shared key. Therefore, a default key mode is provided for the exceptions. To use a default key, click Enable and set the default key.
     Local ID	The local ID identifies the local gateway for authentication by the peer gateway. The type and value must be the same as those of the Peer ID of the peer device. If you select Pre-shared key in Authentication Type, this parameter has the following options: IP Address: If this option is selected, the IP address specified in Local Address is used as the local ID. Name: If this option is selected, the local gateway name is used as the default ID. You can specify another name. User-FQDN: If this option is selected, the local gateway name is used as the default ID. You can specify another name. ESN: If this option is selected, the local gateway ESN is used as the local ID. You cannot specify another name.
     Default Peer ID	This parameter value is displayed when you enable Default Key. The peer ID identifies the peer device. Obtain this parameter value from the administrator of the peer device. The type and value must be the same as the Local ID value set on the peer device. If the device accepts requests from any peer IDs, select Any. If the device does not specify ID types and requires only matched strings, select Any Type.
     IKE User Information List	This parameter is available if Pre-shared key is set to Different. Click Add and configure the user information list. Name: name of an IPSec tunnel peer. The name is configured on the local end only to identify a tunnel peer. The two ends of a tunnel are not associated, and configuration consistency between them is not required. Description: description of an IPSec tunnel peer. The description is used to supplement tunnel peer information. Virtual System: Specifies the virtual system, which used to establish IPSec tunnels with the peer device. Users encrypted traffic will be forwarded from the root system to the virtual system. Peer ID Type/Peer ID: ID of a tunnel peer. The ID is used for identity verification. If the device accepts requests from any peer IDs, select NONE. If the device does not specify ID types and requires only matched strings, select Any Type. Pre-shared key: key negotiated by administrators on both ends. Specifies The Assigned IP: IP address assigned to a tunnel peer. Set this parameter if a tunnel peer requires that a specified IP address be assigned. Primary DNS Server: DNS server allocated to a tunnel peer. Set this parameter if a tunnel peer requires that a specified DNS server be used. Secondary DNS Server: When domain name resolution by the primary DNS server fails, the DNS client requests the secondary DNS server for domain name resolution. The addresses of the primary and secondary DNS servers must be different. NOTE: If configured Default Key and Pre-shared key in the IKE User Information List at the same time. The pre-shared key configured in the IKE User Information List is preferred.

   • RSA signature

     Parameter	Description
     Authentication Type	RSA signature
     Certificate	This parameter is available only when you select RSA signature in Authentication Type. Select the public key certificate when this parameter is available. Certain information in the certificate is to be sent to the peer gateway for authentication. For details about certificate uploading, see Local Certificate.
     Local ID	After the certificate is loaded, select the local ID type. The system automatically extracts the corresponding file value from the certificate as the local ID. The local ID can be one of the following items (corresponding to the specific fields in the certificate): IP: The IP Address field value serves as the local ID. DN: The Subject field value serves as the local ID. Name: The Commonname field value serves as the local ID. User-FQDN: The Email field value serves as the local ID.
     Peer ID	The peer ID identifies the peer device. Obtain this parameter value from the administrator of the peer device. The type and value must be the same as those of the local ID specified on the peer device. Select Any if no authentication is required. If only string match is required, select Any Type.

   • RSA digital envelope

     Parameter	Description
     Authentication Type	RSA digital envelope
     Local Certificate	To set this parameter, select the local certificate requested from the CA for the device. Some information in the local certificate is sent to the peer for authentication during tunnel establishment.
     Peer Certificate	To set this parameter, specify the certificate used by the peer device. During tunnel establishment, the local device compares the specified peer certificate with the certificate information sent by the peer to authenticate the peer.

   • SM2 digital envelope

     Parameter	Description
     Authentication Type	SM2 digital envelope
     Encryption Realm	Select the PKI realm of the encryption certificate requested and imported from the SM2 server.
     Signature Realm	Select the PKI realm of the signature certificate requested and imported from the SM2 server. In addition, the CA certificates used by the devices at both ends need to be imported to this signature realm.

4. Configure the authentication domain of the client and the address pool for the client.

   Parameter	Description
   L2TP Authentication Mode	The authentication mode can be set to PAP or CHAP.
   User address Pool	Address pool used to allocate private IP addresses to users. Select an existing address pool or click Add to create an address pool. To create an IP address pool, you can use either of the following ways: Select Add Address Pool from the drop-down list of this parameter. Click Object > IP Pool, then click Add and add an address pool in the page that is displayed.
   Split Tunnel	After the function is enabled, the peer device can directly access the local LAN or Internet while accessing the enterprise intranet over a VPN tunnel, implementing the isolation of encrypted traffic and common traffic. NOTE: This function is supported only by IKEv1.

5. Configure the data flow to encrypted.

   In common cases, only a bunch of data flows need to be encrypted before they are sent to the peer, and the rests are sent directly through the Internet. To avoid those data flows to be transmitted directly through the Internet entering the tunnel, you need to configure certain rules to restrict the them.

   • You can configure multiple rules in a list. Data flows match the rules from top to bottom. If a match is found, data flows are processed according to the specified action, and the matching process ends.

   Under Data Flow to Encrypted, select IPv4 or IPv6 for Address Type and click Add.

   Parameter	Description
   Source Address/Address-set	Specify the source address from which the data flows to be encrypted through the tunnel are originated. In common practices, the source address is usually the address of the intranet subnet to be protected. You can enter an IP address (such as 192.168.1.1), network segment (such as 192.168.1.0/24 or 192.168.1.0/255.255.255.0), or address group. Address groups are usually used when an intranet has multiple network segments, so as to reduce encrypted data flow configuration and increase configuration efficiency. Members cannot be address groups with consecutive IP address segments. Address-set is not supported, when Address Type is set to IPv6.
   Destination Address/Address-set	Specify the destination address for which the data flows to be encrypted through the tunnel are destined. In common practices, the destination address is usually the address of the requested subnet on the peer intranet. You can enter an IP address (such as 10.1.1.1), network segment (such as 10.1.1.0/24 or 10.1.1.0/255.255.255.0), or address group. Address groups are usually used when an intranet has multiple network segments, so as to reduce encrypted data flow configuration and increase configuration efficiency. Members cannot be address groups with consecutive IP address segments. Address-set is not supported, when Address Type is set to IPv6.
   Protocol	Specify the protocol through which the data flows are transmitted, and then the TCP or UDP port for encrypting traffic of specific service. For example, you can specify TCP port 80 to encrypt HTTP traffic, or UDP port 69 to encrypt TFTP traffic. If you do not know the protocol and port or there is no need to perform protocol-based restriction, leave this parameter unspecified or set it to any.
   Source Port	This parameter is available if you select TCP, SCTP or UDP in Protocol. Specify the source port number from which the data flows to be encrypted through the tunnel are originated.
   Destination Port	This parameter is available if you select TCP, SCTP or UDP in Protocol. Specify the destination port number for which the data flows to be encrypted through the tunnel are destined.
   Action	Specify the action for data flows that match the preceding conditions. Encrypt indicates that the data flows are allowed to be encrypted through the tunnel. Do not Encrypt indicates that the data flows are not allowed to be encrypted through the tunnel. The Do not Encrypt action is used to exempt traffic of some clients from encryption. For example, to encrypt the traffic from all hosts on subnet 192.168.1.0/24 except a host at 192.168.1.2, configure a rule for exempting traffic of the host at 192.168.1.2 from encryption and a rule for encrypting traffic of hosts on subnet 192.168.1.0/24.

   

   • The link to [Add Security Policy] is provided on the web UI. You can click the link to access the Add Security Policy page and rapidly create a security policy based on the configured data flows to be encrypted to permit encrypted traffic. In addition, the Add Security Policy page support Switch Source and Destination and OK and Copy for configuring security policies for forward and return traffic.
   • To ensure that data flows enter the tunnel correctly and the negotiation succeeds, you are advised to specify the information about the data flows to be encrypted. In the IPSec policy on the LNS, set Protocol to UDP and Source Port to 1701 for data flows to be encrypted.

   You can select Reverse Route Injection if necessary. If Reverse Route Injection is selected, the device automatically installs the routes pointed to the peer network. This function is usually configured on the HQ gateway connected to multiple branches.

   You can set the Priority if necessary. For example, if other routes to the same destination exist on the device, you can specify the same priority for them to implement load balancing, or different priorities to implement route backup.

6. Optional: Configure advanced parameters in security proposals.

   • If multiple types of terminals are allowed to access the intranet, select Accept proposal from peer device in IKE/IPSec Proposal to ensure the interconnections between the headquarters and clients. After that, the local end accepts the proposed algorithms and parameters when the peer device initiates a tunnel establishment request, improving the negotiation success ratio. In this circumstance, tunnel security is determined by the peer gateway, and no advanced parameters are required.

   • Even so, you still can adjust local configurations as required.

   Deselect Accept proposal from peer device in IKE/IPSec Proposal and expand Advanced to check the pre-defined sets of security proposal parameters. Modify the parameters in Advanced if the pre-defined sets cannot meet the requirement. All parameters except the SA timeout period must be set to the same values at both ends.

   You can select multiple algorithms for the security proposal. Then the tunnel peers will preferentially use the algorithm with the highest security for the IKE negotiation. On the web UI, the algorithms are ranked in descending order of their priorities from left to right.

   Expand Advanced.

   Parameter	Description
   IKE Parameters
   IKE Version	Select v1 or v2 to specify the version of the IKE protocol used in negotiations with the peer gateway. For details on IKE versions. If both versions are selected, the local end can respond to both IKEv1 and IKEv2 requests but initiate only IKEv2 requests.
   Negotiation Mode	Select the IKEv1 negotiation mode. Automatic: Both the main mode and aggressive mode are acceptable in the response to IKE requests, but only the main mode is acceptable in the initiation of IKE requests. Main Mode: Only the main mode is acceptable in the negotiation. Aggressive Mode: Only the aggressive mode is acceptable in the negotiation.
   Encryption	Select an encryption algorithm as required. The AES algorithm has higher security than DES and 3DES and delivers more complicated calculation than 3DES. Compared with DES, 3DES provides higher security but lower encryption speed.
   Authentication	This parameter is available only after you select v1 in IKE Version. Select the algorithm used in data source authentication. NOTE: Only IKEv1 supports this parameter. In the case of interconnection with a device running V100R001, if the peer device uses IKEv1 for negotiation, ensure that Authentication on the local device is the same as Authentication on the peer device.
   Integrity Hash	This parameter is available only after you select v2 in IKE Version. Specify the algorithm for data integrity checks if IKEv2 is used in the negotiation.
   PRF	This parameter is available only after you select v2 in IKE Version. Select the algorithm used in data source authentication. NOTE: Only IKEv2 supports this parameter. In the case of interconnection with a device running V100R001, if the peer device uses IKEv2 for negotiation, ensure that PRF on the local device is the same as Authentication on the peer device.
   DH Group	Select the key exchange methods.
   SA Timeout	Set the IKE SA lifetime. When the lifetime is about to expire, the FW will negotiate a new SA. The new SA will immediately replace the old SA once it is established. Specify the timeout period, in seconds.
   IPSec Parameters
   Encapsulation Mode	Select an IPSec encryption mode. Automatic: Both the transport mode and tunnel mode can be used to respond to negotiation requests, but only the tunnel mode can be used to initiate negotiation requests. Tunnel: It is usually used in establishing tunnels between the VPN gateways. Transport: It is used in establishing tunnels between mobile devices and the VPN gateway.
   Security Protocol	Select an IPSec protocol. Encapsulating Security Payload (ESP): Encrypts and authenticates the packet payload. Authentication Header (AH): Authenticates the entire packet, but does not encrypt the packet. AH-ESP: Encrypts and authenticates the entire packet.
   ESP Encryption	This parameter is available if you select ESP or AH-ESP in Security Protocol. Select the algorithm used in data encryption. NOTE: During IKEv2 negotiation, do not select only Chinese cryptographic algorithms. Otherwise, the negotiation fails.
   ESP Authentication	This parameter is available if you select ESP or AH-ESP in Security Protocol. Select the algorithm used in data source authentication. NOTE: During IKEv2 negotiation, do not select only Chinese cryptographic algorithms. Otherwise, the negotiation fails.
   AH Authentication	This parameter is available if you select AH or AH-ESP in Security Protocol. Select the algorithm used in data source authentication. This parameter is available if you select ESP or AH-ESP in Security Protocol. Select the algorithm used in data source authentication. NOTE: During IKEv2 negotiation, do not select only Chinese cryptographic algorithms. Otherwise, the negotiation fails.
   PFS	Select the key exchange methods. A greater group ID indicates a longer key and higher security. None indicates no extra key exchanges are to be performed.
   SA Timeout	The IPSec tunnel is renegotiated to ensure security when the establishment time or transmitted traffic volume reaches the specified threshold. Specify the idle period for SA renegotiation in Based on Time. Specify the traffic volume threshold in Based on Traffic. When either of the preceding conditions are met after an IPSec tunnel is established, IPSec SA renegotiates the tunnel. The renegotiation does not disconnect the currently available tunnel.
   Dead Peer Detection (DPD)
   Detection Mode	After Dead Peer Detection (DPD) is enabled, the local end sends DPD packets to detect whether the peer gateway is still alive. Available detection methods are as follows: Periodic: The local end resends DPD packets if no packet is received from the peer device within the period specified in Detection Interval. On-demand: The local end sends DPD packets only when the communication is required and no packet is received from the peer device within the period specified in Detection Interval. Enable or disable this function on both ends at the same time. A detection failure is logged if no response is received within the period specified in Retry Interval after the local end sends a DPD packet. After five consecutive detection failures, the peer is regarded to be down and the tunnel is automatically removed.
   Detection Interval	Specify a period in Detection Interval, in seconds.
   Retry Interval	Specify a period in Retry Interval, in seconds. This parameter is applicable only when the tunnel uses IKEv1.

7. Click Apply. The configured IPSec policies will appear in the policy list in network > IPSec > IPSec.

Viewing and Exporting Recommended Settings for the Peer Device