NetDiag+

WireGuard handshake fails on iOS but not on other devices

Same network, same config file: the Linux laptop and the Android phone connect instantly, while the iPhone keeps repeating handshake did not complete. Switch that iPhone to 5G and the tunnel comes straight up. Almost everyone reaches for the MTU setting at this point, and almost everyone is wasting their evening — a failed handshake cannot be an MTU problem.

What to test, in order

  1. Stop changing the MTU. A WireGuard handshake initiation is 148 bytes and the reply is 92. Those fit inside every MTU ever deployed, so nothing is being fragmented. A handshake that never completes means the packets are not arriving at all. Put the MTU back to 1420 and leave it there.
  2. Check whether UDP leaves the device. Run a STUN query on the Wi-Fi that fails. If it answers, UDP egress works and the problem is the specific port or endpoint. If it times out here but answers on cellular, this network is filtering UDP for this device.
  3. Compare what the two devices see. Put the iPhone's IP, subnet mask, gateway and DNS next to the laptop's. A different subnet or gateway means the phone landed on a guest VLAN, or a per-device profile is applied to it on the router — the restriction lives there, not in your config.
Download on the App Store

Free · 25 tools · one-time purchase removes ads · no subscription

Questions people actually ask

Why does it work on 5G but not on Wi-Fi?

That is the most useful clue you have. Identical config, identical server, different result — so the variable is the network, not the tunnel. Your carrier passes the handshake and this Wi-Fi network does not.

I tried MTU 1280, 1200 and 1100. Nothing changed.

Expected. MTU governs the size of packets carried inside the tunnel, which only matters once the tunnel exists. Before the handshake completes there is no tunnel and nothing to fragment.

Could the network be blocking the UDP port?

It is the likeliest single cause, especially on hotel, campus, office and some mobile-hotspot networks. Try moving your server's listen port to 443 or 53 — traffic there usually passes, because blocking those ports would break the web for everyone.

What about Private Relay, Limit IP Address Tracking and Private Wi-Fi Address?

Worth switching off while you test, but rarely the cause. They change which address you appear from; they do not decide whether a UDP packet reaches your endpoint.

So when does MTU actually matter for WireGuard?

After the handshake. The signature is a tunnel that connects fine and then stalls on anything large: a page half-loading, a transfer freezing after a few kilobytes. 1420 is the usual value over IPv4.

If your tunnel connects and then stalls on large transfers, that one really is MTU. How to measure your real Path MTU →