AR router maintenance guide - FAQ (VPN)

The device supports GRE, IPSec, VLL, L2TP, and SSL VPN.

Starting from V200R002C00, the device supports L2TP and SSL VPN. Starting from V200R003C00, the device supports VLL.

GRE tunnels can encapsulate unicast and multicast packets.

IPSec tunnels can only encapsulate and encrypt unicast packets. To encrypt multicast packets, use GRE over IPSec.

As a point-to-point Layer 2 tunneling technology based on MPLS, VLL allows data packets to traverse networks using different media.

L2TP tunnels transmit PPP packets over the public network, and support user authentication and remote access, but have low security. You can use L2TP over IPSec to improve security.

Based on the HTTPS protocol, SSL VPN uses the data encryption, user identity authentication, and message integrity check mechanisms of the SSL protocol to ensure secure remote access to enterprise intranets.

If you set an MTU value on a GRE tunnel interface, forwarding of data packets through the GRE tunnel will be affected. If the packet length exceeds the MTU value on the tunnel interface, the device fragments the packet.

Generic routing encapsulation (GRE) supports the following unicast routing protocols:

• Static routing protocols

• OSPF

• ISIS

• RIP

• BGP

GRE supports protocol independent multicast (PIM), a multicast protocol.

The causes for a GRE tunnel establishment failure are as follows:

• Interfaces on both ends of a tunnel use different tunnel encapsulation modes.

• An IP address, a tunnel source address, and a tunnel destination address are not configured for interfaces on both ends of the tunnel. The source address of one end is not the destination address of the other end.

• There is no reachable route between the tunnel source and destination addresses.

• Keepalive detection is configured, but parameters on both ends of a tunnel are inconsistent.

• GRE key configurations on both ends of a tunnel are inconsistent.

IPSec supports Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols. The differences between these protocols are:

• AH: provides data origin authentication, data integrity check, and the anti-replay services. The sender performs the hash algorithm on the IP payload and all header fields of an IP packet except for variable fields to generate a message digest. The receiver recalculates the message digest according to the received IP packet and compares the two message digests to determine whether the IP packet has been modified during transmission. AH does not encrypt the IP payload. AH is applicable to transmit non-confidential data.

• ESP: encrypts the IP payload in addition to providing all the functions of AH. ESP can encrypt and authenticate the IP payload but does not protect the IP packet header. ESP can be used to transmit confidential data.

AH and ESP can be used independently or together. When AH and ESP are used together, ESP encapsulation and then AH encapsulation are performed on an IP packet to enhance security.

The number of IPSec tunnels supported by the AR depends on the version.

A security association (SA) supports the following types of lifetimes:

• The time-based lifetime: the period of time an SA can exist after it is established.

• The traffic-based lifetime: the maximum traffic volume that an SA can process.

When the specified time or traffic volume is reached, the SA becomes invalid. When the SA is about to expire, IKE will negotiate a new SA for IPSec. In this manner, a new SA is established when the old SA becomes invalid. Before the new SA is established, the two ends use the old SA to protect data flows. When the new SA is established, the two ends immediately use the new SA.

To rectify the failure, perform the following operations:

1. Perform the ping operation to check the public network connectivity.

2. If the IPSec tunnel is established through IKE negotiation, run the display ike sa command to check whether the IKE SA is successfully established.

3. Wait about 10 seconds and run the display ipsec sa command again.

4. Run the display interface brief command to verify that the interface bound to the IPSec policy is in the Up state.

5. Verify that IPSec is configured correctly.

Yes.

When the local interface has a dynamic IP address and the peer interface has a fixed IP address, configure an IPSec policy template on the peer interface to implement IPSec.

The following uses the 3G interface as an example to implement IKE auto negotiation.

Dynamic IP address

#
ike peer peer_3g_1  
 pre-shared-key cipher %@%@VsiNAx"H;$1jaO'QE%[=I\O6%@%@  //Set the pre-shared key to huawei.
 remote-address 10.5.39.160  //Specify a fixed IP address for the peer end.
