VPN - Do you auto-disconnect VPN clients after X hours? Any reason to never force a disconnect?

For those that manage VPN solutions, do you have any rules governing how long a VPN can remain connected? If a user connects their VPN at 8am on Monday, and does not disconnect the VPN themselves, will they be disconnected at some point? Either after X hours? or after X hours of no activity? or some other measurement? And what do you consider the best practice for VPN client management to be connection and time-wise?

Long story short, is there a good reason not to leave a client connected as long as they want to remain connected? If I connect my VPN on Monday at 8am and leave my computer on all week, is there any good reason to force a disconnect?

Ours is set to 12 hours cause our users just walk away from their PC at 4PM and we dont need idle machines on the VPN all night.

  • depends on your licensing (concurrent or everyone)
  • depends on you configuration (split vs full tunnel)
  • depends if the machines connecting are corporate use only or BYOD

We disconnect at 10 hours. By that time, they should either be done working or need to reauthenticate to continue. No reason to let them stay connected overnight and into the following day(s).

We auto-disconnect if there is no internet traffic at all in the last 1800 minutes

Some compliance schemes require user reauth after certain periods. The reasoning for this is that after a certain period of time, you can’t reasonably assume that the user is using the computer, and/or the secure applications (including VPN) that they may have access to. This usually means an auto-disconnect after 12-24h, regardless of whether the user is active or not (idle disconnect is a separate timer).

Stale sessions. If you don’t force a disconnect you can end up with a user that has three sessions but only one session active. This happens a lot if they have crappy internet connections (esp high packet loss or jitter).

Keeping with that same thought, it is probably good to keep the number of user sessions limited to 3 or fewer as they are not likely to be using more than 3 VPN connected devices for work.

Each VPN session reserves a given amount of RAM/Proc on the VPN gateway, if you have users with unlimited sessions, unless you have WAY overspec’d the box you will kill it ded.

So, those two features help keep your VPN gateway happy and healthy. Limited number of sessions, and limited time for a session. (This doesn’t even bring into account IPAM for VPN.)

We use OpenVPN with Duo but wanted users to reconnect via Duo every morning. We have a cron job scheduled to reboot the VM server at 1am, effectively killing all connections.

Long story short, is there a good reason not to leave a client connected as long as they want to remain connected? If I connect my VPN on Monday at 8am and leave my computer on all week, is there any good reason to force a disconnect?

So far I haven’t found a good reason why I would kick out users. The resource impact of stale connections is negligible and since those computers are domain joined they are never really stale anyway because clients will contact the DC on a regular basis for GPOs anyway. The same goes for the SCCM client. So even if I wanted to kick them out I don’t know how I would even identify stale connections.

However, it is worth mentioned that authentication is done using computer certificates - so dead connections get kicked out by the VPN server automatically if it sees the same PC connecting a second time. It is impossible to have multiple connections from the same client.

They can be stale, even with attempted DC connections because the external network protocols have lost connection either because of IP address shift or high jitter connection. The VPN concentrator has no means to determine whether the client is still alive (unless you implement in-tunnel keepalives which suffer the same problem.) You COULD also turn on outside the tunnel keepalives, but that invites firewall problems esp if you have clients/customers attempting to connect from guest networks at other corporate sites.

So, you’re dependent on some timeout to teardown. Depending on your customer base, this could leave you with a LOT of dead connections even just dependent on the default TCP timeouts.