What should happen to an app when its VPN disconnects?

Why use a VPN for one application?

A virtual private network, or VPN, sends traffic through a separate protected connection. Someone might use one for privacy on a shared network, to reach an authorized workplace service or to put a particular application on a separate route. It does not make the application anonymous or excuse what the application does; the VPN provider and the destination service may still handle information about the connection.

Using a VPN for only one application can be less disruptive than sending the whole household through it. Other devices keep their normal connection, and a problem with the VPN need not take down ordinary browsing. The tradeoff is complexity: somebody must make sure the selected application cannot accidentally switch back to the ordinary route. A whole-device VPN is simpler to explain, but may affect every app on that device.

This page describes a general design and a test to consider. It is not a claim that I have run the test or that any specific service is currently configured this way here.

The requirement is about failure, not connection

A normal connection test answers one question: can the application reach the internet through the VPN right now? That is useful, but it describes the healthy state. Privacy problems tend to appear during restarts, partial failures and configuration changes.

If the purpose is to keep a particular application on that protected route, the more important requirement is that it should have no usable internet path when the VPN is unavailable. It should stop, wait and recover only after the protected connection returns.

This behaviour is often called failing closed. The plain-language version is simpler: when the privacy control breaks, access stops instead of becoming less private.

A diagram can make this arrangement look inevitable. Software is under no obligation to respect the emotional certainty produced by a diagram, so the bad state needs its own test.

How the connection is arranged

One possible arrangement uses Gluetun to manage a WireGuard VPN connection and lets a selected application share its network connection. WireGuard is the VPN method; Gluetun is a tool that manages it and related connection rules. This is an example architecture, not an inventory of this site's private setup.

That arrangement aims for a clear ownership model. Gluetun handles the protected connection and firewall. The application should use only the connection Gluetun provides, but that intended behaviour still needs to be verified under failure conditions.

This is easier to reason about than giving the application several possible routes and hoping it chooses the preferred one forever. A privacy control should not depend on software displaying good judgment during a confusing morning.

Running is not the same as protected

A service can be running while the connection it manages is unhealthy. It may have a valid process, a green status icon and absolutely no useful VPN connection. Those facts do not contradict one another.

That is why basic monitoring is insufficient. A check that only confirms the Gluetun process exists proves that the process has not stopped. It does not prove that the VPN is established, traffic uses the correct path or the protected application has been isolated from the regular connection.

A green icon is useful, but it is not a sworn affidavit.

• Confirm that the VPN service itself is running.
• Confirm that the protected connection reaches the internet.
• Confirm that the protected application uses that connection.
• Confirm that the application loses access when the VPN stops.
• Confirm that access returns only after the VPN is healthy again.

The negative test

In a test environment you control, stop the VPN service while the selected application is running. If this is meant to be a protected-only route, the expected result is no internet access for that application, not graceful access through another route. Do not run a disruptive test on a production service without a way to recover it.

Check from the application's point of view rather than assuming the network layout worked. If it can still reach an outside service, the design has failed its most important test even if every configuration file looks persuasive.

Repeat after restarting components in an inconvenient order. The application might start before the VPN, the VPN might restart while the app remains running or the machine might return after maintenance. Each sequence should preserve the same rule. This describes what to verify; it does not claim that those tests have been performed on my system.

Orderly restarts are excellent demonstrations. Unfortunately, failures are not generally known for following the demonstration script.

The test passes only when the protected application has no working fallback route.

Recovery is part of the design

Stopping safely is only half the job. After the VPN returns, the application should recover without manual network repairs, stale settings or a long period where the dashboards look healthy but the connection is still unusable.

A sensible recovery check verifies the VPN connection first, then confirms that the selected application can reach its intended destination through that path. This order prevents the app from becoming a misleading test instrument while the connection is still recovering.

A design that fails safely but requires a page of emergency commands after every routine restart is secure in a very theoretical and irritating sense. Recovery should be repeatable as well as safe.

What the monitoring should say

The monitoring needs to distinguish between three states: the VPN service is stopped, the service is running but the protected connection is unhealthy, and the connection is healthy enough for the application to use.

Those states require different responses. A stopped service may need a restart. An unhealthy connection may need time or investigation. A healthy VPN paired with an unreachable application points somewhere else.

Combining them into one green-or-red status hides the distinction. It looks tidy, but tidiness is not the same thing as information.

Keep the privacy setup small

Every helper script and special exception creates another path to understand during failure. For an arrangement based on Gluetun, start by understanding its documented firewall and connection checks, then add only what the application actually requires.

This does not mean automation is bad. It means automation at a privacy boundary should be deliberately boring. A small design that can be explained from memory is easier to test than a clever design that relies on six scripts and one comment written during a burst of optimism.

The configuration should also be reviewed after meaningful updates. A setup that failed safely months ago may have changed through new software versions, new settings or a well-intentioned improvement that quietly introduced another route.

What this test does not prove

A successful failure test does not prove that every possible privacy concern has been solved. It does not audit the VPN provider, evaluate application data collection or guarantee that future updates will preserve the same behaviour.

If performed successfully, it proves a narrower and still valuable point: in that tested setup, the selected application could not use the regular internet connection when the VPN stopped.

That scope should remain explicit. Security writing becomes unreliable when one successful control is promoted into a universal guarantee.