You may not have tried this yet, but you may want to read the note anyway, so you'll be prepared for the day you will need to cross a VPN. As security gets tightened, and networks are segmented, the VPNs will be coming to a LAN near you.
I hadn't thought about the issue of "dropped links" for years. My modems would often time-out from inactivity. Sometimes ISDN connections would drop due to idle timers, because there weren't that many B-channels available in the pool. I understand why you get timed out, and I empathize with the implementers. But, sometimes you need to keep a link up, without thinking too hard, or remembering to type a key.
In the modem days, I'd start a PING across a PPP link. Sometimes I'd set my email to poll every 5 minutes, just short of the timer, in order to keep links active. But broadband access and SSH to hosts was ubiquitous enough that I'd forgotten about this inconvenience.
Today, I was bitten bye a VPN with idle-timeouts set uselessly low for working remotely on my consoles. While email, and web browsers don't care so much (since they are always initiating a new TCP connection), it was invisible at first. But, my SSH sessions would suddenly be frozen. with no indication of the problem. Meanwhile, my idle TCP connection at the far host was abandoned, and would need to be killed off by someone with administrative privileges.
The answer was the TCP-keepalive options available in my SSH client. Under Microsoft graphical OSs, I use PuTTY, and you can set the option there for sending keep-alive null packets every n seconds, and/or TCP keep-alives. This solves the problem when it needs solving (only when I've got an SSH session I care about), and its automatically done (no need to remember special hacks), with minimal load on the network link.
Now, I admit that I am hogging a resource (the VPN session), but I'm usually logged in for a good reason (such as wrenching on the network), so I'm doing it for a good cause.
If you are going to SSH into console servers (or even reverse-TCP), a dropped VPN connection will cause you a lot of grief, since the port you were connected to will be 'busy' until someone can kill off that process. If you are using SSH to log into a Console Management Application Server (such as Conserver), you will be leaving abandoned sessions on the application server host, but the console ports themselves will still be available to the next person who needs to get on them. If you run into this symptom, check for the keep-alive options in your telnet/SSH clients, and see if that doesn't fix your timeouts. Just remember to log out of those sessions when you are done, so the VPN access can continue to be shared.