Category: MacOS

If you’ve ever tried connecting your MacBook to a T‑Mobile iPhone hotspot only to find that FortiClient, GlobalProtect, or other VPNs refuse to pass traffic or connect at all, you’re not alone. The hotspot provides perfectly normal internet access, but the VPN has issues.

Here’s the short version of why it happens and the simple workaround that fixes it.

The Cause: T‑Mobile’s IPv6‑Only Hotspot Path

T‑Mobile’s mobile network is largely IPv6‑only, and when your Mac connects to an iPhone hotspot, it often receives only an IPv6 address, not a real IPv4 lease. To keep IPv4‑only apps working, the carrier uses DNS64/NAT64 translation mechanisms that synthesize IPv6 addresses for IPv4 destinations. This system works for normal browsing but breaks many enterprise VPN clients, which often expect either:

• A real IPv4 path, or
• A fully IPv6‑capable VPN gateway (many aren’t)

As a result, the VPN may connect but fail to pass traffic—or fail during negotiation—when used over a T‑Mobile hotspot. 

The Easy Workaround

Fortunately, the fix is simple:

Force IPv4 on the Mac for this hotspot SSID.

You can do this by disabling IPv6 on the Wi‑Fi interface whenever you join the hotspot. Once IPv6 is off, the Mac stops using DNS64/NAT64, and the VPN behaves normally again. This avoids the synthetic IPv6 addressing that causes the VPN tunnel to break. 

A Smooth Way to Automate It

Instead of toggling settings manually, macOS lets you create a dedicated Network Location:

1. System Settings → Network → (…) → Locations → Edit Locations
2. Create a new location, e.g., “T‑Mobile Hotspot IPv4”
3. With that location selected, open your Wi‑Fi interface → Details → TCP/IP
4. Set Configure IPv6 → Off
5. Switch to this location whenever you join the hotspot

Now you have a one‑click way to force IPv4 whenever you tether.

Wrap‑Up

The problem isn’t your Mac, your VPN client, or even your employer’s firewall—it’s simply how IPv6‑only networks interact with VPN protocols that weren’t built with translation layers in mind. For now, flipping your Mac into IPv4‑only mode on that hotspot SSID is the cleanest and most reliable solution.

Radtest is a tool that is part of the FreeRadius server package that can be installed with HomeBrew on macOS: https://formulae.brew.sh/formula/freeradius-server

Install command: 

brew install freeradius-server

Once installed, you can run the command like this:

radtest lscaringella "passwordhere" [server IP here] 10 [secret here]

Depending on the Radius server, you may have to ensure that your machine that you are testing from is added as a trusted Radius client on the server.

I have noticed that at times when using FortiClient for remote access VPN connections with MacOS, that after disconnecting from the VPN, the DNS settings added by FortiClient for DNS resolution over the VPN, fail to be removed.

When connecting to the VPN, an entry is added to /etc/resolver for the domain name associated with resources behind the VPN tunnel. For example, a resolver for example.com is added here. When on the VPN, this allows the user to resolve a hostname such as dc01.example.com. However, when the VPN disconnects, this should be removed. If the domain name used internally is the same as that used externally, then once the VPN is disconnected, with that resolver still in place, it will attempt to resolve DNS using that resolver over the disconnected VPN causing subsequent connections to the actual VPN to fail.

If the VPN hostname is vpn.example.com, and the resolver is still there, it fails to resolve and can’t connect to the VPN.

The solution I have found is to go to /etc/resolver, run “ls”, then run “rm example.com” to remove this. After doing this, resolution should use the system DNS servers and work as expected.