All the details I can think of are in the title, but let me know if there is some other info that might be useful. But what could cause this type of situation? The tunnel is up now, but I just want to know what could have caused this so I can prevent it in the future.
Mismatched phase 1 or phase 2 timers?
A lot more details are needed.
Is this IKEv1 or IKEv2?
What was phase 1 showing on both sides?
What was phase 2 showing on both sides?
Some systems may be blocked from initiating the connection, conversely one side may only be able to initiate the connection while the other side side cannot (usually due to some firewall/security device or misconfiguration of the VPN).
I would suggest looking at the raw logs for both sides of the tunnel to see if everything matches up. For example, if one system says that it is sending an INIT, the other side should see that.
About a quarter of the problems I see with VPN tunnels such as this are due to the packets not being received by the actual VPN system (ASAs in this case), check the firewall log to ensure that the packets are actually being received and allowed.
I have seen this before when dead peer detection isn’t enabled. One side goes down but the other side never realizes it and won’t renegotiate the existing tunnels until bounced or it reaches its timers.
stale vpn connection on the “dead side”, bounce the port which bounces the tunnel and now you have new info for the tunnel with connection.
I knew I left out some useful info. But we confirmed that they matched. 3600 for phase 2 and 86400 for phase 1. And this tunnel had been up for at least weeks before this, so I would think that issues with that would have come up within those timeouts.
IKEv2. Phase 1 and 2 were up on one side, and both down on the other side.
Nothing getting blocked on the firewall logs.
On the ‘Down’ side, it said auth exchange failed. Which seems to indicate a mismatch in the encryption profiles, but then wouldn’t that same mismatch happen after they bounced the ‘up’ end?
Yeah sounds like a dpd issue
Thanks. I will have to verify that on their end.
What vendor on either side?
If this is PSK based auth for phase1, do you have the right local and remote psk configured in the tunnel group settings for this VPN?
Cisco ASA on both sides Don’t know the code versions, but I know our end isn’t crazy old or anything and the other company is pretty security focused, so I would think they are fairly recent.
Yes and yes. I’m pretty sure it wouldn’t connect at all if those things had problems, right?
Make sure keepalives are enable in both ends. It’s the default on ASA, but can be disabled.
Saw the same issue twice in as many weeks, recently on the same tunnel. Not happened once in the 18 months I’ve been in the job before that. Didn’t really have time to look into it further so would be interested if you don’t find something. I presume some sort of config error or bug.
Anything in the logs? Have you turned on debug for phase1 and phase2?
debug crypto ikev2 200
debug crypto ipsec 200
debug crypto condition peer x.x.x.x
The logs did say something like auth exchange failed. No debug logs right now. Will probably do that if 8t happens again.