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

IPSec tunnel between AR and Eudemon not created

Publication Date:  2019-07-17  |   Views:  1209  |   Downloads:  0  |   Author:  b84084128  |   Document ID:  EKB1001542346

Contents

Issue Description

IPSec tunnel between AR and Eudemon not created.
AR device: Huawei AR1220EV running V200R008C50SPC500.
Eudemon device: Eudemon1000E-X3 running V300R001C00SPCa00.

Alarm Information

On the AR side:
Feb 13 2018 15:38:53.410.1+00:00 XXX IPSEC/7/IPSEC-DEBUG:IPSEC_ERROR 20:1462 IKE is negotiating SA for IPsec policy: branch_vpn-1
Feb 13 2018 15:39:13.490.1+00:00 XXX IPSEC/7/IPSEC-DEBUG:IPSEC_ERROR 20:1462 IKE is negotiating SA for IPsec policy: branch_vpn-1

Handling Process

1) As customer provided only the configuration on both IPSec tunnel sides, I’ve checked that and noticed that the ACLs having the role to identify interesting traffic for the IPSec policy to apply integrity and/or confidentiality services were identical, so in customer case one was not matching traffic. From the Eudemon’s ip route-static 10.125.255.240 255.255.255.240 Tunnel29 description bthub5test command I assumed the 10.125.255.240/28 segment should be found behind AR1200’s G0/0/8 interface, case in which the Eudemon’s ACL source and destination needed to be interchanged.

 

Customer adjusted that accordingly, but mentioned problem is still present.


2) Asked customer to feedback display ike sa command output.

 

3) Then customer took traces and we noticed problem is that NAT Traversal ISAKMP messages 5 and 6 sent by the AR are not replied to by the Eudemon side.

 

Starting with ISAKMP message 5 of IKEv1, the Identity Authentication phase begins and in customer’s scenario here happens the fault, because the message is received from X.X.217.113, while the Eudemon expects the ISAKMP negotiation to be started by X.X.217.11.

 

Customer adjusted the remote address IP on the Eudemon side and then noticed problems with the larger packets.

4) Customer took traces and we found traffic requests over TCP session with three-way handshake negotiated MSS of 1460B were not replied by the device behind Eudemon, hence MSS or MTU limitation present on path.
 

20 Bytes for IP header
20 Bytes for TCP header
28 Bytes for GRE encapsulation  => MTU - IP - TCP - GRE  = 1500 – 20 – 20 – 24=1436B
56 Bytes for IPSEC => MSS for the GRE over IPSec tunnel = 1436 – 52 = 1384B


5) After noticing TCP retransmissions in the provided traces, suggested customer adjusting the TCP Maximum Segment Size to a value like 1200 bytes on the Eudemon side, using the command firewall tcp-mss.


6) Customer did not want to change MSS for all tunnels on the Eudemon side, so we provided the option of restricting the MSS on the AR side, with command tcp adjust-mss.


7) To no change MSS at all, advised customer to set the Don't Fragment (DF) flag bit for the IPSec tunnel on the AR side, by command ipsec df-bit.


Root Cause

1) Bad ACL to identify interesting IPSec traffic.

2) Incorrect remote IP on Eudemon side.

3) Due to IPSec and GRE encapsulations being present on the traffic path, MSS limitations existed and needed to be adjusted.

Solution

1) Correct ACL to identify interesting IPSec traffic.

2) Correct remote IP on Eudemon side.

3) Set the Don't Fragment (DF) flag bit for the IPSec tunnel on the AR side.