What does an always-on VPN client open for a captive portal, and for how long?

## The window exists because the network demands a click first Hotel, airport and conference networks forward nothing until someone accepts terms or enters a room number. A laptop that refuses all untunnelled traffic therefore cannot join them at all, because the sign-in itself is untunnelled traffic. Every always-on deployment resolves this the same way: the client detects that a portal is present, opens a narrow exception, lets the user sign in, then closes it and brings the tunnel up. ## How the client knows a portal is there It asks a question it already knows the answer to. The client (or the operating system) issues a plain HTTP request to a URL it controls and expects an exact response — commonly a 204 with an empty body. If what comes back is a 302 to somewhere else, or a 200 with a login page in it, then something in the path is answering on behalf of the destination, and the client concludes it is behind a portal. Some networks also advertise a portal URL in a DHCP option, which is a cleaner signal, but you cannot rely on it being present. Note what this probe is: it is deliberately unencrypted, because a portal that intercepts a TLS connection would produce a certificate error rather than a usable redirect. It is a signal, not an authentication, and the answer comes from whoever runs the network. ## What the exception should contain, and what it usually does The minimum viable exception is: | Allow | Why it is needed | How it is usually over-scoped | | --- | --- | --- | | UDP/TCP 53 to the DHCP-supplied resolver | resolve the portal's host name | left open to any resolver, or left open after tunnel-up | | TCP 80 and 443 to the portal host | render and submit the sign-in page | opened to `any` destination for the whole window | | a bounded timer | close the hole automatically | renewed silently, or effectively unlimited | The over-scoped column is where deployments actually live. `Allow 80 and 443 to anywhere for ten minutes` is a general, uninspected internet path for every process on the machine, not a portal exception — background updaters, telemetry agents and anything a user launches all get out through it. ## What an adversary gets from the window Nothing exotic is required. Whoever operates that network chooses the content the corporate laptop's browser renders, and the browser is doing that with no tunnel, no corporate name resolution and no inspection in front of it. Meanwhile the machine is addressed on a segment shared with a few hundred strangers for the whole duration. Two practical consequences follow: sign in with a restricted, disposable browser profile rather than the user's working profile with its cookies and saved credentials, and treat the window's length as the real exposure metric rather than its rule set. There is also a denial angle worth stating. A network that never completes sign-in keeps the client in portal-remediation state. If your client renews the window automatically while it believes a portal is present, then the network — not you — decides how long the laptop stays untunnelled. The rule that fixes it is simple: the timer expires, lockdown resumes, and reopening requires a fresh user gesture. ## Measuring it, because that is the argument you will have The useful quantity is seconds of association with no tunnel, per network join, per device. The client's connection log has it, and it ships when the tunnel finally comes up. Look at the distribution: the mean will be dominated by office and home joins that never see a portal, while the tail is conferences and hotels where a slow portal produces minutes. When you are asked to justify tightening the exception, or refusing to widen it, the p95 of that number is the sentence that ends the discussion. ## Practical hardening checklist - Scope the HTTP allow to the host the redirect actually named, not to any destination. - Scope resolution to the DHCP-supplied resolver, and close it on tunnel-up. - Bound the timer, and never renew it without a human action. - Launch sign-in in an isolated browser profile with no corporate session material in it. - Keep the host firewall's inbound default-deny in force throughout — the portal exception is about egress and does not need to relax anything inbound. - Log every entry into the window with its duration, and report the tail. That log is also the answer when someone asks you to prove the exception is as short as you claim.