When a network drops UDP, and what a VPN can do about it

Some networks you do not control drop UDP traffic, either entirely or apart from DNS. WireGuard, the protocol a modern VPN app tries first, runs over UDP, so on such a network its handshake goes out and nothing comes back. There is no error, only silence. What a VPN can do about it is switch transport: a well-built app moves on to a TLS-wrapped transport on TCP port 443, the same kind of connection a web browser makes, and keeps that as long as it carries traffic. You lose some speed and nothing else.

UDP and TCP in one paragraph each

TCP is a connection. Both ends agree to talk, every byte is numbered, anything lost is sent again, and the receiver sees data in order. Web pages, email and file transfers use it because they need every byte.

UDP is a postcard. Each packet is sent on its own, with no agreement and no retransmission. Video calls, games, DNS and WireGuard use it because they would rather handle loss themselves than wait for a retransmission that arrives too late to matter. For a VPN, UDP is the better carrier because the traffic inside it already has its own loss handling, and adding a second layer makes things worse. The UDP vs TCP post covers the trade in detail.

Why some networks drop it

Network operators drop UDP for reasons that have nothing to do with VPNs.

Simplicity. A guest network that wants to allow web browsing needs only TCP on ports 80 and 443. Allowing nothing else is the shortest rule set, and it is the default on a lot of hotel and café equipment.

Abuse. UDP is the transport of choice for traffic floods, because there is no handshake to complete. Some firewalls rate-limit or drop it on principle.

Old policy. Corporate and campus firewalls often carry rules written years ago, when nothing a business needed used UDP. Nobody has revisited them because nothing important broke.

The one exception nearly every network makes is DNS on UDP port 53, because without it nothing resolves. A few allow UDP 443 as well, since HTTP/3 uses it and blocking it degrades video calls and some large sites.

What it looks like from the phone

The signature of dropped UDP is silence rather than refusal. A blocked TCP port often produces an immediate error; a dropped UDP packet produces nothing, so the app waits for a timeout. From the user's side:

• The VPN sits at "connecting", then fails or moves on, with no message about why.
• The same app connects instantly on mobile data.
• Video calling apps on the same Wi-Fi fail to connect or fall back to a lower-quality mode.
• Occasionally the VPN reports connected and nothing loads, if the app judged the tunnel up before checking that traffic actually flowed. The connected-but-no-internet post covers that failure.

What a well-built app does

It should not leave you to diagnose any of this. The design that works is a short sequence of attempts, quickest first, each with a small time budget:

1. WireGuard over UDP, on several ports including 443. Trying 443 catches networks that allow UDP there for HTTP/3 while dropping it elsewhere.
2. A TLS-wrapped transport on TCP port 443. The app opens a real TLS connection to the VPN server, exactly as a browser would to a website, and carries the VPN's packets inside it. A network that allows HTTPS allows this.
3. IKEv2, as a final attempt. It is also UDP, on ports 500 and 4500, so on a network that drops UDP it will not connect either; it exists for other failure cases.

The app then keeps the method that carried traffic. The test for "carried traffic" should be real: a request sent through the tunnel and answered from the far side, not merely a completed handshake. The port 443 post explains why that port is the one worth trying twice.

What the TCP transport costs

Carrying a VPN inside a TCP connection means two layers of reliability. The outer TLS connection retransmits anything lost on the Wi-Fi link, and while it waits, the traffic inside, which has its own retransmission timers, may also decide something was lost and resend. On a clean link this rarely triggers and the transport runs close to the link's speed. On a lossy link, a crowded hotel floor or a café with one old router, it shows up as short stalls, particularly in video.

The practical rule is that TCP 443 is the right answer on the network that needs it and the wrong default everywhere else, which is why the order above tries UDP first.

When UDP is fine but something else is wrong

Not every "connecting" spinner is dropped UDP. A sign-in page that has not been accepted blocks everything, TCP included; the captive portal post covers that. A network that is simply down blocks everything too. The distinguishing test is to load a plain web page without the VPN: if it loads and the VPN still needs the TCP transport, UDP is the difference.

Culvert VPN tries WireGuard over UDP on several ports and then moves to its TLS transport on TCP 443 on its own, treating a tunnel as connected only once a request has actually gone through it and come back, on Google Play.