#
ipsec proposal ipsec  //Use the default security parameters.
#
ipsec policy ipsec 1 isakmp  //Configure an IPSec policy and import the policy on a 3G interface.
 security acl 3000
 ike-peer peer_3g_1
 proposal ipsec
# 
interface Cellular0/0/0 
 ipsec policy ipsec   //Configure the IPSEC policy on the 3G interface.
# 
acl 3000  //Configure ACL rules. The IPSec policy protects packets that match ACL rules.
...
#

Fixed IP address

# 
ipsec proposal ipsec 
# 
ike peer peer_3g_2   //The peer end uses a dynamic IP address.
 pre-shared-key cipher %@%@VsiNAx"H;$1jaO'QE%[=I\O6%@%@  //Set the pre-shared key to huawei.
# 
ipsec policy-template temp 1  //Configure an IPSec policy template.
 ike-peer peer_3g_2
 proposal ipsec 
# 
ipsec policy ipsec 1 isakmp template temp  //Configure an IPSec policy and bind the policy to the template.
# 
interface GigabitEthernet 1/0/0  //This interface uses a fixed IP address.
 ipsec policy ipsec
 ip address 10.5.39.160 255.255.255.255 
#

NOTE:

In V200R002C00 and earlier versions, run the pre-shared-key huawei command to set the pre-shared key to huawei.

In V200R008C00 and later versions, the v1 and v2 parameters are deleted from the ike peer peer-name [ v1 | v2 ] command. To configure the IKE protocol, run the version { 1 | 2 } command.

The AR supports L2TPv2 from V200R002C00.

L2TP inherits the advantages of the L2F and PPTP protocols. It is widely used to connect a single or a small number of remote terminals to an enterprise intranet through the public network.

Currently, the device supports only L2TP, and is able to forward PPTP and L2F packets.

L2TP can be used in scenarios where active and standby LNSs are deployed. When the active LNS fails, services are switched to the standby LNS. However, L2TP connection requests initiated by the LAC cannot reach the active LNS. To ensure that L2TP connection requests are sent to the standby LNS, you must configure the IP address of the standby LNS on the LAC, so that when the first IP address is unreachable, the LAC sends the request packets to the address of the standby LNS.

You can configure IP addresses of a maximum of four LNSs on the LAC.

The number of L2TP tunnels that can be established on a device is shown as follows.

The causes of the L2TP dial-up failure are as follows:

• The firewall deployed on the public network or the built-in firewall on the PC discards L2TP packets.

• The corresponding L2TP port, usually UDP port 1701, is disabled or occupied. For example: ACL or NAT is configured on the port.

• The user name and password configured on the LAC are incorrect, or no related user is configured on the LNS. Check whether the user password in the AAA view is set to cipher but not irreversible-cipher format.

• The configuration address, such as the static address of the VT interface, is incorrect.

• The tunnel authentication modes are different.

• LCP renegotiation is not configured.

• The address pool cannot meet user requirement or no address pool is configured.

• No gateway address is reserved in the IP address pool, so that the gateway address is allocated to users.

• The LAC and LNS have no reachable routes to each other.

• An incorrect remote tunnel name is specified in the L2TP group view.

• The authentication domain is incorrectly configured.

• The control packets sent by the PC client do not carry the SQ number, so that the L2TP negotiation fails.

• When IPSec encryption is used, the IPSec parameters on both ends are different.

When the L2TP dialup is successful, private networks may fail to communicate due to the following causes:

• The firewall is enabled on the internal host.

• The local subnet and the remote intranet are on the same network segment.

• The L2TP dialup address is on the same network segment as the LAN user, but the proxy ARP function is disabled.

• The MTU value on the virtual interface is improper. The MTU value plus all the header lengths cannot exceed interface MTU. Otherwise, the packets will be discarded if the device does not support packet fragmentation.

• The TCP MSS value on the virtual interface is improper. Ensure that the MSS value plus all the header lengths cannot exceed the MTU. Otherwise the transmission of packets might be affected.

• LCP renegotiation is not configured.

• The LAC and LNS have no reachable routes to each other.

• The tunnel authentication is not configured.

• When IPSec encryption is used, the data flow does not match the ACL.

