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

Reminder

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

upgrade
Knowledge Base

Encapsulation order for IPsec at AR2240C

Publication Date:  2018-03-23  |   Views:  808  |   Downloads:  0  |   Author:  uWX507869  |   Document ID:  EKB1001427090

Contents

Issue Description

Huawei AR2240C (V200R009C00SPC300) works in Server mode for L2TP over IPSec (IKE v2) remote connections.
For connection of other-vendor device was found problem: pure L2TP works ok, but L2TP over IPSec connection cannot be established.

AR2240C Configuration:
#
l2tpenable
#
ike local-name IKE
#
license active accept agreement
license function dsvpn
license function sece
#
IPsec proposal IPSEC_POLICY
esp authentication-algorithm sha1
 esp encryption-algorithm 3des
#
ike proposal default
encryption-algorithm 3des
 dh group2
 authentication-algorithm sha1
 authentication-method pre-share
integrity-algorithm hMAC-sha1-96
 prf hMAC-sha2-256
#
ike proposal 1
encryption-algorithm 3des
 dh group14
 authentication-algorithm sha1
 authentication-method pre-share
integrity-algorithm hMAC-sha1-96
 prf hMAC-sha1                          
#
ike peer IPSEC_POLICY
undo version 1
pre-shared-key ||||||||||||
ike-proposal 1
undo nat traversal
#
IPsec policy-template IPSEC_POLICY_PT 1
ike-peer IPSEC_POLICY
proposal IPSEC_POLICY
#
IPsec policy IPSEC_POLICY 1 isakmp template IPSEC_POLICY_PT
#
IP pool L2TP_POOL
gateway-list 10.33.1.1
 network 10.33.1.0 mask 255.255.255.0
#
aaa
local-user l2tp_user PASSWORD cIPher ||||||||
local-user l2tp_user privilege level 0
local-user l2tp_user service-type ppp
#
interface GigabitEthernet0/0/9.710
descrIPtion == UPLINK to BKS ==
dot1q termination vid 710
IP address x.x.x.x 255.255.255.128
nat outbound 3999
 IPsec policy IPSEC_POLICY
#                                       
l2tp-group 1
undo tunnel authentication
allow l2tp virtual-template 1          
#

Other vendor peer-device configuration:
/interface l2tp-client
add allow=chap,mschap1,mschap2 comment=ERT1 connect-to=x.x.x.x disabled=\
    no IPsec-secret=xxx 2 keepalive-timeout=disabled max-mru=1500 \
    max-mtu=1500 name=ERT1_L2TP PASSWORD=xxx user=xxx
/IP IPsec policy
add dst-address=x.x.x.x/32 dst-port=1701 protocol=udp sa-dst-address=\
    x.x.x.x sa-src-address=192.168.1.220 src-address=192.168.1.220/32 \
    src-port=1701 tunnel=yes
/IP IPsec peer
add address=x.x.x.x/32 enc-algorithm=aes-256,aes-192,aes-128,3des \
exchange-mode=ike2 generate-policy=port-strict secret=xxx
/IP IPsec proposal
set [ find default=yes ] auth-algorithms=sha1,md5 enc-algorithms=\
    aes-256-cbc,aes-192-cbc,aes-128-cbc,3des,des
 
[admin@MikroTik] > IP IPsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
 0  E spi=0 src-address=192.168.1.220:1701 dst-address=x.x.x.x:1701
      state=larval add-lifetime=0s/30s replay=0

Alarm Information

Huawei AR2240C logs:
<189>1 2018-01-24T12:39:07.093701+03:00 2018-1-24 09 - - - 09:39:13 ERT1 %%01IKE/5/IKE_NEGO_FAIL(l)[5254]:IPSec tunnel negotiation fails. (IfIndex=26, SeqNum=0, PeerAddress=x.x.x.x, PeerPort=4500, Reason=malformed message)

 

Handling Process

For troubleshoot this info was enabled debugging for IPSec:
<>debugging ikev2 all
<>debugging ipsec
<>debugging ipsec all
<> t m
Then we try to connect again and found encapsulation order is follow:
<ERT1>debugging ipsec
Jan 26 2018 15:11:05.588.3+03:00 ERT1 IKE/7/IKE_Debug:
IKE_INFO 47:6606 Recv Msg: NOTIFY | NOTIFY | NONCE | KE | SA |

So, encapsulation order of peer device is: NOTIFY | NOTIFY | NONCE | KE | SA

Root Cause

The encapsulation order of NOTIFY and SA for the IKE V2 INIT negotiation packets sent from the peer device is not standart order of encapsulation and does not meet Huawei requirements, so the negotiation fails.

Solution

At AR routers encapsulation order is fixed and we cannot change it.
AR encapsulation order is  SA | KE| NONCE | NOTIFY | NOTIFY | , that we can get from traffic dump:

 To solve this issue it needed to adjust client-side encapsulation order in accordance to Huawei requirements (SA| KE| NONCE | NOTIFY | NOTIFY ).