Nicholas Clooney

Debugging Tailscale on UK Mobile Networks: A Journey into NAT, DERP, and IPv6

Introduction

What started as a simple question — "Why can’t I reach my MacBook over Tailscale from my iPhone on mobile data?" — turned into a deep dive into NAT types, relay servers, and the hidden power of IPv6. This post documents the technical journey, the dead ends, and the final conclusion.

The Problem I Had

  • On UK mobile data, the iPhone could SSH into a VPS (US-based) over Tailscale just fine.
  • But when I was trying to connect to my MacBook (at home on Hyperoptic broadband) failed.
  • Running tailscale ping iphone on the MacBook timed out, and tailscale ping mac from iPhone showed relay LHR but still failed.
  • On the same Wi-Fi network, iPhone ↔ Mac worked perfectly.

So the mystery: why do VPS connections work, but Mac connections fail?

Read further on to find out there was one simple fix!

First Clues

  1. Mac Tailscale netcheck (initially):

    IPv6: no
IPv4: yes, behind NAT
PortMapping: UPnP, NAT-PMP, PCP
MappingVariesByDestIP: false

    → At first, Mac did not have IPv6. It was behind NAT but the router supported port mapping, so NAT was not symmetric.

  2. Ping results:

    • tailscale ping debian (VPS) → worked, direct IPv4 path.
    • tailscale ping iphone → failed, even via relay (DERP LHR).

  3. Sleep was ruled out (Mac was configured never to sleep).

The Double NAT Discovery

Initially the Mac was behind double NAT (home router + ISP box). After plugging the router directly:

  • WAN IP showed 100.71.x.x → inside 100.64.0.0/10, confirming Carrier-Grade NAT (CGNAT).
  • Result: Mac was still not directly reachable over IPv4.

Trying IPv6

Hyperoptic provided IPv6 (example, dummy addresses for illustration):

  • Router got a /56 prefix: 2a01:abcd:1234::1/56
  • Mac received a global IPv6: 2a01:abcd:1234::97d2
  • Confirmed with browser tests: the Mac was globally reachable over IPv6.

This was a breakthrough: no more NAT for the Mac.

The iPhone Test

The missing piece was the iPhone’s mobile connection:

  • Visiting https://test-ipv6.com/ (Avoid Safari, in case you have Private Relay on) on iPhone (mobile data only) showed: IPv6: no.
  • Confirmed: iPhone had only IPv4 (CGNAT).
  • Safari Private Relay briefly tricked us into thinking IPv6 was present, but it was just Apple’s proxy.

Conclusion: iPhone mobile network is IPv4-only, CGNAT.

Why VPS Worked, but Mac Didn’t

  • iPhone → VPS: VPS has public IPv4 → direct connection succeeds.
  • Mac → VPS: Mac can connect outbound → succeeds.
  • iPhone ↔ Mac: both behind NAT/CGNAT → no direct path. Must use DERP.
  • But DERP relay (UDP) was unreliable on mobile carrier → packets dropped.

Final Findings

  1. Mac is fine: with IPv6, it’s globally reachable.

  2. VPS is fine: public IPv4 makes it easy.

  3. iPhone mobile carrier was the blocker at first:

    • Initially, no IPv6 support → stuck in IPv4 CGNAT.
    • DERP UDP traffic was flaky or blocked → relay fallback failed.

  4. The One Simple Fix: But later, after activating the UK SIM properly, the iPhone suddenly received a public IPv4 (85.xxx.xxx.xxx). This allowed direct iPhone ↔ Mac connectivity without DERP.

Potential Workarounds

(if you don't have a public IPv4 address for your mobile)

  • On Mac: could force DERP to guarantee relay, but the real issue is on iPhone’s side.
  • Alternative: use VPS as an exit node / relay for iPhone → Mac traffic.
  • Long-term fix: switch to a mobile carrier that offers either public IP address, or IPv6 on mobile data.

Conclusion

This long journey showed how much the success of peer-to-peer VPNs like Tailscale depends on what’s happening under the hood:

  • CGNAT breaks IPv4 peer connectivity.
  • DERP relays save the day — unless your carrier filters UDP.
  • IPv6 is the real solution, but only if both ends support it.

In our case: the Mac was ready, but the iPhone’s mobile carrier wasn’t. The lesson: sometimes the problem isn’t your device or Tailscale — it’s the invisible network policies between you and the internet.