VPN over 5G versus Wi-Fi
Cellular networks differ from home broadband in ways that matter to tunnels. NAT mappings expire faster, many cores are IPv6-only with translation at the edge, the usable packet size is smaller, and keeping a tunnel alive keeps the radio awake more often than it otherwise would.
4 min read
5G is fast enough that raw throughput is rarely the interesting question. What differs from Wi-Fi is everything around it: how long a connection's state survives, which address families exist, how large a packet can be, and what keeping a tunnel open does to the radio.
Throughput and latency
A good 5G connection delivers hundreds of megabits, comfortably more than most household use requires. Latency on a mid-band 5G network is typically 20 to 40 milliseconds, against 5 to 15 on decent fixed broadband.
A tunnel costs the same proportional throughput it costs anywhere, and adds the same round trip to the server. Nothing surprising there.
What varies far more than the tunnel is the radio: signal strength, cell loading, and whether you are on mid-band or a low-band fallback can change your numbers by an order of magnitude between two rooms.
Carrier NAT and short timeouts
Mobile operators put subscribers behind shared address space defined in RFC 6598, and their translation tables expire entries aggressively — sometimes in under a minute, because they are managing millions of subscribers rather than a household.
A tunnel that goes idle can therefore lose its path back. The symptom is a connection that works, sits idle in your pocket, and is dead when you look at it.
The fix is a keepalive. WireGuard's PersistentKeepalive = 25 sends an empty
packet every twenty-five seconds, holding the mapping open. It costs a trivial
amount of data.
IPv6-only cores
Several large carriers run IPv6-only to the handset, translating to IPv4 at the network edge with NAT64 and DNS64. Your phone genuinely has no IPv4 address.
Two consequences for tunnels:
An endpoint configured as a literal IPv4 address may be unreachable, because nothing looks it up and therefore DNS64 never synthesises an IPv6 address for it. A hostname endpoint works; a bare address may not.
A tunnel that carries only IPv4 covers less than you think. On an IPv6-only attachment, an IPv4-only tunnel is handling a translated subset while native IPv6 traffic goes around it.
MTU is smaller and less predictable
Cellular links often carry a smaller MTU than Ethernet, and carrier-side tunnelling reduces it further. A tunnel MTU that is correct on Wi-Fi can be too large on mobile.
The symptom is the classic one: small requests work, pages with images hang. 1380 is a sensible mobile value; 1280 is the floor worth testing.
Battery
This is where mobile genuinely differs rather than merely varying.
A phone's radio moves between power states, and returning from idle costs energy. A tunnel that sends a keepalive every twenty-five seconds prevents deep idle more often than an idle phone would otherwise experience.
The honest figures: a modern phone running WireGuard costs a few percent of battery a day. OpenVPN costs more, because it does more work per packet and maintains a session. What costs far more than either is a client stuck in a reconnection loop on a marginal signal, which is the usual cause of a phone that seems to lose half its battery to a VPN.
Switching between Wi-Fi and cellular
WireGuard handles this gracefully: it is stateless between packets, so the first packet from the new address updates the server's record and nothing reconnects.
OpenVPN does not, because it maintains a TLS session that must be rebuilt. That is the two-to-ten-second pause when a phone changes network.
IKEv2 with MOBIKE handles it too, by explicitly telling the server it has moved. This is why the protocol persists on phones despite its age.
Practical settings for mobile
- Keepalive on, to survive carrier NAT timeouts.
- MTU 1380, or lower if large pages stall.
- Always-on VPN and a kill switch, because a phone changes networks constantly and each change is a window.
- Battery optimisation off for the client, or the system will suspend it with the screen off. On Android this is the single most common cause of overnight disconnections.
- A hostname endpoint, so IPv6-only carriers can reach it.
Measure the result with the speed test on the phone rather than assuming what a desktop measurement implies. Mobile is variable enough that one reading in one place is not a number you can generalise from.
