On public wifi a VPN does two useful things: it hides which sites and services you use from the network operator and anyone else on that network, and it stops the network from tampering with your traffic - redirecting your DNS, injecting pages, downgrading old unencrypted connections. It does much less than the advertising suggests about the rest, because most of what you send was already encrypted by HTTPS before the VPN ever saw it. It does nothing for your laptop's open file shares, nothing against a convincing phishing page, and nothing until you have got past the hotel's login page. The useful habit is short: accept the portal, connect the VPN, keep your device's own firewall on, and treat the network as hostile.
The rest of this post goes through what is actually visible on a shared network today, which risks are real and which are folklore, and how to set up a laptop and a phone so the VPN covers what it can.
What a shared network can see without a VPN#
The scary posters about public wifi were written when most of the web was plain HTTP. That has changed. Today almost every site, app and mail service uses TLS, so the operator of a cafe network - or someone sniffing the air - sees much less than they used to. Much less is not nothing.
| Visible to the network | Without a VPN | With a VPN |
|---|---|---|
| Contents of HTTPS pages and app traffic | No | No |
| Which sites you visit (DNS queries) | Usually yes | No |
| Which sites you visit (TLS SNI, destination IPs) | Yes | No, only the VPN server |
| Contents of plain HTTP, old mail or FTP | Yes | No |
| How much you send and when | Yes | Yes, as one stream |
| That you use a VPN | - | Yes, unless it is disguised |
| Your device on the local network | Yes | Yes |
The middle rows are what a VPN changes. Your DNS lookups normally go to whatever resolver the network hands out, in the clear, so the operator has a list of every name you looked up. Even with encrypted DNS, the TLS handshake for most sites still names the site in its Server Name Indication field, and the destination IP addresses tell their own story. A VPN wraps all of that into one encrypted connection to one server.
The last row is what a VPN does not change at all, and it is the one people forget.
The risks that are real#
DNS hijacking and captive redirection. The network controls the resolver it gives you. A malicious or merely aggressive network can answer a lookup for your bank with an address of its choosing. HTTPS and HSTS stop most of the damage - your browser will refuse a certificate that does not match - but apps that do not check certificates properly, and people who click through warnings, are exposed. Through a VPN your lookups go to the far end and the local network never gets to answer them.
Unencrypted leftovers. Old IoT apps, some games' login flows, a mail client configured years ago without TLS, a plain HTTP update check. Each of these is readable and alterable on an open network. A VPN covers them in transit; fixing them at the source is better still.
Evil twins. Anyone can create an access point called Hotel_Guest or Airport Free WiFi. Devices that remember open networks join automatically. Everything then flows through a laptop in the lobby. A VPN that connects before anything else is sent turns that laptop into a dumb pipe, which is exactly what you want.
Shared-password networks. On WPA2-Personal, everyone who knows the password - which in a cafe is everyone - can decrypt other people's traffic if they capture each device's connection handshake. The padlock icon on the wifi menu does not mean other customers cannot read your packets. WPA3's SAE fixes this with a per-device key, and Wi-Fi Enhanced Open (OWE) encrypts open networks, but you cannot choose which one a cafe runs.
Other devices on the same network. Unless the network isolates clients from one another, which good ones do and many do not, every other guest can reach your device directly. Open file shares, a development server listening on all interfaces, an old remote desktop setting - all of these are reachable from the next table.
What a VPN does not fix#
That last point deserves its own section, because the VPN does not help with it at all.
A VPN changes where your outgoing traffic goes. It does not stop other devices on the local network from sending packets to your device's local address, and your operating system will happily answer on any service that is listening. The fix is the device's own firewall and the network profile:
- Windows: when you join a network, mark it as a public network. In Windows 11 this is under Settings, Network and internet, Wi-Fi, then the network's properties, Network profile type. Public turns off network discovery and file and printer sharing for that network.
- macOS: turn on the firewall under System Settings, Network, Firewall, and turn off sharing services you do not use under General, Sharing.
- Phones: generally expose far less by default. The risk there is mostly apps and auto-joining networks.
A VPN also does nothing against:
- Phishing. A fake login page is just as fake through a tunnel.
- Malware already on the device. It will happily use the VPN.
- The VPN server itself. Everything the cafe could have seen, the server operator can now see instead. With a commercial VPN, that is a company you are trusting. With your own server, it is you.
- Being identified by accounts. Signing in to your accounts tells those services who you are, VPN or not. What a VPN protects and what it does not covers the full threat model; there is no anonymity here, only a change of who can see what.
Captive portals: the order matters#
Hotel, airport and train networks almost all use a captive portal: until you accept terms or enter a room number, every connection is redirected to a login page. A VPN cannot connect through that, because its connection to your server is intercepted like everything else.
The order that works:
- Join the wifi network.
- Wait for the login page to open, or open a browser and visit any plain
http://address to trigger it. Your operating system's captive portal check usually does this for you. - Accept the terms or sign in.
- Connect the VPN.
- Check that pages load through it.
If you use Android's always-on VPN with "block connections without VPN", step 2 never happens: the portal cannot be reached, the VPN cannot connect, and the phone sits there with no internet. Turn the block off for the few minutes it takes to get through the portal, then back on. VPN kill switch and always-on explains how those settings interact.
The minutes between joining and connecting the VPN are exposed. Most apps will try to sync the moment the network appears. If that window matters to you, pause background sync or keep the device in airplane mode with only wifi on until the VPN is up.
When the hotel network blocks VPNs#
Some networks block VPNs on purpose: corporate guest networks, some hotels and campuses, and networks in countries that filter protocols. Usually they do it in one of three ways.
| Method | What it blocks | What still gets through |
|---|---|---|
| Allow only web ports (80, 443) | WireGuard on 51820, OpenVPN on 1194 | Anything on TCP 443 |
| Block UDP except DNS | WireGuard, OpenVPN over UDP, QUIC | TCP-based tunnels |
| Inspect protocols (DPI) | WireGuard and OpenVPN on any port | Traffic that really looks like HTTPS |
The first two are crude, and OpenVPN over TCP 443 gets past them. The third is the one that matters: a firewall that checks whether the traffic on port 443 is genuine TLS will spot WireGuard and OpenVPN on any port. That is the case Xray with VLESS and Reality was designed for - the connection reads as an ordinary TLS 1.3 session with a well-known website. Xray vs WireGuard vs OpenVPN compares the three on exactly this.
Setting up a laptop and a phone for travel#
A short checklist, done once at home where nothing is in a hurry:
- Install your VPN client and test it on your home network. Do the DNS leak test while you are at it.
- On the laptop, confirm the firewall is on and that new networks default to public.
- Turn off auto-join for open networks you no longer use, and forget the ones called "Free WiFi". Every remembered open network is a name an evil twin can reuse.
- On the phone, decide whether to use always-on. It is the best protection against forgetting, and it needs the portal workaround above.
- Save the VPN link or profile somewhere you can get to without the internet, in case you need to re-import it.
- Check that the services you rely on (banking, two-factor apps) work from your VPN server's address before you are abroad and depending on them. Some banks are suspicious of logins from data-centre addresses.
A sensible travel routine join wifi -> accept portal -> connect VPN -> check IP -> use the network leave -> disconnect VPN -> forget the networkA phone hotspot is often the better answer#
Mobile data is a different kind of network. The radio link is encrypted between you and the operator, there are no strangers on your local segment, and there is no captive portal. Tethering a laptop to your phone avoids almost every public-wifi risk in this post without any VPN at all. The VPN is still useful over mobile data for the reasons it is useful at home - your carrier sees your DNS and destinations - but the specifically public-wifi risks disappear.
The catch is cost and coverage: roaming data abroad can be expensive, and hotel basements have no signal. Where both are available, a hotspot for anything sensitive and the hotel wifi plus a VPN for streaming is a reasonable split.
Your own server versus a shared VPN on the road#
On public wifi, any working VPN covers the same ground. The difference with a private VPN server is who sits at the far end and what the address looks like. A shared commercial VPN puts you on an address used by thousands of strangers, which is why so many sites throw captchas at VPN users. Your own server has one address and one set of users: you.
On RE:NODE the VPN line runs Xray with VLESS and Reality, so it keeps working on hotel and campus networks that block ordinary VPN protocols. The server has its own address and key, nobody else uses it, and there is no traffic cap. Windows connects through the Renode VPN app with the link the server prints; phones and Macs use any VLESS client such as v2rayNG, Hiddify, Streisand or Shadowrocket. It runs in Germany, which sets your latency: fine from most of Europe, noticeably further from elsewhere.
FAQ#
Is HTTPS enough on public wifi without a VPN?
For the contents of your traffic, mostly yes - HTTPS already encrypts what you read and send. What it leaves visible is which sites you visit, through DNS and the TLS handshake, plus any app traffic that is not encrypted. A VPN closes those gaps; it does not add much to the encryption itself.
Should I connect the VPN before or after the hotel login page?
After. The login page has to load first, because until you accept it the network intercepts everything, including the VPN's connection. Accept the portal, then connect, then check your public address.
Can other guests see my files if I use a VPN?
They can reach your device on the local network whether or not the VPN is on, because the VPN only changes outgoing traffic. Mark the network as public on Windows, turn on the firewall on macOS, and turn off sharing you are not using.
Is a password-protected cafe network safe?
Safer than an open one against passers-by, but not against other customers who know the same password. On WPA2-Personal anyone with the password can decrypt traffic they capture from other devices. Treat it like an open network.
Does a VPN protect me from a fake wifi hotspot?
It protects the traffic that goes through the tunnel, so a rogue hotspot sees only encrypted data to your server. It does not stop the hotspot showing you a fake login page before the VPN connects, so never type real account passwords into a captive portal.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.