Why VPN does not work on mobile internet — an analysis
If a VPN works normally at home over Wi-Fi but does not connect on mobile internet, or connects with no internet access, the cause is almost always a combination of three factors: operator filtering of UDP/protocols, CGNAT with an aggressive timeout, and a low effective MTU. The fix is to change the protocol, ports, and MTU.
A mobile network is built differently from a home connection: between your device and the internet there are operator NATs, traffic-type filters, port restrictions, and DPI that detects and cuts non-standard packets. The same VPN client with the same settings can behave completely differently on Wi-Fi and on LTE.
Below is a breakdown of exactly how mobile internet breaks VPNs and what to do about it. At the same time, a check through Freedom Checker will show which operators currently allow your protocol through.
Short answer
- Mobile operators cut UDP more aggressively than home ISPs — WireGuard and OpenVPN UDP often do not get through.
- CGNAT drops “quiet” tunnels after 30–120 seconds — keepalive is needed in the VPN settings.
- On LTE, the effective MTU is lower than at home — WireGuard at 1420 often breaks, and 1280–1380 helps.
- Changing the protocol to TCP/443 helps: OpenVPN TCP, VLESS Reality, or Hysteria 2 with a longer keep-alive.
- The same service may work on MegaFon and not work on MTS — this is normal.
Why mobile internet breaks VPNs: the main reasons
There is not one reason, but four. Which one applies to you is determined by how the tunnel behaves when connecting.
1. Operator filtering and protocol blocking
Russian mobile operators (MTS, MegaFon, Beeline, Tele2, Yota) use TSPU filters and their own policies at the point where the mobile network connects to the internet. Plain WireGuard and OpenVPN UDP are often filtered by signature before they reach the server. On a home connection, the same filtering may be weaker or absent.
What helps: masking protocols (VLESS Reality, Hysteria 2, Shadowsocks 2022), TCP/443 instead of UDP, AmneziaWG instead of plain WireGuard.
2. CGNAT and session timeouts
Mobile operators put thousands of subscribers behind one external IP address through Carrier-Grade NAT. This type of NAT has an aggressive timeout: if no traffic passes through a connection for 30–120 seconds, the table entry disappears. After that, the next packet goes “nowhere”; the tunnel looks alive on the client side, but is effectively dead.
Solution: enable persistent keepalive in the VPN client (for WireGuard — 15–25 seconds); for OpenVPN, use the keepalive parameter.
3. MTU and fragmentation
A mobile network often does not pass large packets. If the MTU inside the tunnel is 1420 (the WireGuard default) while the operator only passes 1400, the ICMP message saying that fragmentation is needed may not arrive. The tunnel is up, but large packets such as HTTPS pages or video are lost.
Solution: reduce the MTU to 1280–1380 in the VPN client settings.
4. Regional differences and roaming
The same operator configures TSPU differently in different regions. Different policies are also possible when roaming between regions. This explains why your VPN worked in one city and broke in another with no visible reason.
How to understand what exactly broke
| Symptom | Possible cause | What to check |
|---|---|---|
| Works on Wi-Fi, but on LTE does not connect at all | The operator blocks the protocol / port | Switch to VLESS Reality / Hysteria 2 / TCP 443 |
| Connects, but after a minute or two there is no internet | CGNAT drops the session by timeout | Enable persistent keepalive at 15–25 sec |
| Sites load slowly or “hang” on large files | MTU is too large | Reduce MTU to 1280–1380 |
| Works on one operator, but not on another | Different filtering policies | Switch to a masking protocol |
| Works in one city, but not in another | Regional TSPU settings | Test with another protocol |
| Connects and immediately disconnects | DPI cuts the handshake | Switch to Reality / Hysteria, disable aggressive power saving |
How to check right now
Freedom Checker regularly checks the availability of sites and protocols through Russian mobile operators. This makes it possible to understand whether the problem is with your specific device/settings or with the operator’s policy in general.
A simple check: connect to LTE and try opening a neutral site without a VPN. If it opens, the mobile internet connection is alive and the problem is in the tunnel. If nothing opens, the problem is with the APN, balance, or coverage area.
Failure or blocking?
If the VPN does not work only on LTE from one operator, while it works on other operators in the same region, this is operator filtering. Only changing the protocol helps.
If it stopped working at the same time on all operators in the region, it is probably regional blocking by the service’s IP subnet or mass TSPU activity. Changing the VPN service or protocol helps.
What to pay attention to
- Compare behavior on Wi-Fi and on LTE — this immediately shows who is at fault.
- Try tethering LTE from another phone — this separates a network problem from a device problem.
- On Android, disable battery saving for the VPN app — otherwise the service will be killed in the background.
- Check the operator’s APN — some AI plans have special APNs through which VPN is prohibited.
- Do not turn off mobile data and Wi-Fi at the same time — the VPN may “hang” on the old interface.
- Enable forced TCP/443 in the VPN client — this is the most “invisible” transport.
- The situation may differ by operator, region, and time of the check.
Conclusion
Mobile internet breaks VPNs differently than home internet: protocol filtering + CGNAT timeouts + MTU limits. The deciding factor is not the service itself, but the right combination of protocol, ports, and keepalive.
If your VPN drops only on LTE, switching to a masking protocol over TCP/443 and reducing the MTU almost always helps.