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

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.                                                     

 gateway-list 192.168.1.1                                                      

 network 192.168.1.0 mask 255.255.255.0                                         

#

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 192.168.1.1 255.255.255.0

#

interface vlanif 10

 ip address 10.10.10.1 255.255.255.0

#

interface GigabitEthernet1/0/0                                                        

 ip address 200.1.1.1 255.255.255.0                                       

 ipsec policy policy1                                                         

#

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

 undo tunnel authentication                                                    

 allow l2tp virtual-template 1                                                 

# 

ip route-static 0.0.0.0 0.0.0.0 200.1.1.2  //Configure a static route.

ip route-static 10.1.1.0 255.255.255.0 10.10.10.1

#

return

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

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    200.1.1.2 0     RD                     2    

      253    200.1.1.2 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      : 200.1.1.1

    Tunnel remote     : 200.1.1.2

    Flow source       : 200.1.1.1/255.255.255.255 17/1701

    Flow destination  : 10.1.1.25/255.255.255.255 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.

2^nd 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

<HUAWEI>

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

  Recv SCCRQ:

      Tunnel:1,  state:1

      From: 10.1.1.25

      VPN-Index:0

<HUAWEI>

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

L2tp CONTRL:  Check SCCRQ MSG Type 1

<HUAWEI>

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

<HUAWEI>

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

<HUAWEI>

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

  Send SCCRP:

      Local Tunnel Name :

      Remote Tunnel Name :

<HUAWEI>

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

L2tp CONTRL: Hello Timer:

 TunnelID 1, Timer :60 seconds.

<HUAWEI>

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 10.1.1.25 and that our router replies with a SCCRP without receiving a final SCCNP to complete the tunnel negotiation.

3^rd 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 10.1.1.25 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 10.1.1.0/24 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: 

1^st 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   

2^nd 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 200.1.1.2 

ip local policy-based-route redirect_l2tp