To have a better experience, please upgrade your IE browser.upgrade
Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
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 Cisco 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 = 10.204.96.2: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 = 10.204.96.2: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 Cisco side. After customer finished the troubleshooting, they changed IKE pre-shared password from encrypted by AES (6) on Cisco's hub to standard encrypted by service password-encryption (7).
After that, IKE connected successfully between Cisco hub and Huawei spoke. However, the service traffic is still not working. Could not ping peer private IP address from Cisco 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 Cisco side.
c. Cisco received the packet and it did not respond correctly.
4. Based on above analysis, we need to capture packets to check. From the capture, we can confirm that Cisco device received packet from AR router.
However, packets from Cisco are not correct.
Packet from Cisco 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 Cisco.
Need customer to check peer side why the IPSec traffic did not goes into VPN tunnel. We doubt it is route issue.
Cisco 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 Cisco. The problem is solved.