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

Hotel WiFi has become an invisible part of modern travel. You connect by reflex on arrival, tick the terms, check your emails, and sometimes work for hours on it. But what flows over this shared network hasn't changed in nature for ten years. It's still a medium the hotel operator can watch. It is sometimes actively manipulated. And it is always profiled by the Cisco Meraki or Aruba tools that chains use inside. HTTPS helps but doesn't close all the leaks. For a business traveler with sensitive work data, an active VPN with a system-mode kill switch isn't a luxury. It's a basic must-have.

This guide pulls together the specific risks of hotel WiFi and the exact steps to connect safely. It also covers the variants per hotel type (low-cost, business, conference) and the mobile hotspot plus VPN combo for critical tasks. It's the direct practical companion to the Travel VPN 2026 pillar, with a hotel-only focus.

Anatomy of hotel WiFi in 2026

To understand the risks, you have to understand what happens between the moment you connect to the room WiFi and the moment you load a site. There are four steps you never see. The hotel operator or other network guests can watch or exploit each one.

Step 1 - Association and DHCP. When you join the hotel WiFi, your device sends a DHCP request in broadcast to get a local IP address. The hotel DHCP server replies with a local IP, a subnet mask, a default gateway, and one key item: one or more DNS servers. At that exact moment, the hotel picks which DNS resolver your OS will use for every later query. This is the first tracking entry point. The operator can force its own DNS resolvers and log every query.

