cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
187
Views
5
Helpful
1
Replies
Highlighted
Beginner

Testing DMVPN Traffic Reach-ability

I have one DMVPN spoke site that stopped working a few days ago with no changes on the network at the spoke nor the hub. It's encrypted with a certificate so I pulled a new certificate no problem. That shows port 80 to the hub is fine. But I'm not seeing logged attempts from the spoke at the hub so I'm suspecting perhaps the ISP put in place some kind of protection that blocking the crypto conversation and preventing the tunnel from coming up.

 

What other commands could I run to verify whether the tunnel setup traffic is permitted from spoke to hub? Ping verifies the routing is good. Certificate pull and telnet port 80 to the hub verifies port 80 is all good. Is there some kind of command that would let me send the ports and protocols of IPSec as a test to vet that these are in fact permitted to the DMVPN hub router? 

 

I could run debug dmvpn at the spoke. I tried running debug dmvpn at the hub but that debug surprisingly was not showing me the source address of the connection attempts (there are dozens of sites connecting to the hub). Any tips on verifying the connection path appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions
RJI Advisor
Advisor

Re: Testing DMVPN Traffic Reach-ability

Hi,

You could run a packet capture on the hub router, match on the ip address of the spoke in question. Bounce the tunnel on the spoke and "clear crypto session" to force the tunnel to re-establish. Run a debug of ike/isakmp on the spoke and confirm the spoke attempts to communicate (upload here for review). If the packet capture on the hub does not capture anything then that could indicate an ACL in the path blocking communication (udp/500, esp or esp/4500).

 

Also refer to this Cisco Live presentation BRKSEC-3052, which provides useful troubleshooting tips.

 

HTH

View solution in original post

1 REPLY 1
RJI Advisor
Advisor

Re: Testing DMVPN Traffic Reach-ability

Hi,

You could run a packet capture on the hub router, match on the ip address of the spoke in question. Bounce the tunnel on the spoke and "clear crypto session" to force the tunnel to re-establish. Run a debug of ike/isakmp on the spoke and confirm the spoke attempts to communicate (upload here for review). If the packet capture on the hub does not capture anything then that could indicate an ACL in the path blocking communication (udp/500, esp or esp/4500).

 

Also refer to this Cisco Live presentation BRKSEC-3052, which provides useful troubleshooting tips.

 

HTH

View solution in original post