I'm having a strange issue where one of my GRE/IPSEC tunnels has started dropping. No config has been changed on any of the end points. It's a Cisco Router to Cisco Router VPN Tunnel. This has been working fine for years.
I have one hub router which connects to many spoke sites. All other GRE/IPSEC tunnels are up and working no problem. The issue is just with one of the spoke sites. The Internet connection is all good as when the tunnel goes down I can still connect to the spoke router over the Internet using the Public IP and it's stable, no drops. It seems the phase 1 negotiations are failing. The tunnel will come back up itself eventually, but then an hour or so later it goes down. I'm really stuck here. Debugs attached. I've masked the public IPs but 194.x.x.x is the HUB router and 109.x.x.x is the spoke site. The debug was taking from the spoke router.
I have looked through the debug that you sent. It shows pretty clearly that the spoke is attempting to negotiate ISAKMP with the hub. Repeatedly the spoke begins the negotiation by sending ISAKMP to the hub, waiting for a response, retransmitting, waiting, etc until the 5th timeout when it drops the attempt, and then begins another attempt.
So the question is why is the hub not responding? Can you do a conditional debug on the hub so that we see only the interaction between the hub and this spoke?
I have encountered several times issues with symptoms similar to this. I have found that sometimes doing clear crypto isakmp and clear crypto sa will get things going again. The next time the problem happens try using these commands and let us know if it helps.
The HUB Router is a 2811, running 12.3 code. The remote site router is a 3825 running 12.4 code.
Old I know..but I have multiple GRE/IPSEC tunnels running successfully off it and so was this one until earlier. No one has access to make any changes, it's locked down with TACACs. I've also compared an old backed up config to the current configs and all are exactly the same. Very strange.
I've attached the debug from the HUB just now. Tunnel still down...
Thanks for the additional information. The debugs seem to be at different times and seem to show different events/different problems. The first set of debug was from the spoke and shows the spoke sending ISAKMP and apparently not receiving any responses from the hub. The second set of debug from the hub seems to show ISAKMP negotiating
Jan 8 14:33:18.626: ISAKMP:(0:66:HW:2): sending packet to 109.x.x.x my_port 500 peer_port 500 (R) MM_SA_SETUP Jan 8 14:33:18.626: ISAKMP:(0:66:HW:2):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE Jan 8 14:33:18.626: ISAKMP:(0:66:HW:2):Old State = IKE_R_MM1 New State = IKE_R_MM2
and then proceeding into negotiation of IPSec. So I am puzzled at the different behaviors.
I am curious whether you have tried the clear crypto commands and whether they help.
I did clear those as requested but still had same problem. I have since rebooted the HUB Router (Since it's now out of hours here in the UK). The tunnel has now come back up! However I guess I'll find out in the morning if this stays the same :-) WIll keep you posted.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...