I am lost on this one and hope to find some aid.
For my organization I have setup an IKEv2 VPN on our firewall. And it seemed to work fine, as my coworkers all use it without problems. But a few days ago one of our users approached me and asked when their problem is “finally solved”.
Which problem? I wasn’t aware that there even is a problem.
We had a few major internet outages three weeks ago, but those were resolved by our ISP. But since then, their VPN connections drop regularly, like every 1-2hours. The users thought, that these two problems were somehow related.
While windows is still telling them, that the VPN Connection is connected, the firewall already decided to drop the connection, probably because of the DeadPeerDetection.
I don’t know who to ask exactly. The firewall is a fortigate. The OS is windows, and the vpn profile is setup in Intune.
Does anybody have a tip for me? What can cause such a behavior?
You’re flying a bit blind here without logs. If it’s just one person then it’s probably their internet connection.
Check if their using a 4g/5g service and also what router they have.
Some of them turn on packet inspection but usually it’s not called that in the options.
Non 4g/5g services can also have those types of routers.
In addition to that - ikev2 can have problems renegotiating the tunnel over cellular connections. Check out the fortinet docs on ikev2 IPsec mtu fragmentation. But first check on your clients internet connection / router.
That sounds promising.
I haven’t played around much with the rekey interval. First I have to lookup how this setting is called on our firewall.
I guess it is the “Autokey Keep Alive” and “Key Lifetime” which is currently set to 43200 seconds (12hrs).
Is that too much? Probably.
I should try to reduce it maybe and see the impact.
Sadly it’s hard to pinpoint this problem. The firewall only allows me to start a debug log for 30minutes. And it’s not granted, that I will catch the error during this time.
IPSec VPNs have two phases and both have rekey timers, where they will renegotiate new keys to use for encryption, so the keys don’t become ‘stale.’ The rekey values do not necessarily need to match on both sides, they just need to agree the other values are OK.
Phase 1 (IKEv2) is where they agree on a set of algorithms to communicate securely (Diffie-Hellman exchange) and then they connect securely (this is one set of keys). Next they securely negotiate the parameters for Phase 2, ‘inside’ which all the data is encrypted (this is a second set of keys).
After a preset amount of time has passed or data has passed THAT SIDE of the tunnel will attempt a rekey.
Here’s where your problem could lie: If your VPN server tries to rekey first it will send a packet to (perhaps) someone’s cable modem router, which will surely just drop it. It is an inbound packet with no corresponding outbound session, because the outbound session was 24 hours ago when your user first connected from home.
What you can try is configuring the rekey timer on the VPN CLIENT, for both phases, to be shorter than the timers on the VPN server. That way the client’s outbound connection attempt should not be blocked.
You can also test if this is the issue by changing the timers a bit right now to see if that shortens or lengthens the time before this user gets disconnected. A new connection needs to be made after the timers have been saved.