Have a Watchguard T30-W box which is closing user SSL and L2TP/IPSec VPN sessions after 7 hours and 36 minutes.

This applies to all users and doesn't matter what time.. Login time is irrelevant.

The solution is to reconnect the VPN, which makes this a tiny pain verse's a show stopper; but I've been looking into to the why.

I've dug through the firewall logs and see it happening consistently (more so now that a lot of people are working remote).

The VPN logs look correct with the user logging in, and then logging out 7 hours and 36 minutes later. The only reason I've noted it, is more than one person is reporting the same sort of scenario getting kicked out and having to log back in. IE. If everyone one logs in around the same time, then they all get booted at the same which cause me grief with large groups of annoyed people :-)

A sample taken from the firewall logs (from the Event section) look like the following (Identifiable info removed)

The VPN Users had a initial "session time out" of 8 hours (bumped to 9 with no change in symptoms) and "Idle time out" to 30 minutes. I've also dug through other settings and don't see anything that screams "Tell Cersei. I Want Her to Know It Was Me"

Any ideas?

Aside: Were one release back on the firebox firmware; but I haven't wanted to update incase

Dimension gives you quite a bit more information and is the preferred logging method in my opinion. You need to be on 11.10 or higher I believe. You could log to both and then see which you prefer. Dimension is free and comes as a virtual appliance. The log server is also free and is part of your Watchguard management software.

Set up both, and do your own comparisons. Don't rely solely on other peoples opinions when you can evaluate both for free. If I could only pick one I'd go Dimension.

I can't help you with specifics on what each log line means (I don't really know), but I did pass those logs to one of my support engineers, to ask if they had seen them.

They say there is some bug associated with this logs, that results in the same impact you're having. One of the bug numbers is "BUG65975", however, we have a few others related to this issue. Engineering is working with support to find the core issue causing this. In many cases, the "scheduling while atomic" log shows up first as a result, but engineering believes that this is just some result from another issue.

In any case, engineering is working hard to resolve this. If you have already opened a support ticket associated to this, I recommend you keep on that ticket, to learn of the resolution. If you haven't opened a support issue, I suggest you do, even though we know of the bug, having more cases to look at will help the engineers resolve the problem.

It was initially set to 8; but I bumped it to 9 to see if anything changed; but unfortunately no change. Still disconnecting at 7h36m

Was thinking it might be a global setting; but I couldn't find anything

Taking this from a different angle, Maybe its a windows 10/1909 thing as the below shows up in the most recent of checking of the debug section of the firewall just before the disconnect. Maybe its one of the many new unintentional Windows features (cough bugs) MS seems to want to put in every major windows release (I only upgraded the laptops as I had thought RDP had up-scaling for allowing larger remote screen resolutions while the remote was running with a lessor resolution - but I was mistaken)

My suspicion was the same as Patricks. Like some authentication or session timeout.

Would the connections be idle, one could also check the connection timeout, but it's in the nature of a VPN, that there will be at least some rekeys in certain time periods.

However, when we speak about any of the manually / default timeout or rekey settings, none is 27.360 seconds by default and it would be a bit strange if someone would modify the default values to this strange number.

So I can only suggest you to open a support case and see, if tech support has something in their database for you.

I also wondered, if you upgraded the SSL VPN client, when you upgraded the Firebox OS, but than I remembered, that you mentioned the same happening on L2TP/IPSec as well, so it's not a client related thing.

WPaul​ I am in somewhat of the same boat as you. I have an M440 and we are using L2TP and I am having users get disconnected after a length of time. We are also using the firebox for authentication and I have changed both the active and idle timeouts and that seems to have no effect. But I am seeing this on Windows 7 and Windows 10 users. I have a case opened with WatchGuard, they had me upgrade to the latest firmware and that had no effect.

Alright, this may sound a bit odd, but I'm curious about what host based firewall is running.

I've found reports of the exact same behavior for Windows VPN connections to various equipment, not just the Firebox, where the issue is seen at 7hrs 36min 32sec. It seems that windows firewall or a third party host base firewall is potentially blocking the rekey negotiation of the client itself. Reported solutions for this is to disable the windows firewall.

The catch here is that I'm not aware this would be related to SSLVPN, only L2TP and IKEv2.

All machines are running retail Windows 10 Pro 1909 with latest service packs. Has occurred with standard windows firewall and with AVG Firewall

The devices are used exclusively for remote only, and are behind NAT'ed firewalls.
Users are using standard user account (no admin access) with group policies to lock down all execute within the profile. A vanilla machine setup.

As per SSLVPN, it may only be L2TP. I Initially most people were setup with L2TP, but have moved a few people over to SSL using the watchguard SSL client. Part of the problem is that we've had issues with VPN dropping due to WIFI which hides the 7h32m issue. I've moved most people over to wired ethernet which has cleaned up the drops and now its mostly the 7m32s drops

On another note with windows doing something strange: Had a previous windows 10
L2TP/IPSec
issue with reconnecting with after the external internet connection would drop . After the drop, it would take about 5 minutes to successfully reconnect . Connecting via a different source IP, or restarting the PC would fix the issue immediately. Something within windows requiring a set amount of time before the connection would time out.

As a side note, We were also having random drops which seemed to be attributed to wifi. Older wifi cards seemed to be less prone to this. Connecting the machines up via Ethernet removed the random drops (Had to use some USB/Ethernet dongles for some laptops - "
UGREEN USB Ethernet Adapter USB 3.0 to Gigabit Ethernet RJ 45 Lan Network Adapter Converter 10 100 1000Mbps Ethernet" worked fine out of the box)

now mostly we just have the consistent 7h36m drops across multiple users.

I'm thinking along with a few others, that it might not be with the watchguard. Maybe OS or firewall related on the client machine.

That behavior taking some time to rebuild sounds suspiciously similar to the 15 year old cisco VPN thread I was referencing. While old, I'm not sure that the underlying IPSec re-key in windows has changed. Especially when the time is almost the same down to the second.

Reports were that disabling windows firewall resolved the issue, which indicates that something in windows is getting in the way of its own rekey behavior.