Step 2 - Captive portal and redirection. Most hotel WiFi networks grab your first HTTP request and send it to a landing page. It asks either for terms validation (click "I accept") or for credentials (room number plus last name). This is active traffic manipulation. On a legitimate captive portal, it stops after the first session. On a compromised one, it can keep going after login: JavaScript injection, browser fingerprinting, and sometimes a redirect 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 set DNS server (the hotel's by default): "what's the IP of gmail.com?". By default, this query goes out in cleartext on UDP port 53. So the hotel sees every visited domain, stamped to the second, sorted by MAC address or local IP. Modern tools like Cisco Meraki and Aruba add analytics modules. They match this data to the customer profile (room number, length of stay, visit frequency). This data is resold to marketing providers in most standard setups.

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

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

Captive portal and HTTPS: precise interactions

The captive portal deserves its own focus. It raises a subtle technical question that comes up often in practice.

The problem. Before you accept the captive portal, the hotel blocks internet egress. So the VPN tunnel can't fully come up, because the remote VPN server is out of reach. If you launch the VPN first, then join the WiFi, the VPN client tries to bring up the tunnel, fails, and starts a retry loop.

The modern solution. Top-3 VPN clients (NordVPN, ExpressVPN, Surfshark, ProtonVPN) detect the captive portal on their own. They open a built-in browser window to accept the terms without breaking the main tunnel. Here are the user steps: launch the VPN client, join the WiFi, wait for the "captive portal detected" notice, and accept in the built-in window. The tunnel then comes up on its own. The whole thing takes less than 30 seconds.

The manual solution (for VPNs without auto detection). (1) Turn off the VPN for a moment, (2) join the WiFi and accept the captive portal in the standard browser, (3) turn the VPN back on right away. The risk during the 30–60 second window is DNS and SNI leaks to the hotel operator. With a system-mode kill switch set, the risk is low, because no critical app session should open during the switchover.

Special case of captive portals asking for credentials. Some hotels, above all business chains, ask for a room number plus last name to sign in on the WiFi. That's fair from the hotel's view, since it links the session to the customer for billing and profiling. But it opens a grey area. Another guest of the same hotel could sniff the session and reuse these credentials. 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 plus password to "log in," it's almost always a credential trap.

VPN setup BEFORE hotel WiFi connection: complete procedure

Here is the procedure in 4 steps. It takes 3 minutes once the routine is set.

Step 1 - Prepare the VPN on the cellular network. When you reach the hotel, before you even look for the WiFi, launch the VPN client on the phone's 4G/5G. You can also use the international eSIM if you followed the prep in the Travel VPN 2026 pillar. The tunnel comes up on the cellular network and stays active. Check by eye that the connection is up (active VPN icon, tunnel-up notice).

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

Step 3 - Join the hotel WiFi. Pick the real SSID (check at reception if in doubt). Enter the shared password (typical of Asian chains) or the room credentials (typical of business chains). The captive portal appears. Let the modern VPN client handle it on its own, or accept it by hand with the steps above. The tunnel holds through the switch.

Step 4 - Test leaks right away. Once connected, open our DNS leak test tool. In 30 seconds it checks that (a) the visible IP is the VPN server's, not the hotel's, (b) DNS queries do go through the VPN resolver, not the hotel's, and (c) no WebRTC or IPv6 leak occurs. If all is OK, the session is safe. If it finds a leak, switch to mobile 4G/5G right away and look into the VPN setup before you resume a sensitive session.

Common error case. The VPN cuts off after a few minutes because the OS sees a "new connection" and drops the tunnel. The fix: turn on the "always on" option in the VPN client (NordVPN: Settings → Auto-connect → Always; ExpressVPN: Settings → Launch on startup and connect). Then set the system kill switch, which blocks any reconnection without a tunnel.

Risks specific to each hotel type

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

Low-cost and independent hotels (hostels, B&Bs, small hotels). The WiFi usually uses a shared password for all guests, shown at reception. Risk #1 is sniffing by other guests on the same network. Technical quality is usually low: no client isolation (each guest can try to reach other guests locally), and router firmware is rarely updated. A second risk: people often stay connected for hours, which widens the exposure window. The fix: an active VPN is a must, plus a system kill switch and turning off file sharing (Windows → network profile "Public"; macOS → AirDrop on Contacts only).

Business hotels and international chains (Marriott, Hilton, IHG, Accor, Hyatt). The WiFi is usually dedicated per room with client isolation on (each room is a separate network cell). Technical quality is high: up-to-date firmware, security monitoring, and PCI-DSS certifications for the payment network. But internal profiling is strong. Cisco Meraki or Aruba tools match sessions to the customer profile (room number, length of stay, visit frequency, loyalty program). Visited domains are logged at DNS level, and the data is resold to marketing networks in most standard setups. The fix: an active VPN is a must to close the leak on the hotel side.

Conference hotels and professional events. Two risks stack here. First, conference WiFi is shared by hundreds of attendees, with a risk of sniffing, Evil Twin, and a compromised captive portal. At DEF CON and BlackHat for years, the "Wall of Sheep" exercise has shown credentials caught on the conference WiFi itself in public. Second, the personal hotel WiFi carries the standard commercial profiling risk. The fix: an active VPN on both networks, a check of the SSID with the organizers (often shown on the badge), and a refusal of any other SSID with the same name.

Hotels in censored zones (China, Russia, Iran, some Gulf countries). Two filtering layers stack: hotel WiFi plus national filtering. Most large international hotels don't filter on top of national filtering. But VPN use needs a specific setup: Obfuscated servers and obfuscation protocols like NordWhisper or masked Lightway. See our China VPN 2026 guide for the dedicated steps, and the Travel VPN 2026 pillar for the other countries.

Case study: business travel with work email and corporate VPN

Here is a frequent scenario worth its own focus. A business traveler has sensitive work email and a corporate VPN (Cisco AnyConnect, OpenVPN enterprise, Cloudflare Zero Trust) on top of a personal commercial VPN.

Recommended stack. First layer: a commercial VPN active on the device (NordVPN, ExpressVPN, Surfshark) that encrypts all traffic at the device's egress. Second layer, optional: a corporate VPN on top to reach internal resources (intranet, shared files, internal database). The double tunnel works on most modern combos. The commercial VPN sits on the OS layer, and the corporate VPN sits on the app layer. Check it fits your company IT policy before arrival.

Why a corporate VPN alone isn't enough. There are three reasons. First, the corporate VPN is usually "split tunnel" by default. Only traffic to internal resources goes through the tunnel. Traffic to public services (Gmail, personal Office 365, web browsing) goes out directly, so the hotel still sees it. Second, the corporate VPN is usually not always on. It comes up on demand when you reach internal resources, and the cleartext egress between two sessions stays visible. Third, the corporate VPN usually has no consumer-grade kill switch, so it can't shield you from leaks on sudden drops.

Down-to-earth advice. Keep the commercial VPN on at all times on the device (layer 1). Trigger the corporate VPN on demand for internal resources (layer 2). Both can run together without breaking connectivity. Hardware 2FA or TOTP is a must on the main email account. Never enter critical credentials on a hotel captive portal. Always use the service's native app (Gmail app, Outlook app, banking app), which checks the TLS certificate apart from the captive portal.

Combining mobile hotspot + VPN if high stakes

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

Technical upsides of the mobile hotspot. First, you get 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 anyone without access to the operator core. There is no public WiFi sniffing here. Second, you share no radio layer with other clients. Each mobile hotspot is its own antenna cell. Third, mobile hotspot plus VPN stacks two shields: radio encryption and an encrypted app tunnel. Fourth, it can bypass hotel filtering. Some hotels, above all Asian chains, throttle or block certain services (VoIP, streaming). The mobile hotspot gets around this.

Practical limits. The mobile plan costs money, above all in international roaming. Bandwidth can be lower than the hotel WiFi, based on local cellular coverage. Heavy usage (video, cloud backup) can use up the plan. Advice: use hotel WiFi plus a commercial VPN by default. Switch to the mobile hotspot for critical tasks only (usually 15–30 minutes per day, low data cost).

Recommended setup. Use a second phone or a dedicated 4G box (handy for very frequent travelers) with an international eSIM like Airalo Europe or GigSky Global. Turn on tethering in WPA2-AES (not the dated WPA-TKIP) with a strong, specific password. Connect the laptop to the hotspot and launch the commercial VPN. This combo is one of the safest a traveler can reach without dedicated enterprise gear. More detail in our mobile hotspot vs public WiFi comparison.

Going further

Hotel WiFi in 2026 stays a medium you can be watched on, always profiled by hotel chains via Cisco Meraki or Aruba. HTTPS has cut how much content is readable. But it still lets enough metadata through (SNI, DNS, destination IP) to rebuild your activity to the second. A top-3 VPN with a system-mode kill switch closes the leak on the hotel side. It encrypts 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 tasks, add the personal mobile hotspot as an extra layer. The end-to-end 4G/5G radio encryption neutralizes the radio-level vectors a VPN alone doesn't close. For travel in censored zones (China, Russia, Iran), the VPN setup needs specific obfuscation protocols. We detail them in our Travel VPN 2026 pillar. The EFF Surveillance Self-Defense and Freedom of the Press Foundation resources are a useful add-on for travelers with higher OPSEC (journalists, activists, sources).

Going further. Related reading on these topics: the juice jacking risk at public USB ports, VPNs for remote work and what to do when your IP is exposed.

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.