If your VPN disconnect on Iranian mobile networks follows a specific pattern — handshake succeeds, ping works, small requests load instantly, but anything large stalls after a few seconds — you are almost certainly hitting a Path MTU Discovery black hole. This is the most common VPN timeout cause in Iran, and it is not the VPN app's fault. It is a consequence of ICMP filtering on Iranian carrier networks.
We spent a week diagnosing this at NexTunnel after users on Irancell, MCI, and Rightel filed reports. Here is the complete story: the mystery, the diagnosis, the fix, and why it matters for AmneziaWG users specifically.
The Mystery: Timeouts on Mobile, Fine on Wi-Fi
The reports started arriving in a specific pattern. Users would write: "VPN connects, I can ping Google, but Instagram freezes after a second of loading." Multiple users. Multiple app versions. Multiple servers. The common factor was always the same: mobile data on an Iranian carrier. The same users on Wi-Fi had no problem.
Our initial hypothesis was ISP-level throttling of our Reality borrowed-site IPs. We rotated cover sites. No improvement. We tried different egress ASNs on the server side. Same stalls. The packets were reaching the server — tcpdump showed clean TLS handshakes and the first few kilobytes of response arriving normally. But the client stopped acknowledging somewhere around the 1400-byte mark.
PMTU Discovery and Why ICMP Blocking Breaks It
Path MTU Discovery (PMTUD) is the mechanism TCP uses to find the maximum packet size that fits through every network hop between client and server. When a TCP sender emits a packet with the Don't Fragment (DF) bit set and that packet is larger than a link along the path can handle, a router at that link is supposed to return an ICMP "Fragmentation Needed" message with the maximum allowed size.
Many Iranian carrier networks — particularly those running CGNAT, IPv6 transition tunnels, or older MPLS backbones — have effective path MTUs below the standard 1500 bytes. Some are as low as 1280 bytes. When those carriers also filter ICMP (which is common, both as a misguided security measure and as an accidental side effect of NAT configurations), the ICMP "Fragmentation Needed" message never arrives. The sender keeps emitting 1500-byte packets. The path keeps silently dropping them. TCP retransmits, stalls, and eventually the application times out. This is a PMTUD black hole.
Why This Only Appears on Large Responses
Small requests — DNS queries, HTTP headers, API responses under a kilobyte — fit in a single MTU-sized packet even at 1500 bytes. The problem only appears when the server tries to send a response larger than the path MTU. A Twitter timeline, an Instagram image, a YouTube chunk — all of these trigger the bug. A ping packet does not. This explains the precise symptom: small things work, large things stall.
The MTU=1280 Fix: Why This Number
RFC 8200, the IPv6 standard, requires every IPv6-capable network to be able to carry packets up to 1280 bytes without fragmentation. This is the defined minimum MTU for IPv6. By clamping our inner tunnel MTU to 1280 bytes, we ensure our packets never exceed the smallest path MTU that any network claiming IPv6 support must accommodate.
# VLESS/Xray inbound stream settings
streamSettings:
sockopt:
tcpMss: 1280
# AmneziaWG client config
[Interface]
MTU = 1280We applied this to every NexTunnel server and every protocol: VLESS+Reality, VLESS+WebSocket, Trojan, and AmneziaWG. The fix went live across all servers in a single deployment. We were already running 1280 on WireGuard (it is the WireGuard project's own recommendation), but we had not applied it to the VLESS family.
Why This Works Especially Well for AmneziaWG
AmneziaWG is derived from WireGuard, which has always defaulted to MTU=1280 in most client implementations. This is one of the reasons AmneziaWG performs well on Iranian mobile networks even before our server-side fix: the client already enforces conservative packet sizing. When we matched the server-side MTU clamp to the same 1280 value, we eliminated the one case where server-initiated large sends could still trigger the PMTUD black hole.
For users choosing between Reality and AmneziaWG on Iranian mobile networks: both now benefit from the MTU=1280 clamp on the server side. AmneziaWG has slightly lower CPU overhead per packet, which can matter on budget Android devices. Reality has better censorship resistance against active probing. See nextunnel.com/protocols for a full comparison.
How We Deployed the Fix and What We Observed
We deployed the MTU clamp to our Helsinki server first and monitored connection success rates from Iranian IP ranges over 24 hours. The timeout rate on mobile connections dropped from approximately 23% to under 2% immediately. We then rolled out to all other servers in the pool — Nuremberg, Dubai, USA, and Mexico — over the following 48 hours.
- Mobile connection success rate: 77% → 98% after fix
- Median time-to-first-byte on large responses: 34 seconds stall → under 200 ms
- Throughput cost of the MTU clamp: approximately 1.2% reduction on clean networks — not measurable in user experience
- Secondary benefit: same fix resolved similar reports from users on Russian mobile networks (MTS, Beeline) that also filter ICMP
What to Do If You Are Still Seeing VPN Disconnects
If you are using a NexTunnel subscription, the MTU fix is already applied server-side and you do not need to change anything. If you are using a different VPN provider and experiencing the same pattern of large-response stalls on Iranian mobile, ask your provider to clamp the server MTU to 1280, or set it manually in your WireGuard client config by adding MTU = 1280 to the [Interface] section.
If disconnects continue after the MTU fix, the next thing to investigate is whether Hysteria2 (QUIC-based) resolves the issue. QUIC performs its own path MTU probing in the data layer rather than relying on ICMP, and therefore is structurally immune to PMTUD black holes. NexTunnel includes Hysteria2 on all accounts — try it as a fallback. See the complete Iran VPN guide at /blog/vpn-for-iran-2026-complete-guide.
Related Posts
- The Complete Guide to Using a VPN in Iran in 2026 — /blog/vpn-for-iran-2026-complete-guide
- Why MTU=1280 Fixes Mobile VPN Timeouts (original deep-dive) — /blog/mtu-1280-fixes-mobile-vpn-timeouts