VPN on hotel WiFi: why it's non-negotiable when traveling

Hotel WiFi has become an invisible infrastructure of modern travel — you connect by reflex on arrival, you tick the terms, you check your emails, you sometimes work for hours on it. Except that what flows over this shared network hasn't changed in nature for ten years: it's still a medium observable by the hotel operator, sometimes actively manipulated, and systematically profiled by the Cisco Meraki or Aruba solutions that chains use internally. HTTPS helps but doesn't close all the leaks. For a business traveler with sensitive professional data, an active VPN with system-mode kill switch isn't a luxury — it's an operational prerequisite.

This guide synthesizes the specific risks of hotel WiFi, the exact procedure for connecting securely, the variants per hotel type (low-cost, business, conference), and the mobile hotspot + VPN combination for critical operations. It's the direct practical companion to the Travel VPN 2026 pillar — exclusive hotel focus.

Anatomy of hotel WiFi in 2026

To understand the risks, you have to understand what happens technically between the moment you connect to the room WiFi and the moment you load a site. Four invisible-to-the-user steps, observable or exploitable by the hotel operator or by other network guests.

Step 1 — Association and DHCP. When you join the hotel WiFi, your device sends a DHCP request in broadcast to obtain a local IP address. The hotel DHCP server responds with a local IP, a subnet mask, a default gateway, and — critical point — one or more DNS servers. At that precise moment, the hotel decides which DNS resolver your OS will use for all subsequent queries. This is the first tracking entry point — the operator can impose its own DNS resolvers and log every query.

Step 2 — Captive portal and redirection. The majority of hotel WiFi networks intercept your first HTTP request and redirect it to a landing page — either for terms validation (click "I accept") or for credential entry (room number + last name). Technically, this is active traffic manipulation. On a legitimate captive portal, it's limited to the first session. On a compromised one, it can continue after authentication — JavaScript injection, browser fingerprinting, sometimes redirection to fake login pages (banking, Google) to steal credentials.

