VPN Not Working on Hotel, Café or Office Wi-Fi? Why It Happens and What Works

VPN not working on Wi-Fi away from home? If it works at home but fails on hotel, café, school or office Wi-Fi, the network is almost certainly blocking it. Usually there are four possible causes. You haven't finished the Wi-Fi sign-in page yet. The network blocks UDP, which stops WireGuard and IKEv2. It blocks the VPN's port. Or its firewall recognises VPN traffic and drops it. The fix that works on most of these networks is a VPN protocol that runs on TCP port 443 and looks like ordinary HTTPS, such as VLESS + REALITY. The one case no VPN can beat is a managed device that decrypts all your traffic.

Why VPNs fail on hotel, café and office Wi-Fi

1. The captive portal

When you join hotel or café Wi-Fi, the network holds back your traffic until you accept the terms on a login page. RFC 8952 describes these portals: access is "limited until some requirements have been fulfilled". Many portals fake DNS answers or intercept web requests to show you that page. A VPN that starts before you've signed in can't connect, and it can stop the login page from appearing.

Fix: turn the VPN off, open any plain http:// page (such as neverssl.com), complete the sign-in, then turn the VPN back on.

2. UDP is blocked

Many guest networks allow only web traffic: TCP on ports 80 and 443. Everything else, including most UDP, is dropped. That stops:

• WireGuard, which is UDP-only by design;
• IKEv2/IPsec, which uses UDP 500 and 4500;
• OpenVPN in its default UDP mode (port 1194).

UDP blocking is common enough that Google tells admins Meet will fall back to TCP when UDP is blocked, and warns that this can lower call quality. Microsoft documents the same fallback for Teams.

Fix: use a protocol that runs on TCP 443. Switching OpenVPN to TCP works but is slow (see why VPNs get slow). A TLS-based protocol such as VLESS + REALITY is fast on TCP.

3. Only certain ports are open

Some office and coworking networks run a port allow-list: 80 and 443 for the web, maybe a few others. A VPN on an unusual port gets dropped silently.

Fix: choose a protocol and server on port 443.

4. The firewall recognises VPN traffic

Business firewalls from Fortinet, Palo Alto Networks and Cisco classify traffic by application, not just by port. Fortinet's FortiGuard database lists OpenVPN and WireGuard in its "Proxy" category, defined as "Proxy and VPN applications". Fortinet's own guidance for blocking third-party VPNs is to block that category plus the IKE signatures, block unknown applications, turn on deep inspection, and inspect all ports.

Researchers have shown how well this works against older protocols. A USENIX Security 2022 study identified more than 85% of OpenVPN flows on a live ISP network, and flagged most "obfuscated" OpenVPN configurations it tried.

Fix: a stealth protocol whose traffic is genuinely TLS 1.3 and looks like a real website. Scrambled or random-looking traffic is often classified as "unknown" and blocked too. Our stealth VPN guide compares the methods.

5. Your traffic is being decrypted

Managed company laptops often carry a corporate root certificate, and the company firewall decrypts and inspects all TLS. Some captive portals try a cruder version of this. No VPN protocol survives full TLS interception, because the device itself trusts the interceptor.

Fix: none, on that device. If it's your employer's laptop, use its official VPN and follow its policy. For personal use, use your own device.

The fix that works on most networks: TCP 443 with real TLS

Every network that lets you browse the web has to allow TCP port 443 with TLS. If a VPN's traffic is indistinguishable from a normal HTTPS visit, the network can't block it without blocking websites.

That's how VLESS + REALITY works. It runs on TCP 443, its handshake is byte-for-byte a Chrome TLS 1.3 handshake to a real website, and anyone who probes the server is shown that real website. Our VLESS + REALITY explainer walks through it.

On a café network, being blocked isn't the only risk. Café Wi-Fi is often slow on its own. Ookla's first-half 2026 data put Starbucks' median Wi-Fi download in the US at 12.1 Mbit/s, which Ookla reads as a deliberate cap. A VPN can't make the Wi-Fi itself faster. What it can do is not make it slower. In our own interleaved test on café Wi-Fi in November 2026, download through SleekDart ran at 182–202 Mbit/s against 183 Mbit/s direct on the same network.

A 2-minute checklist when your VPN won't connect

1. Turn the VPN off and load a plain http:// page. Accept the portal's terms if one appears.
2. Check the internet works without the VPN. If it doesn't, the problem is the Wi-Fi itself.
3. Switch to a TCP or stealth protocol in your VPN app and reconnect.
4. Pick a server close to you. A far server can time out on a slow network.
5. Still failing? Test on your phone's hotspot. If it works there, the Wi-Fi is filtering your VPN, and only a TLS-based protocol on 443 will get through.
6. Seeing certificate warnings on normal sites? Stop. The network or device is intercepting TLS. Don't enter passwords, and switch networks.

Is it okay to use a VPN on these networks?

On hotel, café and airport guest Wi-Fi, using a VPN is normal and sensible. You're sharing the network with strangers, and a VPN hides what you do from the network operator and other guests. Most guest networks that block VPNs do so with blanket rules, not because they forbid privacy.

Employer and school networks are different. They're entitled to set rules for their own network and devices. If your employer requires its own VPN or forbids third-party ones on work devices, follow that. For working from cafés and coworking spaces on your own devices, see what remote workers need from a VPN.