The advice to leave your virtual private network switched on at all times ignores the fundamental mechanic of how a tunnel works. A VPN does not simply add a layer of security; it reroutes your device’s entire network stack through a remote endpoint. This means your device no longer speaks directly to the local environment. It speaks only to the tunnel interface. When this interface is always active, the local network becomes invisible to the operating system for all traffic that is not explicitly excluded. The battery drain is a negligible side effect compared to the functional breakage this causes.
Consider the local network. Most homes and offices rely on local services that are not routed over the internet. A smart thermostat, a network-attached storage drive, a local printer, or a media server all communicate via private IP addresses. When a tunnel is active and set to route all traffic, these local addresses are often dropped or sent into the void of the remote server. The device assumes the local host is unreachable because the routing table prioritises the tunnel interface. The result is a device that is online but isolated from its immediate surroundings.
This isolation is not a bug; it is a feature of the tunnel architecture. The operating system treats the VPN interface as the primary gateway. Unless the software is explicitly configured to exempt local subnets, every packet destined for a nearby device is encapsulated and sent away. This creates a situation where the user appears connected to the internet but disconnected from their own home. The assumption that privacy is binary—on or off—fails to account for the mechanical reality of network routing.
The Airport and Hotel Trap
Public Wi-Fi networks operate on a different set of rules that clash directly with always-on encryption. Hotels, airports, and cafes use captive portals to authenticate users before granting internet access. These portals intercept HTTP requests and redirect the user to a login page. The mechanism relies on the device’s ability to send unencrypted, standard web traffic to the network’s gateway.
When a VPN is always on, this mechanism breaks. The VPN client intercepts the HTTP request before it reaches the captive portal. It encrypts the traffic and sends it to the remote server. The local gateway never sees the request to authenticate. The device remains stuck in a pre-login state, unable to reach the internet despite being connected to the Wi-Fi. The user sees a spinning wheel of death and assumes the network is broken, when in fact the security layer is the obstacle.
Some modern operating systems have introduced workarounds. Android and iOS can detect captive portals and temporarily disable the tunnel to allow authentication. However, this is not universal. Many desktop clients and older mobile versions lack this logic. Even when it works, it creates a momentary lapse in encryption right as you are joining an untrusted network. This is the opposite of what a privacy-conscious user wants. The always-on approach turns a simple login process into a technical conflict that requires manual intervention.
When Always-On Is Non-Negotiable
There are specific contexts where leaving the tunnel active is the only rational choice. The primary scenario is any public Wi-Fi network that lacks encryption. On an open airport hotspot or a café connection, the data transmitted between your device and the router is visible to anyone on the same local network. A VPN encrypts this leg of the journey, making it unreadable to local eavesdroppers. In this case, the privacy benefit outweighs the inconvenience of broken local services, because public networks rarely require local device interaction.
The second scenario involves accessing geo-restricted content or bypassing state-level censorship. If the goal is to appear as if you are in a different country, the tunnel must carry all traffic. Splitting traffic would leak your true location or break the functionality of the service you are trying to access. Here, the always-on state is a requirement for the service itself, not just a privacy preference. The trade-off is accepting that local network features will cease to function until you disconnect.
The Kill Switch Paradox
The marketing for VPNs heavily promotes the kill switch as a safety net. It is described as a feature that cuts your internet connection if the tunnel drops. This is accurate, but the analysis rarely considers the context of a drop. If you are on a trusted home network and the tunnel fails, the kill switch cuts your access. You are now offline. If you are on a public network and the tunnel fails, the kill switch cuts your access. You are now offline.
The problem arises when the kill switch is enabled but the user is unaware of the drop. Many users assume they are protected because the icon is green. In reality, the tunnel has failed, and the kill switch has engaged. The device is safe, but useless. This is not a failure of the kill switch; it is a failure of user expectation. The kill switch does not restore connectivity; it enforces security by enforcing silence.
Furthermore, some kill switches are implemented at the application level, while others are at the system level. A system-level kill switch is more robust but more disruptive. It blocks all traffic, including critical updates or background syncs. An application-level kill switch is easier to manage but can be bypassed by poorly coded apps. The choice of implementation dictates the user experience during a drop. An always-on configuration assumes the tunnel will never fail, which is a dangerous assumption for any network-dependent tool.
Configuration Over Constant State
The solution to the always-on dilemma is not to toggle the switch manually every time you change locations. It is to configure the tunnel to behave intelligently. Split tunneling is the primary tool for this. It allows you to route only specific traffic through the VPN while leaving local traffic on the direct connection. This solves the local device problem without exposing that traffic to the internet.
However, split tunneling has its own risks. It can bypass gateway-level security in corporate environments and may expose DNS queries to the local network. The configuration must be precise. Excluding the local subnet is essential for home use. Excluding specific services that require local access is necessary for productivity. The alternative is inverse split tunneling, where only specific destinations are routed through the VPN, and everything else goes direct. This is often the safer choice for general privacy.
The final piece is the captive portal workaround. Ensure your client supports automatic tunnel disabling for authentication. If it does not, you must accept that you will need to disconnect manually. There is no magic setting that makes a VPN invisible to a captive portal while remaining encrypted. The trade-off is inherent. The goal is to minimise the friction of these trade-offs through careful configuration, not to eliminate them through a single always-on toggle.