Culvert VPNThe Wi-Fi blocks VPN connections. What now?
First tell a filtered network from a sign-in page or a dead connection. Then let the app try its other methods, and know when mobile data is the answer.
When a Wi-Fi network blocks VPN connections, the practical answer is in three parts. First, make sure it really is filtering, rather than a sign-in page you have not accepted or a connection that is down for everyone. Second, let the app work through its connection methods: a good one tries WireGuard over UDP on several ports, then a TLS-wrapped transport on TCP port 443, then IKEv2, and keeps the one that carries traffic. Third, if none of those connects, accept that this network has chosen not to carry VPN traffic and use mobile data for anything you would rather keep private.
Rule out the two look-alikes
Three different problems produce the same "connecting" spinner, and only one of them is a block.
The sign-in page. Hotels, airports, cafés and campuses put a captive portal in front of the network. Until it is accepted, nothing gets through, including the VPN. Open a browser without the VPN and load a plain page; if a sign-in screen appears, that was the whole problem. The captive portal post explains why Android's "Block connections without VPN" can stop the page from loading.
No internet at all. The venue's uplink is down, the portal has expired overnight, or the router has run out of addresses. Again, load a plain page without the VPN. If nothing loads, no VPN setting will help.
Actual filtering. Plain pages load fine, but the VPN never connects, or says connected while nothing loads. This is the case the rest of this post is about.
How networks filter, and what each one does to a VPN
Networks you do not control filter for their own reasons: keeping load down, limiting abuse, or applying a security policy written for a different purpose. The common mechanisms are:
| What the network does | Why it does it | Effect on a VPN |
|---|---|---|
| Drops UDP except DNS | Cuts load and abuse; most web traffic is TCP | WireGuard's handshake gets no answer |
| Closes ports other than 80 and 443 | Allows web browsing and little else | Anything on a non-web port is silent |
| Recognises VPN handshakes and drops them | Firewall policy, often a default rule set | Even VPN traffic on port 443 is dropped if it has a VPN protocol's shape |
| Inspects TLS and refuses unknown server names | Strict corporate policy | Only a transport that is an ordinary HTTPS session connects |
The first two rows describe most hotels, cafés and campus networks. The third and fourth are rarer and mostly corporate.
What a well-built app does about it
An app that tries one method and reports failure leaves you to guess. An app built for filtered networks tries several, each with a short budget, in an order that goes from quickest to most compatible:
- WireGuard over UDP, on more than one port. The quickest option. Trying port 443 as well as the usual WireGuard port helps on networks that allow UDP only where video calls use it.
- A TLS-wrapped transport on TCP port 443. The VPN traffic is carried inside a TLS connection to port 443, which is what every HTTPS website uses. To the network's equipment it is a web connection. This is slower than WireGuard, because TCP recovers from packet loss more cautiously, but it connects on networks that allow only web traffic. The port 443 post explains why that port is special.
- IKEv2. A final attempt, also over UDP, for the unusual network where the first two failed for reasons other than filtering.
The whole sequence should take well under a minute. You should not need to change a setting or pick a protocol; the app should do this itself.
Things you can check
- Load a plain web page without the VPN, to rule out the look-alikes above.
- Disconnect and reconnect the VPN once, and give it a full minute before deciding.
- Check the app is up to date. Newer versions add or improve connection methods.
- Switch to mobile data for a moment and connect. If it connects instantly there, the server is fine and the Wi-Fi is the difference.
- If the venue has a second network, a staff or premium tier, it may be filtered differently.
If the VPN connects but nothing loads, that is a different fault. The connected-but-no-internet post covers it.
When to stop trying
Some networks are configured to carry no VPN traffic, full stop. That is the operator's decision to make on their own network, and an app that kept trying increasingly elaborate ways to look like something else would be working against the people whose Wi-Fi you are borrowing. The practical answer on such a network is mobile data, or a phone hotspot, for anything you want to keep private, and the venue's Wi-Fi for everything else.
It is also worth checking the venue's acceptable-use policy, particularly on a campus or at work, since some prohibit VPNs in writing rather than just filtering them. The campus post goes into that.
Culvert VPN tries its connection methods in order on every network without showing you a protocol picker, settling on the TLS transport over port 443 when UDP is dropped, on Google Play.
Questions people also ask
How do I know the Wi-Fi is blocking the VPN and not something else?
Load a plain web page without the VPN. If it loads, the network is up and the portal is accepted, and a VPN that still cannot connect after trying its methods is being filtered. If it does not load, the problem is upstream of the VPN.
Why does the VPN connect on mobile data but not on this Wi-Fi?
Because mobile data carries UDP and every port freely, and this network does not. The difference is the network, not the app or the server.
Is there a setting in the VPN app I should change?
In a well-built app, no. It should try WireGuard over UDP, then a TLS transport on TCP port 443, then IKEv2 by itself. If none connects, the network has decided to carry no VPN traffic, and no setting changes that.