Building a VPN Client People Do Not Switch Off

An enterprise VPN client has an unusual success criterion. It is not adoption — installation is mandated. It is that people leave it on.

Every security client competes with the user's immediate need to get something done. When those conflict, the client loses, because the user can turn it off and the deadline cannot be turned off. So most of the engineering that matters in a good client is not cryptography or routing. It is not being the reason somebody disabled it.

The moments where people reach for the switch

They are consistent, across platforms and organisations.

The network changed and the tunnel did not notice. A laptop moves from office Wi-Fi to a phone hotspot to a hotel captive portal. Each transition is a chance for the client to sit in a state where it believes it is connected and no traffic is passing. The user experiences this as "the internet is broken", tries the obvious remedy, and finds that turning the VPN off fixes it. That lesson is learned once and permanently.

The captive portal is unreachable. Hotel and airport networks require a browser sign-in before any traffic flows. A client that captures DNS and routes everything immediately makes the portal unreachable, which makes the network unusable, which makes disabling the client the only path to working.

Waking from sleep takes too long. A laptop lid opens and the user wants to be working in three seconds. If reconnection takes forty, and during those forty seconds nothing loads, they will get into the habit of disconnecting before closing the lid.

Something unrelated broke and the VPN is the suspect. When a printer stops working or a video call is choppy, the security client is the first thing anyone blames, whether or not it is responsible. If there is no quick way to prove otherwise, it gets switched off diagnostically and frequently stays off.

None of these are cryptographic problems. All of them are state-machine and user-experience problems.

Detect network changes properly, not on a timer

The most common architectural mistake is polling. A client that checks connectivity every fifteen seconds is, by construction, wrong for up to fifteen seconds after every transition — and transitions are exactly when the user is watching.

Every platform provides the right primitive. On Apple platforms the network path monitor reports interface changes as they happen; Android has connectivity callbacks; Windows has its own notifications. Subscribing to these, rather than sampling, is the difference between recovering in under a second and recovering eventually.

The second half is being honest in the UI. Three states — connected, connecting, not connected — with the middle one actually shown. A client that displays "connected" while reconnecting is training users not to believe it, and once the indicator is not trusted, it may as well not exist.

Handle the portal case deliberately

Captive portal detection is fiddly and it is not optional. The client has to recognise that the network requires sign-in, allow enough traffic for the portal to load, and then establish the tunnel once the network is genuinely usable — without leaving a window where traffic the policy should protect escapes.

That balance is a real security decision and it should be made explicitly, written down, and configurable by the administrator rather than resolved by whoever implemented it. The alternative is not a safer product. The alternative is a product that is off.

Fail visibly and specifically

When the tunnel cannot be established, a client that says "connection failed" has handed the user nothing except a reason to give up.

Say what failed. Cannot reach the gateway. Certificate rejected. Authentication expired, sign in again. Blocked by this network. Each of these implies a different action, and the specific one turns a support ticket into a thirty-second fix. It also matters for the diagnostic case above: a client that can say "the tunnel is healthy, your problem is elsewhere" survives the printer incident.

The platform is most of the work

The cross-platform ambition runs aground here, and it is worth knowing in advance. The tunnel itself is portable. What is not portable is everything around it: the network extension model and its entitlements on macOS and iOS, the VPN service lifecycle and per-app routing on Android, the driver and service model on Windows, and each platform's rules about what a background process may do and when it may be killed.

A shared core for protocol and configuration is worthwhile. Expecting to share the integration layer is not — that layer is where the platform-specific behaviour lives, and it is the layer that determines whether the client feels native or feels like something fighting the operating system.

The measure that matters

Not installs. Not connections. The percentage of working hours during which the client is enabled, and the distribution of how long sessions last before someone turns it off.

That number tells you whether you have built security or built a checkbox, and it responds far more to reconnection speed and error clarity than to anything in the protocol.