L2TP encapsulation increases the length of IP packets. When the packet length exceeds the link MTU, the sender needs to fragment the packets, which are then reassembled by the receiver. Fragmentation and reassembly consume CPU resources. When many packets need to be fragmented, CPU resources will become insufficient, lowering the access speed and causing packet loss.

Therefore, the MTU value on the VT interface must be less than or equal to the encapsulation header length of L2TP packets (42 bytes with a serial number, and 38 bytes otherwise) subtracted from the MTU value on the physical outbound interface (1500 bytes by default). For example, when the MTU value on the physical outbound interface is 1500 bytes by default, and the encapsulation header length of L2TP packets is 42 bytes, the value must be less than or equal to 1458 bytes.

If a physical interface performs packet fragmentation again after the packet is fragmented on the corresponding VT interface, device performance degrades. To prevent this case, you are advised to set the MTU value of the VT interface to the range of 1400 to 1450.

When the TCP packets encapsulated by L2TP exceed the link MTU, the ping operation to the private network will be delayed. In this case, web pages may not be displayed normally or remote logins may fail. You are advised to adjust the TCP MSS value on the VT interface to ensure that the length of TCP packets encapsulated by L2TP is less than or equal to the link MTU.

The possible cause for an L2TP over IPSec tunnel establishment failure between a PC running the Windows 7 or XP operating system and the device is that the system registry is not modified.

The following describes how to modify the registry of the Windows 7 operating system so as not to use digital certificate authentication.

NOTE:

The operations in the 64-bit Windows 7 operating system are the same as those in the 32-bit operating system.

1. Choose Start > cmd and enter regedit to open the registry.

2. Choose HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters in the left, right-click a blank area in the right, and choose New > DWORD (32–bit) Value to generate the New Value #1 file.

3. Right-click New Value #1 and choose Rename to rename the file as ProhibitIpSec.

4. Right-click the ProhibitIpSec file and choose Modify.

5. In the displayed Edit DWORD (32-bit) Value dialog box, set Value data to 1 and select Hexadecimal under Base, as shown in Figure 2-11.

6. Restart the PC to make the configuration take effect.

Figure 2-11  Registry Editor

The device administrator can run the qos gts cir cir-value [ cbs cbs-value ] command on the interface from which L2TP users go online. The administrator is advised to set cir-value based on the actual rate of the physical interface and cbs-value to 1500. This can prevent invalidation of L2TP user detection packets in case of traffic burst.

Possible cause:

If the VT interface on the LNS is configured with a non-32-bit subnet mask, the VT interface forwards all the packets matching the network segment route if there is only one VPN dial-up user, even if the packets are not destined for end users. If there are multiple VPN dial-up users, the device does not forward the packets because it cannot determine the destined VPN user based on the network segment route.

Solution:

Set the subnet mask of the VT interface to 32 bits.

By default, the tunnel authentication password is empty on a router.

For the sake of security, L2TP tunnel authentication is enabled by default. In case of network connectivity test or receiving a connection request sent by an unknown remote end, disable L2TP tunnel authentication. It is recommended that you enable L2TP tunnel authentication.

If a PC initiates L2TP dial-up, you are advised to configure the undo tunnel authentication command on the LNS to disable L2TP tunnel authentication.

Starting from V200R002C00SPC200, the device supports this function.

After L2TP is configured on the device, users can dial up successfully after several attempts and error 691 is displayed during the attempts. The cause is that the device supports only 16-byte challenge messages. When challenge messages are not of 16 bytes, CHAP authentication fails and error 691 indicating user name or password error is displayed. Configure L2TP re-negotiation so that the LNS and client can negotiate the 16-byte challenge messages.

When configuring the L2TP function, the LAC cannot set up a tunnel with the LNS. How can I quickly locate the fault?

1. Run the start l2tp command on the LAC to check whether there is a reachable route to the LNS. If no, configure a reachable route to the LNS.

2. Check the L2TP configuration on the LNS and delete the parameter remote specified in the allow l2tp command. If an L2TP tunnel can be established successfully, the LAC cannot set up a tunnel with the LNS because the tunnel name on the LAC is incorrect or the tunnel name specified by the LNS is incorrect. Use either of the following methods to solve this problem:

