9 August 2026
Why your school wifi blocks your VPN
The standard advice when a VPN will not connect is to try a different server. On a school or office network that advice is useless, and understanding why tells you most of what you need to know about the thing blocking you.
The mental model most people have is a bouncer with a list of names. The network keeps a list of known VPN server addresses and refuses anything headed for one. If that were right, a server too new to be on the list would get you through, and the whole problem would be a race between your provider adding servers and the filter adding addresses.
That is not how any of this works, and it has not been for years.
The filter reads the handshake, not the address
Nearly every VPN protocol announces itself in its first packet.
WireGuard opens with a fixed-size UDP message starting on a known byte pattern. OpenVPN puts an opcode in a predictable position, then wraps a TLS handshake in a structure nothing else uses. IPsec negotiates on well-known ports with well-known message types. None of these were trying to be discreet about what they were. They were trying to be secure, which is a completely different problem.
A filter doing deep packet inspection watches traffic pass and matches it against those patterns. See the shape of a VPN handshake, drop the connection. Where the packet was going never enters into it. Point a recognisable protocol at a server nobody has ever seen before and it dies exactly as fast as one on every blocklist, because the thing being recognised is the protocol.
So "try another server" does not fail because you picked badly. It fails because you are answering a question nobody asked.
Why the network can do this at all
Campus networks are unusually well placed for it. They own the entire path from your laptop to the internet, they push everything through one gateway, and they have reasons to look that a court would call legitimate: content filtering for under-18s, bandwidth management, and in a lot of cases a legal duty to enforce an acceptable use policy.
The equipment is boring, off-the-shelf stuff. Firewall vendors ship VPN protocol signatures as a category you switch on with a checkbox, sitting in a list next to streaming and gaming. Nobody at your school wrote a packet parser. Somebody ticked a box.
Which also explains why the blocking tends to be so blunt. A checkbox has no opinion about why a person might want an encrypted connection on a network full of strangers.
Three other things that look identical from your side
Deep packet inspection is the main event, but it usually arrives with company, and the symptoms are easy to confuse.
Port restrictions come first. Plenty of networks permit outbound 80 and 443 and close the rest. A VPN on its default port never even reaches the inspection stage; it is dropped before anything looks at it.
DNS interception is the sneakiest of the three. The network answers your DNS queries itself, whatever server you configured, and hands back its own answers for anything blocked. If your VPN client resolves its server's hostname before the tunnel exists, an intercepted answer breaks the connection at step one, and the failure looks precisely like protocol blocking.
Certificate inspection is the odd one out, because it has nothing to do with the network. A school-owned laptop may carry an institutional root certificate that lets the network decrypt HTTPS. That is a property of the device, not the wifi, and no VPN has ever changed what an administrator can see on a machine they administer.
So what does get through?
If the problem is that your traffic looks like a VPN, the answer is traffic that does not.
That is what obfuscated transports are for, and it is a genuinely different goal from encryption. Encryption makes the contents unreadable. Obfuscation aims at something else: making the connection unremarkable, so that whatever is inspecting it has no reason to care. In practice that means looking like ordinary HTTPS headed somewhere ordinary.
The methods vary. Some wrap the tunnel in a real TLS session. Some copy the handshake of a specific well-known site closely enough to survive comparison against the genuine article. Some worry less about contents than about the statistical shape of the traffic, since packet sizes and timings remain a fingerprint long after the payload has gone opaque.
None of it is permanent, and anybody who tells you otherwise is selling something. A transport that works everywhere today is a transport nobody has written a signature for yet. Having several, and falling back automatically when one dies, matters more than which one you started with.
The part that is not a technical problem
I want to be straight about this, because a lot of writing on the subject slides past it: getting through the filter and being allowed through the filter are separate questions.
Using a VPN is legal in the UK and most other places. Your school's acceptable use policy is its own thing, it almost certainly does prohibit circumventing the filter, and no amount of protocol obfuscation changes what happens if you are found to have breached it. If the device belongs to the school, what you install on it is visible to whoever manages it, whatever the network can or cannot see.
Those are real constraints, and worth knowing before you decide anything. They are also not what most people are actually asking about, which is whether the connection will hold at all.
Pangea's desktop app tries five obfuscated transports in order and keeps the first one that connects, without asking you to configure anything. The VPN for school wifi page has the specifics, including a plain list of what it will not do for you.