Why Four Hours Became the Pattern
Our remote workforce started reporting disconnects exactly at the 4-hour mark during long audit sessions, and the timing was too clean to blame on home Wi-Fi, ISP loss, or random FortiClient behavior. We were running FortiGate SSL VPN on FortiOS 7.4.3, with FortiClient 7.2.4 on most laptops, and the users hit the drop while reviewing evidence files, ERP exports, and maintenance logs from our manufacturing network.
At first, my team treated it like a transport problem. We checked SD-WAN health, WAN latency, packet loss, FortiAnalyzer events, and even a few Windows 11 power settings. Nothing lined up. The firewall logs showed normal SSL VPN authentication, then session teardown after a predictable window. The users were not idle in the human sense, but some of their apps were quiet enough that the tunnel looked inactive from the firewall’s point of view.
The pattern was the clue.
The setting most engineers skip is the SSL VPN idle timeout. In our environment, the default behavior interacted badly with audit workflows because web apps and file shares did not always generate steady traffic through the tunnel. A user could be reading a PDF, comparing screenshots, or typing notes locally while the tunnel aged out. The 300-second idle default sounds short, but the practical symptom was a longer, repeatable work-session failure once authentication lifetime and application traffic patterns overlapped.
Where I Changed the Wrong Timeout
I first changed the wrong timeout value — auth-timeout instead of idle-timeout — which made it worse. I assumed the 4-hour mark meant the authentication lifetime was the main problem, so I increased the SSL VPN authentication timeout and pushed the change during a maintenance window. The next morning, we still had drops, and a few users had more confusing reconnect behavior because stale sessions stayed around longer than I wanted.
That was on me. FortiGate SSL VPN has several timeout values that sound similar when the help desk ticket only says “VPN disconnected again.” They do different jobs, and mixing them up creates messy troubleshooting. On FortiOS 7.4.3, I had to separate session inactivity from authentication lifetime and login negotiation timing before the fix became obvious.
Names matter here.
- idle-timeout: Controls how long an SSL VPN session can sit without matching activity before FortiGate closes it.
- auth-timeout: Controls how long an authenticated SSL VPN session can live before reauthentication is required.
- login-timeout: Controls how long a user has to complete the login process before FortiGate abandons it.
- dtls-tunnel: Changes SSL VPN transport behavior, but it does not fix a bad inactivity policy by itself.
- FortiClient keepalive behavior: Helps visibility, but I do not use it as a substitute for correct firewall policy.
My opinion after this incident is simple: if a tunnel drops at a clean interval, I look at timers before I look at drivers, endpoint patches, or user habits.
How I Proved It From the CLI
I used the CLI because the GUI hid too much context and because I wanted exact values I could paste into our change record. We were testing from an Ubuntu 22.04 admin workstation using Python 3.11 scripts for log parsing, but the decisive evidence came directly from the FortiGate. I wanted the active tunnel list, the VPN settings, and the event log timing side by side.
show vpn ssl settings
get vpn ssl monitor
diagnose vpn ssl list
execute log filter category 1
execute log filter field subtype vpn
execute log displayThe monitor output showed active users and tunnel age. The SSL settings showed the timeout values we had inherited from an older FortiOS 6.4 configuration and carried forward through upgrades. The event log gave us the clean disconnect trail. Once I lined up a user’s session start, last meaningful tunnel activity, and disconnect event, the issue stopped looking mysterious.
I stopped guessing.
What I didn’t expect was how many users had built workarounds around this without telling us. One auditor opened a ping to an internal print server before long sessions. Another kept a dashboard tab refreshing in the background. Those tricks made the issue seem inconsistent until we looked at enough session history. Manufacturing IT teaches this lesson often: users adapt faster than tickets describe.
My opinion is that SSL VPN troubleshooting should start with session state, not endpoint reinstallations.
What We Changed Permanently
The permanent fix was boring, which is exactly what I wanted. We set the SSL VPN idle timeout to match the actual audit workflow, left auth-timeout controlled and intentional, and documented the difference in our firewall runbook. I did not set everything to unlimited because that would have traded user frustration for stale access risk, and I still have to defend the change during internal security reviews.
You may also find this useful: Check out our guide on Python Network Config Backup: Automating Multi-Vendor Device Snapshots for more practical tips.
config vpn ssl settings
set idle-timeout 28800
set auth-timeout 43200
set login-timeout 60
endFor our environment, 28800 seconds gave users an 8-hour inactivity window, and 43200 seconds kept the authenticated session lifetime at 12 hours. That balance fit our first-shift and second-shift audit schedule without encouraging overnight tunnel reuse. We tested with FortiClient 7.2.4 and 7.4.0, Windows 11 23H2, and a smaller Ubuntu 22.04 engineering group that used browser-based access through the same SSL VPN portal.
The tickets disappeared.
Before the change, disconnect tickets averaged 23 per week across remote audit, finance, and engineering users. After the fix, disconnect tickets dropped from 23 per week to 0 after the fix, measured over the next three full weeks. I also watched SSL VPN concurrent sessions on FortiAnalyzer 7.4.2 to make sure we had not created a pile of abandoned tunnels. We saw a small increase in average session duration, but not a capacity problem.
My opinion is that the right timeout is not the biggest number; it is the number that matches the work and still respects access hygiene.
Monitor the Fix Like a Security Control
After we changed the timer, I added a short monitoring checklist to our weekly firewall review. I care about tunnel duration, failed logins, stale sessions, and whether users reconnect from new source IPs during the same work period. A timeout change is still an access-control change, even when the business driver is productivity.
We now review SSL VPN behavior after FortiOS upgrades, especially minor upgrades like 7.4.3 to 7.4.4, because inherited settings can survive quietly while defaults, GUI labels, and FortiClient behavior change around them. I also keep a test user profile with lower permissions so my team can validate timer behavior without borrowing a real employee account. That small habit has saved us from vague post-upgrade complaints more than once.
Small timers create big noise.
I would not recommend copying our exact values without checking your own risk model. A plant with strict contractor access, shared workstations, or regulated remote maintenance windows may need a much shorter idle timeout. A design engineering group moving large CAD files over SSL VPN may need different keepalive expectations. The mistake is treating the default as a decision someone already made for your environment.
My final opinion is that SSL VPN reliability is usually not glamorous engineering. It is knowing which knob actually controls the pain users feel, proving it from logs, and changing only that knob.