Public Wi-Fi and a VPN: What the Tunnel Does Not Cover

Green badge, satisfied portal, working browser: that is the whole visible story. What the badge omits is that the encrypted connection is carried by the very wireless link it is supposed to protect you from. That link still delivers every packet, still sees the endpoint address, and still decides whether anything arrives at all. Walking the laptop side of a hotel connection shows which parts the tunnel covers and which parts it leaves to you.

The Access Link Carries Everything

An IPsec ESP tunnel wraps a protected inner packet inside an outer header the network can route, and RFC 4303 section 3.1.2 lays out that split. The inner packet is what the tunnel protects. The outer header is what the hotspot reads in order to forward it. Other designs encapsulate differently, yet the planning question is identical: which access path carries this connection?

A gateway failure or a link that drops packets stops delivery without revealing content. Changing to a stronger cipher does nothing for that, because the missing piece is transport rather than cryptography. Successful delivery proves as little in the other direction, since a working path says nothing about the state of either machine.

Your Laptop Still Has Its Own Doors

Joining an untrusted segment changes who can reach the ports your machine listens on. A file-sharing service, a remote administration agent or a development server bound to all interfaces is reachable by anyone on that segment unless something stops it. Traffic that never enters the tunnel is not protected by it. A listener that answers before the tunnel is up is exposed for exactly that window.

The requirement is narrow and worth stating exactly: the laptop must reach the VPN endpoint, and unrelated devices on the hotspot must not reach local services. Host firewall rules express that boundary, and the platform's own sharing settings express part of it too. A printer or a portal step is a scoped exception you add deliberately, not evidence that the whole hotspot deserves office-LAN trust.

Some organisations also restrict local access while a work connection is active, which is policy rather than engineering. Read that policy before disabling a firewall to make a peripheral work.

Check What Is Actually Listening

Look at the sockets rather than at the settings page, because the page describes intent and the socket table describes the machine. The two listings below separate every listening socket from the ones a neighbour could reach. Run them on the untrusted segment before connecting the tunnel.

ss -lntu
ss -lntup | grep -v 127.0.0.1
resolvectl query vpn.example.net

The first command shows every socket, and the second filters to those bound beyond loopback. A service on 0.0.0.0 or :: is available on every interface, including the wireless one, while the same service on 127.0.0.1 is not reachable from the segment at all. The resolver query confirms which path the name takes before the tunnel exists, which is where captive portals interfere. Repeat the listing after connecting, because some clients raise interfaces that change the answer.

A port that appears only while the tunnel is up is less exposed, though it is still worth knowing about. Record the difference rather than the absolute list, since the delta is what the tunnel added.

Do Not Accept a New Identity Mid-Session

An unexpected route change, a reconnect or a portal redirect is not permission to accept a different server identity. If the client reports a certificate or key mismatch, treat it as an identity finding rather than as connectivity to be worked around. Installing an unexplained root certificate to make a portal work converts a delivery problem into a trust problem. The trust problem then outlives the trip that created it.

Use the portal's own browser flow, then reconnect the tunnel and read the client log for the identity it verified. Identity failure means the peer is not who you expected, while delivery failure means the peer never answered. The first is a reason to stop, and the second is a reason to try another path.

Decide the Outage Behaviour First

Two different features get confused here. Reconnection attempts to restore service, while a blocking policy controls which traffic is permitted while the tunnel is down. Neither supplies a working wireless link, and neither proves the endpoint is clean. Choose explicitly: fail closed for applications that must never use the local path, and allow ordinary browsing outside the tunnel if that is acceptable.

Write the choice down, because the default in most clients is neither, and it varies by version. Then arrange an alternative access path if availability matters, such as a phone hotspot with its own data plan. A passable acceptance test has three separate outcomes: intended traffic uses the verified tunnel, unrelated local listeners are unreachable, and an outage produces the behaviour you chose.