Test a Hotspot Before You Let Work Credentials Near It

The hotspot hands out an address before it hands out the internet, and trust gets decided in that gap. The device associates, asks for an address, and then every outbound request is intercepted until a portal says the session is authorized. That mechanism explains why a page can appear to load while no real connection exists. Test the gap with something harmless before any work credential touches it.

What the hotspot does to your first request

Association gives the device a link, and DHCP gives it an address, a gateway and usually a DNS server owned by the venue. Until authorization completes, the gateway drops or redirects outbound traffic, and many portals answer DNS for every name with their own address. That is why a lookup appears to succeed: the answer is the portal, not the site you asked for. The network is behaving as designed; it simply is not the internet yet.

The first HTTP request normally receives a redirect to the portal, which the operating system may open for you. HTTPS cannot be redirected that way, so it either fails or hangs, and the browser shows a certificate error or a timeout. The difference is diagnostic: an HTTP redirect is the portal talking, while a TLS failure to an unrelated host is something else. A walled garden, where a few domains are allowed through for payment or sign-in, produces a third pattern.

Confirm the network before you sign in

Confirm the SSID and the sign-in method with the venue through a channel that is not the network itself. A portal asking for a corporate password, a card number and an email address is doing three different things, and only the last two are ordinary for guest access. Prefer the operating system's captive portal prompt, which detects the redirect through a known endpoint instead of trusting whatever page appears. If the venue cannot describe its own portal, that is a reason to wait rather than to improvise.

A certificate warning during portal sign-in is not a step to click through. The portal does not need to impersonate an unrelated host in order to authenticate you.

Run the smallest check that proves access

Complete the legitimate authorization, then request one ordinary public HTTPS page you have not loaded before, so the answer cannot come from cache. Record what actually failed if it fails: a name lookup, a connection timeout, a certificate error or a service refusal. Those four map to different layers, and writing them down stops the next person from re-testing by feel. Then connect the intended VPN and request one resource that requires it.

Keep the test small. A speed-test download on metered access answers a question nobody asked and can cost the user money. A response with headers is enough to establish reachability, and it does not pull megabytes through a link that bills per gigabyte.

If ordinary access works and the tunnel does not, that is a different investigation from a network that never authorized. Keep the two results apart instead of changing several privacy settings at once.

Keep private work out of the comparison

Every app on the device is a potential observer, and a captive portal is the moment when they all try to reach their servers. Close the ones you can, and treat a managed always-on device as a policy question rather than a technical one: use the approved method for the comparison instead of removing the protection that makes it managed. If the device forbids outside-tunnel traffic entirely, run the check on a different, non-sensitive device. The point of the exercise is to learn about the network without exposing credentials to it.

Do not capture other people's traffic to diagnose the venue, and keep any diagnostic capture scoped to your own device and session. Review address and identifier fields before attaching a capture to a ticket, because the venue's network is not your evidence locker.

Decide what the result lets you do

Three outcomes are possible: full access with a working tunnel, portal-only access with a failing tunnel, or no access at all. Each has a different next step, and the value of the test is knowing which one you are in before changing settings. Full access means work can proceed through the tunnel; portal-only access suggests the tunnel's port or protocol is blocked, so a different transport or network is the answer; no access means the venue cannot support the task today. A device that only ever tries one protocol cannot tell those apart.

Record the SSID, the outcome and the time, so the next person at the same venue starts from evidence. Apple's captive network guidance describes the detection behaviour behind the prompt, which is the part worth understanding before blaming the VPN.