Captive Portals, Self-Hosted WireGuard, and the Precise Limits of Public WiFi Anonymity

by Border Cyber Group

There is a ritual familiar to anyone who has opened a laptop in a coffee shop, airport, or public library: you connect to the network, open a browser, and instead of the page you wanted, you get a landing page demanding that you click through a terms-of-service agreement, enter a room number, or in some cases provide an email address before the internet will agree to exist for you. This is the captive portal — one of the more interesting intersections of network engineering and institutional liability management in everyday life. It is also, for users of commercial VPN clients, frequently the last thing they see before their software either refuses to connect or gets quietly blocked by the network's filtering infrastructure. Understanding why this happens, and why a self-hosted WireGuard VPN on a personal remote server produces a very different outcome, requires going several layers down into how both systems actually work.

What a Captive Portal Actually Is

The term "captive portal" describes the condition of the network client more than it describes any specific technology. You are, in a literal sense, captive — held in a walled garden until you satisfy the network's authentication requirements. The mechanism that produces this condition is built from several cooperating deceptions, all of them quite deliberate.

When you associate with a public WiFi access point, your device receives an IP address via DHCP. In a normal network, the gateway address handed to you by DHCP is the actual path to the internet. In a captive portal network, that gateway exists, but every outbound packet you send — regardless of destination — is intercepted by a transparent proxy or redirected by firewall rules before it can reach the open internet. The network is already reading your traffic before you've clicked anything.

For HTTP traffic, the interception is straightforward. Your browser attempts to reach, say, example.com. The DNS query resolves — the captive portal network typically allows DNS through, or runs its own resolver that returns the portal's IP for everything — and your browser opens a TCP connection to what it believes is the destination server. The network's gateway intercepts that connection and substitutes its own response: an HTTP 302 redirect pointing to the portal login page. From your browser's perspective, example.com helpfully redirected you to the library's login page, which is not true, but is indistinguishable from true at the application layer.

HTTPS complicates this somewhat. A transparent proxy cannot intercept an encrypted TLS connection without triggering certificate errors that modern browsers treat as hard failures. So captive portal systems have developed a secondary approach: most operating systems now include a captive portal detection mechanism that, immediately upon network association, makes an HTTP (not HTTPS) request to a known endpoint. Apple devices ping captive.apple.com. Android devices ping connectivitycheck.gstatic.com. Linux systems have various implementations depending on the network manager. These probes are intentionally unencrypted and intentionally predictable, designed to be intercepted. If the probe returns anything other than the expected response, the OS concludes it is behind a captive portal and surfaces the login interface. The system is, in other words, designed to be deceived in a controlled way — the deception is the detection mechanism.

The portal itself is typically served by a RADIUS authentication backend or a simpler session-token system. When you click "I agree to the terms of service," your device's MAC address or an assigned session token is registered with the gateway, a firewall rule is updated to pass your traffic, and the walled garden opens. From that point, your traffic flows outbound — subject to whatever filtering the network operator has layered on top.

How Commercial VPN Blocking Works

The filtering layer is where things become interesting for VPN users. A managed public WiFi network — the kind operated by a library system, a hotel chain, an airport authority, or a large enterprise — typically runs one of a small number of commercial next-generation firewall platforms. Fortinet's FortiGate, Palo Alto Networks' NGFW, Cisco Umbrella, and Zscaler are the most common names in this space. These platforms are not simple packet filters. They perform deep packet inspection, meaning they examine not just the header information (source, destination, protocol, port) but the content and structure of the traffic itself, attempting to classify it by application and behavior.

Commercial VPN protocols have well-documented traffic signatures. OpenVPN, depending on configuration, produces a characteristic TLS handshake followed by traffic patterns that DPI engines recognize readily. L2TP and PPTP are even more distinctive. IPSec has known port usage and handshake structures. The commercial VPN industry has, for obvious reasons, attempted to address this through obfuscation — Mullvad's "Shadowsocks" mode, NordVPN's obfuscated servers, ExpressVPN's Lightway protocol — but the cat-and-mouse game between VPN obfuscation and DPI signature updates is ongoing, and in a managed enterprise or institutional network environment, the DPI platform's signature database is typically updated continuously by the vendor.

