GRE/IPSEC Tunnel Keeps Dropping

[GRANT3779]

Hi,

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.

Debug attached.

[Richard Burts]

I am looking at the debug that you posted and would like to start with a couple of questions:

- you say there have not been config changes. Is this true on both sides? How sure are you of this?

- you do not mention whether either of the routers (and probably most especially the spoke router) has had any change in the code that it is running?

- can you tell us what platform and what version of code these routers are?

HTH

Rick

[Richard Burts]

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.

HTH

Rick

[GRANT3779]

Hi Rick,

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

[Richard Burts]

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.

HTH

Rick

[GRANT3779]

Hi,

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.

Thanks for advice, appreciate it.