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
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.