Limitations and Precautions for L2TP VPN

Hardware Requirements

The USG6635E/6655E, USG6680E and USG6712E/6716E can function only as the LNS, but not the LAC. Other models can function as both an LNS and an LAC.

License Requirements

The L2TP VPN function is not license-controlled.

Restrictions

• The SecoClient that supports this version has no longer evolved and cannot be downloaded from the Huawei Support website. The downloaded SecoClient can still be used. SecoClient configuration examples and common configuration problems are retained in the document. When users need to use the SSL VPN function through client access, see : VPN Client Download Description.

• In the NAS-Initiated and client-Initiated scenarios, the LNS allows PC users to use EAP authentication for access but does not allow mobile phone (both Android and iOS systems) users to use EAP authentication for access. In the call-LNS scenario, the LNS does not allow the LAC use EAP authentication for access.
• The FW does not establish any L2TP VPN tunnel with the Android 5.0 system of a user because the L2TP VPN function of the Android 5.0 system does not comply with the corresponding RFC.
• In the NAS-Initiated and client-Initiated scenarios, the LNS allows PC users to use EAP authentication for access but does not allow mobile phone (both Android and iOS systems) users to use EAP authentication for access. In the call-LNS scenario, the LNS does not allow the LAC use EAP authentication for access.
• The NAS-initiated scenario does not support the web UI-based configuration.
• The LNS does not allow the LAC to use the same IP address for dialup.
• L2TP does not support SPU capacity expansion. When the capacity of the SPU is expanded, online L2TP users go offline abnormally.
• If a DNS address needs to be assigned to the client, select the local authorization mode instead of the RADIUS server authorization mode.
• In L2TP scenarios, if tunnel detection is disabled, the tunnel that fails to be negotiated may not be aged in time when the link is abnormal. As a result, system resources are occupied. To avoid this, you are advised to enable tunnel detection.
• When the AD server is used for authentication in the L2TP scenario, the authentication mode can only be PAP. CHAP is not supported.
• L2TP VPN is a tunnel encapsulation protocol. The MAC address of an access user is lost after being transmitted over the LAC and then the public network. Therefore, the IP/MAC address binding function is not supported.

Precautions

• In the scenario in which L2TP VPN uses RADIUS authentication, and the LNS is a FW, the authenticationpacket that the LAC sends to the LNS may carry the Calling-Station-Id field. The LNS then processes the authentication packet accordingly. If the Calling-Station-Id field is less than 64 bits, the LNS will transparently forward the field to the RADIUS authentication server. If the Calling-Station-Id field exceeds 64 bits, the LNS will cut the excessive bits and forwards the field to the RADIUS authentication server. The possible changes that the LNS makes to the Calling-Station-Id field may cause the RADIUS authentication failure. Therefore, if a Calling-Station-Id field error is

  reported, you are advised to disable the Calling-Station-Id field on the LAC.

• When the Android 6.0 or Android 7.0 system of a mobile user establishes an L2TP over IPSec tunnel with the FW, the recommended

  IPSec authentication algorithm is SHA1. The Android 6.0 and Android 7.0 systems implement SHA2-256 based on the RFC draft. Therefore, when SHA2-256 is used to establish an IPSec tunnel, the devices at both ends of the tunnel cannot properly communicate.

• When the LAC starts, it pre-allocates some ports to the L2TP service. These ports will be used by the L2TP service. When the administrator specifies a user-defined port for the Portal, NTP, SNMP, NQA, or TWAMP protocol, the port may conflict with those pre-allocated by the LAC to L2TP. To prevent a port conflict, change the user-defined port number.
• In the NAS-Initiated and Client-Initiated scenarios, the peer device may use the cached IP address to go online without applying for an IP address. The cached IP address may be assigned to a new user. If this happens, IP address conflict occurs and the new user cannot go online. Therefore, when assigning an IP address to the peer end, you are advised to enable the function of preventing the peer end from using its own configured IP address.
• In hot standby mode, the server IP address and subnet mask must be configured on both the active and standby devices.
• In the Call-LNS scenario, when the local device functions as an LAC to connect to the peer LNS, the IP address of the virtual template (VT) interface on the peer LNS must be different from the IP address of the public network interface on the peer LNS. Otherwise, L2TP link flapping occurs, causing frequent connection interruptions.