• Run the tunnel name command on the LAC to set the local tunnel name to the value of the parameter remote specified by the allow l2tp command on the LNS.

• Run the allow l2tp command on the LNS to change the value of the parameter remote to the tunnel name configured on the LAC. If no local tunnel name is configured using the tunnel name command on the LAC, the value of the parameter remote is the device name of the LAC.

The LAC authenticates access users. After the users are authenticated, the LAC sends authentication information to the LNS which determines whether the users are valid users.

If the LAC is trusted by the LNS, you can run the authentication-mode none command in the authentication scheme view of the LNS to set the authentication mode to non-authentication. If the command is configured, the LNS does not perform second authentication on remote users.

To log out an L2TP user, use either of the following methods:

• Run the reset l2tp tunnel command to forcibly disconnect a specified L2TP tunnel connection and all sessions in the tunnel.

• Run the reset l2tp session command to forcibly disconnect a specified L2TP session.

When a PC functions as the LAC, the LAC name is the computer name.

If the computer name of the PC exceeds 30 characters, use the first 30 characters as the LAC name.

Starting from V200R002C00SPC200, the device supports this function.

NOTE:

The Windows 7 operating system is used as an example.

The SSL VPN gateway runs on the HTTPS server. The possible causes are as follows:

• The browser has no root certificate of the HTTPS server installed.

• The browser has an incorrect root certificate of the HTTPS server installed.

Solution 1:

1. When you open the web login page of the SSL VPN gateway, the system displays the root certificate.

2. Install the root certificate to the browser.

   Choose Install Certificate > Next > Place all certificates in the following store > Browse, select Trusted Root Certification Authorities, and click OK.

Solution 2:

1. Manually obtain the correct root certificate of the HTTPS server. Contact the enterprise network administrator.

2. Save the root certificate to the local device.

3. Install the root certificate to the browser.

   Choose Install Certificate > Next > Place all certificates in the following store > Browse, select Trusted Root Certification Authorities, and click OK.

Outlook web access 2007 and 2010 addresses are configured through the web proxy function of SSL VPN. After a user logs in to Outlook Web Access 2010, the user fails to log in to Outlook Web Access 2007. The system displays a message indicating session timeout. This is because Outlook Web Access 2010 reserves user authentication information in the browser buffer and such information cannot be processed by Outlook Web Access 2007.

Layer 3 virtual private network (L3VPN) supports the following networks:

• Basic BGP/MPLS IP VPN

• Inter-AS VPN, including Option A, Option B, and Option C

The device supports this function from V200R005C00.

Run the reset mpls ldp command to reset LDP instances of public networks.

When the AS number in the Update message to be received by the EBGP-enabled device is the same as the AS number on the device, the device does not receive the Update message. This prevents routing loops. In some scenarios, the device needs to receive a Update message that carries the same AS number as the AS number on the device. In Hub and Spoke networking, when the Hub-PE and Hub-CE use EBGP, the Update message received by the Hub-CE contains the AS number of the Hub-PE. To prevent the Hub-PE from discarding such Update message, run the peer allow-as-loop command to set the number of times for the repeated AS number.

The device does not support static MPLS IP VPN when PEs advertise private routes. The device can use only MP-BGP to allocate labels to private routes; however, VPN labels cannot be manually specified and the remote PE cannot be specified as the neighbor.

When the same traffic needs to be sent to the headquarters but an IPSec tunnel exists between the branch and headquarters to protect access traffic from existing users, a new IPSec tunnel cannot be established before the old IPSec tunnel is torn down after it is restarted on the headquarters device.

To solve the problem, run the ipsec remote traffic-identical accept command to enable new users with the same IPSec rule to quickly access the headquarters. This function quickly ages an existing IPSec SA between the branch and headquarters to re-establish a new IPSec tunnel.

An SSL VPN client only supports 32-bit operating system and 32-bit JRE Java.

After A2A VPN is deployed, A2A VPN packets are discarded if their size exceeds the interface MTU but the DF flag is not set to 0. To solve the problem, run the ipsec df-bit clear command to enable fragmentation of A2A VPN packets.