Beyond protocol signatures, there is the question of endpoint reputation. Commercial VPN providers operate from known IP ranges. Mullvad's exit nodes, NordVPN's server fleet, ExpressVPN's infrastructure — all of it is extensively documented, both by the providers themselves for marketing purposes and by threat intelligence aggregators and firewall vendors who maintain blocklists of known VPN endpoints. When your OpenVPN or WireGuard client attempts to connect to 198.54.132.74, which has been registered to Mullvad in every relevant database, a firewall with current threat intelligence feeds does not need to perform any DPI at all. It can simply drop the connection to a known VPN endpoint IP, regardless of what the traffic looks like.

There is also the matter of the client software itself. A branded commercial VPN client running on Windows generates ambient telemetry, interacts with the operating system in characteristic ways, and in some cases announces itself through mDNS or other local discovery protocols. A managed network with endpoint visibility tools — not uncommon in enterprise environments that have extended their guest network through the same management plane — can identify VPN client processes without ever examining a single packet.

Why Self-Hosted WireGuard Is Different

WireGuard was designed with a fundamentally different philosophy than its predecessors. It is a minimal protocol — the entire implementation fits in roughly four thousand lines of code — and its on-the-wire format reflects that minimalism. A WireGuard handshake consists of two messages: an initiation and a response, both appearing as fixed-size binary blobs carrying no plaintext metadata. There is no banner, no certificate exchange, no protocol version negotiation, no application-layer header that announces "this is WireGuard traffic." After the handshake, all data packets are encrypted ChaCha20-Poly1305 frames of varying size, carried over UDP. To a passive observer or a DPI engine encountering WireGuard traffic for the first time without prior knowledge of the endpoint, it is effectively indistinguishable from generic encrypted UDP — the kind of traffic produced by gaming applications, VoIP systems, video conferencing, and dozens of other common applications.

This is not, strictly speaking, obfuscation by design. WireGuard makes no attempt to actively disguise itself. What it achieves is closer to minimalism by design: there is simply nothing present in the traffic stream that a signature can match against, because there is nothing unnecessary in the protocol to begin with. A DPI engine looking for OpenVPN's characteristic TLS client hello will not find it. A system hunting for the WireGuard handshake specifically can find it — the packet sizes and timing are distinctive to a trained observer — but this requires a targeted detection effort rather than a generic VPN signature match.

