Publication Date: 2019-07-18 | Views: 1676 | Downloads: 0 | Author: SU1001835942 | Document ID: EKB1000114546
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.
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
<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.
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 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:
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 200.1.1.2
#ip local policy-based-route redirect_l2tp