An Estate Left Connected

## Always-on is a claim about the endpoint, not about the gateway A remote-access VPN client in always-on mode (also called lockdown, or a kill switch) installs a packet filter **on the laptop itself**. Its default action is deny. Its allow list is short and deliberate: - the tunnel endpoints — the gateway addresses and the port/protocol the tunnel rides, so the client can build a tunnel at all; - DHCP, so the interface can obtain an address in the first place; - name resolution to the DHCP-supplied resolver, often only long enough to resolve the gateway and, where enabled, a captive portal; - a timed captive-portal remediation window, if you turned one on; - the directly attached subnet, if you granted a local-device exception. Everything else fails while the tunnel is down. Once the tunnel is up, anything not routed into it fails too. That is the whole assertion: **no untunnelled traffic leaves this endpoint**. ## The three answers that get marked down **"Always-on means the client reconnects automatically."** Reconnect is availability, and it is best-effort: the client keeps trying, and while it is trying the machine has a working internet connection. Lockdown is *enforcement*: while the client is trying, the machine has no working internet connection. The difference is the entire point, and it is the difference a candidate has to be able to state. **"The gateway enforces it."** A gateway can only apply policy to traffic that arrives at it. Traffic that goes straight out of the hotel Wi-Fi to a destination on the internet never reaches your gateway, so nothing there can see it, let alone stop it. The only place a rule can deny that flow is on the endpoint, in the path the packet actually takes. That is why the control lives in a filter the user is, technically, administrator over. **"The machine is off the network until the tunnel is up."** It is not. The radio is associated, the interface holds an address, and the link layer is running — address resolution, neighbour discovery, DHCP, whatever the network sends unsolicited. Another host on the same segment can address frames to the laptop and reach any service listening on it. The VPN client's filter is aimed at *egress*; inbound protection is the host firewall's job and is a control you must configure and verify separately. Ask, too, whether the filter covers both address families: a lockdown that denies IPv4 and ignores IPv6 on a dual-stacked hotel network denies less than the sticker says. ## Why the exceptions are the interesting part A laptop with no carve-outs at all cannot join most real networks. Public Wi-Fi almost always wants a click-through before it forwards anything, and a click-through needs DNS and HTTP *before* the tunnel exists. So you open a hole. Every hole you open is open to the segment for as long as it lasts, and the segment on hotel or conference Wi-Fi is a few hundred devices you know nothing about, plus whoever operates the network. The security of an always-on deployment is therefore not the lockdown — that part is easy — it is the size, duration and scope of the exceptions, and how many of them you have been talked into. ## The price you sign for Lockdown fails users closed. A client that cannot come up leaves the machine with no network at all, including no path to the helpdesk, no path to the fix, and no path to the portal that would have let it reach either. That cost is not theoretical: it is a stranded traveller at 23:00 and a helpdesk queue in the morning, and it is why the failure posture is argued about at a level above the engineer who configures it. ## What a good owner does with all this - Keep the host firewall's **inbound** default-deny in force independently of the VPN client, so the two controls do not depend on each other. - Enumerate the carve-outs as a list you can read in one screen; if you cannot, you have too many. - Cover both address families and confirm it, rather than assuming the client does. - Instrument the thing you actually care about: how many seconds per network join the machine spends associated with no tunnel. The client's own connection log carries it, and the number is a distribution, not an average. - Be ready for "prove it denies". The evidence is the endpoint's own filter drop counters and connection log, plus a repeatable test that attempts a known off-tunnel destination while the tunnel is down and records the failure — not a screenshot of the policy page.