No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.

Knowledge Base

L2TP/IPSec tunnel negotiation fails when it is inittiated from particular locations

Publication Date:  2019-07-18  |   Views:  443  |   Downloads:  0  |   Author:  SU1001835942  |   Document ID:  EKB1000114546


Issue Description

Scenario: The router functions as a LNS and is configured to accept L2TP/IPSec connections from travelling employees. The employees can establish the tunnel and have access to the HQ resources but in particular cases, from particular ISP locations the L2TP/IPSec negotiation fails.

LNS Configuration:


 sysname RouterA  //Configure the device name.


 l2tp enable   //Enable L2TP.


ipsec proposal prop  //Configure an IPSec proposal.                             

 encapsulation-mode transport                                                  


ike proposal 5  //Configure an IKE proposal.                                   


ike peer peer1 v1  //Configure an IKE peer.                                             

 pre-shared-key cipher %^%#JvZxR2g8c;a9~FPN~n'$7`DEV&=G(=Et02P/%\*!%^%#  //Configure the authentication password in the pre-shared key to huawei, in cipher text. This command in V2R3C00 and earlier versions is pre-shared-key huawei, and the password is displayed in plain text.

 ike-proposal 5                                                                


ipsec policy-template temp1 10  //Configure an IPSec policy template.                                               

 ike-peer peer1                                                                

 proposal prop                                                                 


ipsec policy policy1 10 isakmp template temp1  //Configure an IPSec policy.   


ip pool lns  //Configure an IP address pool from which IP addresses are allocated to access PCs.                                                     


 network mask                                         


aaa  //Configure the local user name and service type on the PPPoE server.

 local-user huawei password cipher %#%#{_r}>NR>J,z3uPK9j*ZWTL~UQ:crN:FG{:0KBUE%%#%#

 local-user huawei privilege level 0

 local-user huawei service-type ppp


interface Virtual-Template1  //Configure the user name and password of the virtual PPP use, authentication mode, and IP address.

 ppp authentication-mode chap                                                   

 remote address pool lns                                                        

 ip address


interface vlanif 10

 ip address


interface GigabitEthernet1/0/0                                                        

 ip address                                       

 ipsec policy policy1                                                         


l2tp-group 1  //Configure an L2TP group and set attributes.                                     

 undo tunnel authentication                                                    

 allow l2tp virtual-template 1                                                 


ip route-static  //Configure a static route.

ip route-static




Alarm Information

The following error is received in the HUAWEI VPN CLIENT when the tunnel negotiation fails:

Handling Process

Troubleshooting steps:

 1st Step : Reproduce the problem and check where does the L2TP/IPSec negotiation interrupt. Helpful commands to check the stage where the problem appears:

Display ike sa command shows the status of the ike sa

Display ipsec sa command shows the status of the ipsec sa

Display l2tp tunnel command shows information about the established l2tp tunnels

Command output:

<HUAWEI>display ike sa

    Conn-ID  Peer            VPN   Flag(s)                Phase 


      254 0     RD                     2    

      253 0     RD                     1  


<HUAWEI>display ipsec sa



Interface: GigabitEthernet0/0/0

 Path MTU: 1500




  IPSec policy name: "policy1"

  Sequence number  : 1

  Acl group        : 0

  Acl rule         : 0

  Mode             : Template


    Connection ID     : 254

    Encapsulation mode: Tunnel

    Tunnel local      :

    Tunnel remote     :

    Flow source       : 17/1701

    Flow destination  : 17/26173


<HUAWEI>display l2tp tunnel


 Total tunnel : 0



According to the output, we can notice that the IPSec tunnel is successfully established but no information is displayed for L2TP.


2nd Step: To further identify why the  L2TP negotiation fails we can collect the debugging information for L2TP


<HUAWEI>terminal monitor

Info: Current terminal monitor is on.

<HUAWEI>terminal debugging

<HUAWEI>debugging l2tp all

<HUAWEI>debugging ppp all verbose



Nov 30 2015 00:28:31.259.5+01:00 HUAWEI L2TP/7/L2TDBG:

  Recv SCCRQ:

      Tunnel:1,  state:1




Nov 30 2015 00:28:31.259.6+01:00 HUAWEI L2TP/7/L2TDBG:

L2tp CONTRL:  Check SCCRQ MSG Type 1


Nov 30 2015 00:28:31.259.7+01:00 HUAWEI L2TP/7/L2TDBG:

  Check SCCRQ:

      Protocol version: 100

      Host Name :

      Vendor Name : HuaWei

      Framing capability : 3

      Remote TunnelID: 1

      Recv Window: 128


Nov 30 2015 00:28:31.259.20+01:00 HUAWEI L2TP/7/L2TDBG:

L2tp PAYLOAD:  Tunnel 1 first ctrl in send window, start ack timer


Nov 30 2015 00:28:31.259.21+01:00 HUAWEI L2TP/7/L2TDBG:

  Send SCCRP:

      Local Tunnel Name :

      Remote Tunnel Name :


Nov 30 2015 00:28:31.259.22+01:00 HUAWEI L2TP/7/L2TDBG:

L2tp CONTRL: Hello Timer:

 TunnelID 1, Timer :60 seconds.


Nov 30 2015 00:28:32.159.1+01:00 HUAWEI L2TP/7/L2TDBG:

L2tp CONTRL: The tunnel does not exist.


The debugging output states that the L2TP SCCRQ  packets are received from and that our router replies with a SCCRP without receiving a final SCCNP to complete the tunnel negotiation.


3rd Step: Investigate why the router does not receive any SCCNP in reply to the SCCRQ


In this specific case, we can see that the SCCRQ are received from which means that the router’s reply will be destined to the same IP address. Double checking the routing table of the LNS we can observe that it is configured with a static route for the subnet in the HQ LAN which has a higher preference than the default route. As a result, the router will forward the SCCRQ reply according to its routing table, sending it on the LAN side and being incapable of finishing the tunnel negotiation.


This behavior is a known limitation that can happen in L2TP scenarios in the situation where the PC initiating the tunnel has an IP address from the same subnet as the one used in the LNS side.


Since the IP addresses used in the HQ network at the moment when the tunnel is initiated are unknown and because we cannot control all the time what IP address we receive from the ISP on the PC from which we initiate the L2TP/IPSec tunnel, we can provide the following solution.


Implement policy based routing in order to redirect all the packets that are supposed to be sent on the L2TP tunnel (including SCCRP)  over the WAN interface. This can be done in the following way: 


1st Step : To redirect all the packets that are supposed to be sent over the L2TP tunnel we need to define an ACL which would select the traffic source from the 1701 UDP port


acl number 3333                                                                                               

 rule 5 permit udp source-port eq 1701   

2nd Step: Define a PBR to redirect the traffic on the WAN interface and apply it in the system view


policy-based-route redirect_l2tp permit node   5   

  if-match acl 3333                                                              

  apply ip-address next-hop 


ip local policy-based-route redirect_l2tp