Hotel and airport Wi-Fi: what public networks expose and how a VPN helps
Practical scenarios: public Wi-Fi, streaming, travel, gaming, and torrenting — where a VPN genuinely helps and where it doesn’t.
Why public Wi-Fi is still a security nightmare in 2024
You're sitting in an airport lounge, waiting for a delayed flight. Your phone connects automatically to "AIRPORT_FREE_WIFI." You check your bank balance, reply to a work email, and scroll through social media. Feels normal, right?
Here's what you don't see: that network might be logging every unencrypted domain you visit. Someone two seats over could be running a packet sniffer. The router itself might be compromised, silently redirecting login pages to credential-harvesting clones. Or it could just be an attacker's laptop broadcasting a fake network with a convincing name.
Public Wi-Fi networks—airports, hotels, coffee shops, conference centers—are fundamentally different from your home network. They're shared infrastructure with minimal authentication, often no password at all, and zero trust model enforcement. You're sharing that network with strangers, and the network operator has complete visibility into your unencrypted traffic.
This chapter walks through what public networks actually expose, which threats are real versus overhyped, and exactly how a VPN mitigates specific risks. No fearmongering—just the technical reality of what happens when you connect.
What information public Wi-Fi networks can see
When you connect to any Wi-Fi network, you're trusting infrastructure you don't control. Here's what's technically visible:
DNS queries: Every website domain you visit gets resolved through DNS. Even with HTTPS, the network sees you're visiting "bankofamerica.com" or "company-internal-portal.com." This creates a detailed log of your browsing activity—not the content, but the destinations.
Unencrypted traffic: Anything sent over plain HTTP is completely visible. In 2024, most major sites use HTTPS by default, but plenty of apps, API calls, and legacy services still don't. The network can read these in full: passwords, messages, form submissions.
Metadata patterns: Even with encryption, networks see connection timing, packet sizes, and traffic volumes. This reveals which apps you're using (streaming video has a distinct pattern), when you're active, and how much data you're transferring.
MAC address and device identifiers: Your hardware address is broadcast to connect. Combined with other identifiers, this can track you across locations and build a profile of your movements.
Hotels particularly like to correlate room numbers with browsing data. That "accept terms" portal isn't just legal cover—it's associating your identity with your network activity for the duration of your stay.
Real attacks that happen on public networks
Let's separate genuine threats from theoretical scenarios:
Man-in-the-middle (MITM) attacks: An attacker positions themselves between you and the internet, intercepting traffic. On public Wi-Fi, this is easier because you're already routing through untrusted infrastructure. The attacker can downgrade HTTPS connections, inject malicious JavaScript, or harvest credentials from poorly-configured apps.
In practice: This requires active attack effort and targets specific high-value individuals. Not every coffee shop has someone running SSLstrip. But the attack surface exists, and automated tools make it easier.
Evil twin networks: Someone creates a fake access point named "Hilton_Guest" or "LAX_Free_WiFi." Your device connects automatically because it looks familiar. Now all your traffic flows through the attacker's laptop.
In practice: Extremely common in airports and hotels. We've personally observed multiple fake networks at every major airport tested. Your phone can't distinguish between the legitimate network and the clone.
Session hijacking: Attackers capture your session cookies from unencrypted connections, then replay them to impersonate you on websites. Even if your initial login was secure, staying logged in often relies on cookies transmitted over plain HTTP.
In practice: Less common since widespread HTTPS adoption, but still viable against poorly-configured services, especially older internal corporate tools.
Malicious router configuration: Compromised routers can redirect traffic, serve modified content, or inject tracking scripts. Hotel networks often run outdated firmware with known vulnerabilities.
In practice: Documented cases exist, particularly in hotels in regions with weak cybersecurity standards. You won't know the router is compromised until you notice something wrong.
What a VPN actually prevents
A VPN creates an encrypted tunnel from your device to the VPN server. Here's what that protects against:
Complete traffic encryption: The network only sees encrypted data flowing to a single IP address (the VPN server). Your DNS queries, HTTP requests, and metadata all travel through the tunnel. The hotel network can't log which sites you visit, the airport can't inject ads, and passive observers can't read your traffic.
Check it yourself: Run Wireshark on a public network with and without a VPN active. With the VPN on, all packet content shows as encrypted garbage—no readable domains, no exposed data.
DNS query protection: Instead of using the network's DNS resolver (which logs everything), your queries go through the VPN tunnel to the provider's DNS servers. Some VPN apps also include DNS leak protection that blocks queries from bypassing the tunnel.
NordVPN and ExpressVPN both implement automatic DNS leak protection, but verify it's working using dnsleaktest.com immediately after connecting.
Evil twin mitigation: A fake network can intercept your traffic, but it only sees encrypted VPN packets. The attacker can't read the contents or modify them without breaking the encryption. They might deny service by blocking VPN protocols, but they can't silently harvest your credentials.
Router-level attacks: Malicious redirects and content injection fail because your traffic is encrypted before it reaches the router. The compromised device can't see what you're requesting or modify the responses.
What VPNs don't protect against
Be clear about the limitations:
Device-level compromise: If your laptop has malware, the VPN doesn't help. The malware can log keystrokes, capture screenshots, and steal data before it enters the encrypted tunnel.
Application vulnerabilities: Apps with security flaws remain vulnerable. A VPN encrypts transit but doesn't fix broken authentication, XSS vulnerabilities, or API bugs.
Endpoint security: The websites and services you connect to still see your actual requests. A VPN protects the path to the VPN server, but from there to the destination, you're trusting the VPN provider's security and the destination's HTTPS implementation.
Behavior tracking beyond the network: Browser fingerprinting, account-based tracking, and cookies that follow you across sites all still work. The VPN hides your IP address from websites, but Facebook still knows you're you because you logged in.
Practical setup for travel Wi-Fi
Here's how to actually configure this:
Before leaving home:
- Install and test your VPN app on all devices you'll travel with (laptop, phone, tablet)
- Configure automatic connection for untrusted networks
- Enable the kill switch so traffic never leaks if the VPN drops
- Set DNS to the VPN provider's servers or use encrypted DNS (DoH/DoT)
- Disable automatic Wi-Fi connection for all saved networks
1. Connect to the public Wi-Fi 2. Immediately launch your VPN before opening any other apps 3. Wait for the connection to establish (usually 3-10 seconds) 4. Verify it's working: check your IP address at ipleak.net 5. Look for DNS leaks—your real ISP's DNS servers shouldn't appear
If the network blocks VPN traffic (increasingly common), switch protocols. Most VPN apps support multiple options:
- Try WireGuard first (fastest, modern)
- Switch to OpenVPN if WireGuard is blocked
- Use obfuscated servers if available—these disguise VPN traffic as regular HTTPS
- Consider TCP instead of UDP for restrictive firewalls
The hotel Wi-Fi special case
Hotels present unique challenges:
Captive portals: These often break when a VPN is active because the portal needs to redirect you. Solution: authenticate first, then connect the VPN.
Per-device charges: Some hotels charge per connected device. A VPN on your laptop doesn't hide other devices. If you're trying to share a single connection, you need a travel router—connect it to the hotel Wi-Fi, pay for one device, then connect all your devices to the router's private network. Run the VPN on the router itself if it supports it, or on each device individually.
Bandwidth throttling: Hotels often throttle streaming video. A VPN's encryption prevents traffic shaping based on content type, but the hotel can still limit total bandwidth per connection. Results vary—some hotels can't distinguish VPN traffic from other HTTPS and throttle it equally; others specifically throttle any sustained high-bandwidth connection regardless of protocol.
Room number correlation: As mentioned earlier, hotels link your room to your network usage. The VPN prevents them from seeing what you're doing, but they still know room 342 is transferring 50GB of data. If that matters for your threat model, consider using mobile data instead.
Mobile data vs. public Wi-Fi
Your cellular connection is already encrypted between your phone and the tower. The carrier sees your traffic (similar to what an ISP sees), but random people nearby don't.
For quick tasks—checking email, light browsing—mobile data is often safer than public Wi-Fi without overthinking it. The attack surface is smaller because you're not sharing infrastructure with strangers in the same room.
A VPN on mobile data protects you from carrier surveillance and prevents the carrier from selling your browsing history (legal in many jurisdictions). But the immediate physical threat of someone intercepting your traffic doesn't exist like it does on shared Wi-Fi.
Weigh convenience against data caps. If you have unlimited mobile data, using it instead of airport Wi-Fi eliminates the whole category of network-based attacks. A VPN adds another layer but isn't strictly necessary for basic security—HTTPS to major sites is generally sufficient.
If you do connect a VPN over mobile data, expect 10-20% speed reduction from encryption overhead and routing through the VPN server. For most uses, this is unnoticeable.
Performance expectations on public networks
Public Wi-Fi is usually slow to begin with. Adding a VPN makes it slower. Expect:
- 10-30% speed reduction from encryption overhead
- Additional latency from routing through the VPN server (50-150ms typical)
- More variance because you're adding another hop that can congest
Some protocols perform better on congested networks. WireGuard generally handles packet loss and variable bandwidth better than OpenVPN. If streaming is important, test both.
Check your actual performance: run a speed test without the VPN, then with it active. Compare the results. If the VPN reduces your speed by more than 50%, something's wrong—try a different server or protocol.
When you can skip the VPN
HTTPS encrypts the content of your communication. On public Wi-Fi with a VPN, you're double-encrypting: TLS inside the VPN tunnel. For some use cases, this is overkill:
Casual browsing of major sites: If you're reading news on NYTimes.com or watching YouTube, HTTPS protects the content. The network sees you're on those sites, but can't read what you're viewing. A VPN adds metadata privacy (hiding which sites) but isn't strictly necessary for security.
When speed matters more than privacy: Video calls and real-time gaming suffer from VPN latency. If you're joining a work Zoom from the airport and the call quality is terrible with the VPN, dropping it might be acceptable—Zoom's own encryption protects the content, though the network sees you're on a call.
Trusted networks with a password: A password-protected network at a friend's house isn't the same as open airport Wi-Fi. You're still trusting the router, but the threat model is different. Use judgment.
The decision matrix: high-sensitivity activity (banking, work credentials, personal communications) on untrusted networks = use the VPN. Low-sensitivity activity or time-critical performance needs = HTTPS might be enough.
Verifying your VPN is actually working
Don't assume—check:
1. Visit ipleak.net before connecting the VPN. Note your real IP address and ISP. 2. Connect the VPN. 3. Refresh ipleak.net. You should see the VPN server's IP and location, and all DNS queries should show the VPN provider's servers. 4. Check dnsleaktest.com for comprehensive DNS testing. 5. Run a WebRTC leak test—some browsers leak your real IP through WebRTC even with a VPN active.
If any test shows your real IP or ISP's DNS servers, the VPN isn't fully protecting you. Troubleshoot: enable DNS leak protection, check for WebRTC leaks in browser settings, verify the kill switch is active.
For extra paranoia, disconnect the VPN mid-session and watch what happens. With a proper kill switch, all internet access should immediately stop. Without it, your traffic reverts to the unprotected connection—a serious leak if the VPN drops while you're logged into sensitive accounts.
Key takeaways
- Public Wi-Fi exposes DNS queries, metadata, and any unencrypted traffic to the network operator and anyone else connected
- Evil twin networks and MITM attacks are real threats in airports and hotels, not just theoretical concerns
- A VPN encrypts all traffic from your device to the VPN server, hiding content and destinations from the local network
- VPNs don't protect against device malware, application vulnerabilities, or tracking that happens after authentication
- Always verify your VPN is working using IP and DNS leak tests immediately after connecting
- Mobile data is often safer than public Wi-Fi for quick tasks, but a VPN on either adds privacy from carriers and ISPs
- Hotel networks require special handling for captive portals and may throttle bandwidth regardless of VPN use