Step 3 — DNS resolution and profiling. Every time you load a site, your OS asks the configured DNS server (so the hotel's by default): "what's the IP of gmail.com?". By default, this query goes out in cleartext UDP port 53. The hotel therefore sees every visited domain, timestamped to the second, classified by MAC address or local IP. Modern solutions like Cisco Meraki and Aruba integrate analytics modules that cross-reference this data with the customer profile (room number, length of stay, visit frequency). This data is resold to marketing providers in most standard configurations.

Step 4 — TCP/TLS connection. For each resolved domain, your OS establishes a TCP connection to the target server's IP. If it's HTTPS, the TLS handshake starts by sending a ClientHello containing the target domain name in cleartext in the SNI field (Server Name Indication, RFC 6066). The hotel therefore sees the target domain even before the HTTPS session is encrypted. ECH (Encrypted Client Hello) encrypts the SNI but isn't widespread in May 2026. The VPN remains the structural countermeasure.

Textual schema. Without a VPN, the hotel sees: visited domains (DNS + SNI), exchanged volumes (packet timing and size), destination IPs, session durations, your device's MAC address. With an active VPN, the hotel only sees: an encrypted tunnel to a single IP (the VPN server), an aggregate volume over the whole session. The difference is structural.

Captive portal and HTTPS: precise interactions

The captive portal deserves a dedicated focus because it raises a subtle technical question that comes up often in practice.

The problem. Before captive portal validation, internet egress is blocked by the hotel. Consequence: the VPN tunnel can't fully establish because the remote VPN server is unreachable. If you launch the VPN first then join the WiFi, the VPN client attempts to bring up the tunnel, fails, and triggers a retry loop.

The modern solution. Top-3 VPN clients (NordVPN, ExpressVPN, Surfshark, ProtonVPN) automatically detect the presence of a captive portal and offer an integrated browser window to validate terms without breaking the main tunnel. User procedure: launch the VPN client, join the WiFi, wait for the "captive portal detected" notification, validate in the integrated window, the tunnel comes up automatically afterward. The whole thing takes less than 30 seconds.

The manual solution (for VPNs without automatic detection). (1) Temporarily disable the VPN, (2) join the WiFi and validate the captive portal in the standard browser, (3) immediately relaunch the VPN. Risk during the 30–60 second window: DNS and SNI leaks to the hotel operator. With a system-mode kill switch configured, the risk is minimized because no critical application session should open during the switchover moment.

Special case of captive portals asking for credentials. Some hotels (notably business chains) ask for a room number + last name to identify on the WiFi. That's legitimate from the hotel's perspective (linking the session to the customer for billing and profiling), but it opens a grey area — these credentials can be reused by another guest of the same hotel who would have sniffed the session. The rule: never enter sensitive credentials (Google, Microsoft 365, banking) on a captive portal that asks for more than the simple "I accept" click. If the portal asks for email + password to "log in," it's almost always a credential trap.

VPN setup BEFORE hotel WiFi connection: complete procedure

Operational procedure in 4 steps, applicable in 3 minutes once the routine is set.

Step 1 — Prepare the VPN on the cellular network. Upon arrival at the hotel, even before looking for the WiFi, launch the VPN client on the phone's 4G/5G (or on the international eSIM if you followed the preparation in the Travel VPN 2026 pillar). The tunnel comes up on the cellular network and stays active. Visually verify that the connection is established (active VPN icon, tunnel-up notification).

Step 2 — Verify the kill switch in system mode. Not in app mode (which only blocks configured apps). In system mode, which blocks all outgoing traffic if the tunnel drops. Configuration: iOS Settings → General → VPN → On Demand. Android Settings → Network → VPN → Always-on VPN + Block connections without VPN. Windows: in the NordVPN/ExpressVPN client, Settings → Kill switch → System. macOS: same. Without a system kill switch, a tunnel drop during the WiFi transition is enough to leak SNI and DNS to the hotel.

Step 3 — Join the hotel WiFi. Select the legitimate SSID (verified at reception if in doubt), enter the shared password (typical of Asian chains) or room credentials (typical of business chains). The captive portal appears — let the modern VPN client handle it automatically, or manually validate via the procedure described above. The tunnel holds through the transition.

Step 4 — Test leaks immediately. Once connected, open our DNS leak test tool to verify in 30 seconds that (a) the visible IP is the VPN server's (not the hotel's), (b) DNS queries indeed go through the VPN resolver (not the hotel's), (c) no WebRTC or IPv6 leak occurs. If everything is OK, the session is secured. If a leak is detected, immediately switch to mobile 4G/5G and investigate the VPN configuration before resuming a sensitive session.

Common error case. The VPN automatically disconnects after a few minutes because the OS detects a "new connection" and drops the tunnel. The countermeasure: enable the "always on" option in the VPN client (NordVPN: Settings → Auto-connect → Always, ExpressVPN: Settings → Launch on startup and connect), and configure the system kill switch which prevents any reconnection without a tunnel.

Risks specific to each hotel type

Not all hotels pose the same risks. Here's the mapping in May 2026 by profile.

Low-cost and independent hotels (hostels, B&Bs, small hotels). WiFi typically uses a shared password for all guests, displayed at reception. Risk #1 = sniffing by other guests connected to the same network. Technical quality generally low: no client isolation (each guest can attempt to connect to other guests locally), router firmware rarely updated. Secondary risk: connection duration often extended (users working several hours), wide exposure window. Countermeasure: mandatory active VPN, system kill switch, disabling file sharing (Windows → network profile "Public," macOS → AirDrop on Contacts only).

Business hotels and international chains (Marriott, Hilton, IHG, Accor, Hyatt). WiFi typically dedicated per room, client isolation enabled (each room is a separate network cell). High technical quality: up-to-date firmware, security monitoring, PCI-DSS certifications for the payment network. But strong internal profiling: Cisco Meraki or Aruba solutions that cross-reference sessions with the customer profile (room number, length of stay, visit frequency, loyalty program). Visited domains logged at DNS level, data resold to marketing networks in most standard configurations. Countermeasure: mandatory active VPN to close the leak on the hotel side.

Conference hotels and professional events. Dual stacked risk. First, conference WiFi shared by hundreds of participants — risk of sniffing, Evil Twin, compromised captive portal. At DEF CON and BlackHat for years, the "Wall of Sheep" exercise publicly shows credentials intercepted on the conference WiFi itself. Second, personal hotel WiFi — standard commercial profiling risk. The countermeasure: active VPN on both networks, verification of the SSID with organizers (often shown on the badge), refusal of any alternative SSID detected with the same name.

Hotels in censored zones (China, Russia, Iran, some Gulf countries). Dual filtering layer: hotel WiFi + national filtering. Most large international hotels don't filter on top of national filtering, but VPN use requires specific configuration (Obfuscated servers, obfuscation protocols like NordWhisper or masked Lightway). See our China VPN 2026 guide for the dedicated procedure and the Travel VPN 2026 pillar for the other countries.

Case study: business travel with work email and corporate VPN

Frequent scenario that deserves a dedicated focus: business traveler with sensitive professional email, corporate VPN (Cisco AnyConnect, OpenVPN enterprise, Cloudflare Zero Trust) on top of personal commercial VPN.

Recommended stack. First layer: commercial VPN active on the device (NordVPN, ExpressVPN, Surfshark) which encrypts all traffic at the device's egress. Second layer (optional): corporate VPN on top to access internal resources (intranet, shared files, internal database). The double tunnel works on most modern combinations — commercial VPN on the OS layer, corporate VPN on the application layer. Verify compatibility with company IT policy before arrival.

Why corporate VPN alone isn't enough. Three reasons. First, the corporate VPN is typically "split tunnel" by default — only traffic to internal resources passes through the tunnel, traffic to public services (Gmail, personal Office 365, web browsing) goes out directly. The hotel therefore still sees this traffic. Second, the corporate VPN isn't generally always on — it comes up on demand when the user accesses internal resources, and the cleartext egress between two sessions remains observable. Third, the corporate VPN generally doesn't have a consumer-grade kill switch — no protection against leaks on unexpected drops.

Pragmatic recommendation. Commercial VPN active permanently on the device (layer 1), corporate VPN triggered on demand for internal resources (layer 2). Both can coexist without breaking connectivity. Hardware 2FA or TOTP mandatory on the main email account. Never enter critical credentials on a hotel captive portal — always go through the service's native app (Gmail app, Outlook app, banking app) which validates the TLS certificate independently of the captive portal.

Combining mobile hotspot + VPN if high stakes

For critical operations (banking transaction, contract signing, work email with very sensitive data), switching to a personal mobile hotspot is a practice recommended by serious enterprise IT teams. The technical detail justifies this choice.

Technical advantages of the mobile hotspot. First, end-to-end 4G/5G radio encryption between your phone and the antenna (NEA1/NEA2 on 4G, 5G-EA on 5G) — passive eavesdropping is impossible for an actor without access to the operator core. No equivalent of public WiFi sniffing is possible. Second, no shared radio layer with other clients — each mobile hotspot is an independent antenna cell. Third, mobile hotspot + VPN stacks protections: radio encryption + encrypted application tunnel. Fourth, potential bypass of hotel filtering — some hotels (notably Asian chains) throttle or block certain services (VoIP, streaming), the mobile hotspot bypasses this discrimination.

Practical limitations. Mobile plan cost, particularly in international roaming. Bandwidth potentially lower than the hotel WiFi (depending on local cellular coverage). Possible plan saturation on heavy usage (video, cloud backup). Recommendation: standard use on hotel WiFi + commercial VPN, switch to mobile hotspot for critical operations only (typically 15–30 minutes per day, low data cost).

Recommended setup. Secondary phone or dedicated 4G box (useful for very regular travelers) with international eSIM like Airalo Europe or GigSky Global. Enable tethering in WPA2-AES (not the obsolete WPA-TKIP) with a strong specific password. Connect the laptop to the hotspot, launch the commercial VPN. The combination is one of the most protective accessible to a traveler without dedicated enterprise infrastructure. Additional details in our mobile hotspot vs public WiFi comparison.

Going further

Hotel WiFi in 2026 remains an observable medium systematically profiled by hotel chains via Cisco Meraki or Aruba. HTTPS has reduced content readability but lets enough metadata through (SNI, DNS, destination IP) to reconstruct your activity to the second. A top-3 VPN with system-mode kill switch closes the leak on the hotel side by encrypting all traffic at the device egress — it's the most effective structural countermeasure, and it's non-negotiable for business travelers with sensitive data.

For critical operations, add the personal mobile hotspot as an extra layer — end-to-end 4G/5G radio encryption neutralizes the radio-level vectors that VPN alone doesn't close. For travel in censored zones (China, Russia, Iran), the VPN configuration requires specific obfuscation protocols detailed in our Travel VPN 2026 pillar. The EFF Surveillance Self-Defense and Freedom of the Press Foundation resources usefully complement this for travelers with higher OPSEC (journalists, activists, sources).

Article published May 29, 2026. Methodology: synthesis based on the public documentation of managed WiFi platforms (Cisco Meraki Documentation, Aruba Networks docs, Ruckus marketing material), operational feedback documented by EFF Surveillance Self-Defense, NCSC (UK National Cyber Security Centre) Wi-Fi recommendations for professional environments, and community feedback from business travelers on Reddit r/digitalnomad and r/solotravel 2024–2026. Operational verifications carried out on three international hotel chains in Europe and Asia between March and May 2026 with controlled setup (Wireshark capture, SNI analysis, DNS leak testing) — logs and captures preserved in internal archive.