The endpoint question is where self-hosted infrastructure produces its most significant advantage. A personal Linode VPS has an IP address in the 50.142.x.x range, which belongs to Akamai Connected Cloud (Linode's parent company following the 2022 acquisition). That IP range hosts thousands of customers running everything from personal web servers to enterprise applications to development environments. It does not appear on commercial VPN blocklists, because it has never been used as a commercial VPN exit node — it is simply a cloud hosting IP, indistinguishable in any threat intelligence database from any other small VPS. When a managed firewall sees WireGuard UDP traffic to 50.142.x.x on port 51820, it has no basis for blocking it beyond a generic "unknown UDP" policy decision, and most institutional networks do not implement that level of restriction because it would also block legitimate application traffic.

The port is configurable and worth considering. Port 51820 is the WireGuard default and is documented as such. Running WireGuard on port 443 — the standard HTTPS port — makes the traffic even more difficult to block without collateral damage, since blocking port 443 outbound would break essentially all web browsing. This is a one-line change in the server configuration and worth implementing on a laptop that moves through varied network environments.

The operating system matters less than it might appear, but it is not irrelevant. Linux generates substantially less ambient telemetry than Windows. There is no branded VPN client announcing itself in the system tray, no WireGuard-branded process with a recognizable name, and no integration with operating system features that might leak VPN status through legitimate channels. wg-quick is a shell script. The WireGuard kernel module is a standard kernel component on modern Linux systems. To any endpoint visibility tool examining the machine from the network side, this is a Linux box sending UDP traffic to a cloud server, which describes approximately half the development environments on any given enterprise network.

A Candid Evaluation of What This Actually Provides

Here is where honesty is required, because "VPN" has become a marketing category so thoroughly polluted by overclaiming that even technically informed users sometimes carry inflated expectations about what any VPN actually does.

What a self-hosted WireGuard VPN on a personal remote server genuinely provides, precisely stated: your traffic is encrypted in transit between your device and the VPN server, your traffic exits the public internet from the VPN server's IP address rather than your local IP, and your DNS queries (assuming they travel through the tunnel) are resolved by whatever DNS infrastructure the VPN server uses rather than the local network's resolver. These are real and meaningful properties.

What it does not provide: anonymity from your VPN server operator — which, in this case, is you, which is the entire point of self-hosting. Traffic analysis at scale is not defeated by encryption alone; an observer who can see both your connection to the VPN server and the VPN server's outbound connections can correlate timing and volume to reconstruct your traffic patterns without ever decrypting a packet, a technique known as traffic correlation or end-to-end correlation attack. This requires an adversary with visibility at both ends of the tunnel simultaneously — not a realistic threat model for library WiFi, but worth naming. Your activity is visible to the exit point's upstream ISP (in this case Linode/Akamai) in terms of destination IP addresses, even if the content is encrypted via HTTPS end-to-end. A WireGuard tunnel does not add a layer of encryption on top of content that is already unencrypted — if you are browsing HTTP sites, your traffic is readable at the exit point.

Perhaps most importantly: WireGuard on a personal server does not provide the anonymity properties that Tor provides. Your VPN server knows your real IP address — you connected to it. There is a direct association between your identity (you pay for the Linode account) and the VPN server. If someone with legal process contacts Linode and asks about traffic from 50.142.x.x. Linode knows whose account that server belongs to. This is a fundamentally different threat model than Tor's onion routing, where no single node knows both the origin and destination of a connection.

What it provides, against the realistic threat model of a public WiFi network, is substantial: the local network operator cannot read your traffic content, cannot log your DNS queries, cannot perform man-in-the-middle attacks against your connections, and cannot build a browsing profile from your session. The library's managed WiFi service sees encrypted UDP going to a cloud server. The log provider the library relies on for security visibility sees nothing useful. Your traffic, from the perspective of everyone on the local network, is opaque. Against passive surveillance at the local level — which is the actual threat on public WiFi — this is as close to complete protection as is practically achievable without Tor.

The Institutional Compact

There is something worth observing about the relationship between the library's security architecture and the user's privacy interests. The captive portal exists, as discussed, primarily for accountability and liability management. The library needs a logged association between a device and a terms-of-service acceptance. It does not particularly need to know what you do after that — and in fact, in most jurisdictions, the library has an institutional commitment to patron privacy that predates the internet by decades. The American Library Association has formal policies on patron privacy that libraries take seriously, and the managed WiFi service's log retention is often a source of tension for library administrators who would prefer not to hold data they are philosophically opposed to retaining.

From this perspective, connecting through a personal VPN after satisfying the captive portal's authentication requirement is not circumventing the library's actual security interests. You have identified yourself to the degree the institution requires. What you do with the network access after that is, from the library's perspective, your business — and the VPN simply ensures that "your business" remains yours. The log provider absorbs the liability for network abuse complaints, which will correctly point to your VPN server's IP and then go nowhere, because you are not engaged in abuse. The library gets its compliance checkbox. You get your privacy. Nobody is deceiving anyone about anything that matters to them. It is, in its quiet way, a reasonably clean arrangement.

Border Cyber Group publishes technical security research and investigative analysis. Nothing in this article constitutes legal advice. Readers are responsible for understanding the terms of service governing any network they access.