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.


DSVPN with IPSec protection cannot work well with Cisco Router

Publication Date:  2019-07-04 Views:  3885 Downloads:  0

Issue Description

The topology:
Spoke Huawei Router ----- Internet ---- C Hub router

Customer implement DSVPN with IPSec protection between Huawei and C device. After implement the configuration, customer found that DSVPN could not work well.
Check the IKE and IPSec session and found IPSec SA could not be established and IKE SA is stuck in phase 1.
<Test>display ike sa verbose

Number of SA entries  : 1

   Phase                  : Phase 1
   Peer name              : IKE_PEER_20
   Interface:             : Tunnel0/0/0
   Connection ID          : 334
   IP address             : X.X.X.X
   SA flag(s)             :
   Exchange type          : Main
   NAT-traversal          : Disable
   UDP source port        : 500
   UDP destination port   : 500
   SA duration            : 86400 Seconds
   Seconds remaining      : 0 Seconds
   ReAuth Time Negotiated : 0 Seconds
   ReAuth Time Remaining  : 0 Seconds
   Sequence number        : 0
   Last known good Seq Num: 0
   SPI list negotiated    : No

Handling Process

1. Check the configuration on our AR router and compare with Cisco configuration. It seems ok.
We make debugging on AR router (debugging ike all) and found AR router sent out identify and authentication message. However, there was no reply from C side.
Jun 10 2015 18:51:44.402.4+02:00 Test IKE/7/IKE_Debug Info:
17:9087 Send_ID_AUTH msg (Source:Port = X.X.X.X:500), (Destination:port = x.x.x.x:500) Tx 0 times

Jun 10 2015 18:51:44.402.5+02:00 Test IKE/7/IKE_Debug Info:
17:9159 Send_ID_AUTH msg (Source:Port = X.X.X.X:500), (Destination:port = x.x.x.x:500) Tx 1 times

Jun 10 2015 18:51:44.402.6+02:00 Test IKE/7/IKE_Debug Info:
0:8957 EXCHANGE ICOOKIE: 66bd63100b68cfd7 - RCOOKIE: 5944ecbeee2b396b - Exchange run(i): finished step 4, advancing...

As we can see from the debugging, the IKE is stuck in IKE identification and authentication message. Our AR router sent out message and did not receive any reply.

Exchange processes in main mode as following.

2. Let customer check the C side. After customer finished the troubleshooting, they changed IKE pre-shared password from encrypted by AES (6) on C's hub to standard encrypted by service password-encryption (7).
After that, IKE connected successfully between C hub and Huawei spoke. However, the service traffic is still not working. Could not ping peer private IP address from C or Huawei side.

3. Check IPSec packet statistics on AR router and we found there is no any inbound packet from peer side even AR router sent the traffic.
<Test>display ipsec statistics esp
Inpacket count            : 0
Inpacket auth count       : 0
Inpacket decap count      : 0
Outpacket count           : 1001
Outpacket auth count      : 0
Outpacket encap count     : 0
Inpacket drop count       : 0
Outpacket drop count      : 0
BadAuthLen count          : 0
AuthFail count            : 0
InSAAclCheckFail count    : 0
PktDuplicateDrop count    : 0
PktSeqNoTooSmallDrop count: 0
PktInSAMissDrop count     : 0

Maybe there are three reasons for it.
a. AR did not send out the service traffic correctly.
b. Due to ISP network, the packets are dropped and were not received on C side.
c. C received the packet and it did not respond correctly.

4. Based on above analysis, we need packets to check. We can confirm that C device received packet from AR router.
However, packets from C are not correct.

Packet from C with wrong encapsulation


Correct packet format:

The ICMP packet is raw data and goes into internet which are dropped. That is why AR did not receive any packet from C.
Need customer to check peer side why the IPSec traffic did not goes into VPN tunnel. We doubt it is route issue.
C is core device in live network and we could not change it. We could change the source IP of tunnel interface on Huawei side.
Change the source IP from WAN physical interface to one loopback interface like C. The problem is solved.