FaceTime Works but Mac Can't Call Through Your iPhone

You can start a FaceTime audio call from your Mac without a hitch, then dial a plumber's number from the same Mac and nothing happens. The usual reading is that the network is healthy and something unrelated broke. That reading is the myth, and it survives mostly because FaceTime looks like a fair test.

It is not. FaceTime audio and phone relay are separate transports with separate requirements, and one of them survives a tunnel the other cannot cross.

The VPN is not guilty by default either. The order below removes both assumptions before you touch another setting.

FaceTime passing tells you almost nothing

FaceTime audio negotiates a connection to a reachable peer. That traffic can cross the internet, including a full-tunnel VPN, as long as both ends can exchange packets. Phone relay does not leave the building. Your Mac asks a nearby iPhone to place the call on its cellular line, and that request is local.

So a working FaceTime call proves the Mac has usable internet and can reach Apple's services. It says nothing about whether the Mac can see the iPhone sitting next to it. Two devices can share an SSID and still be invisible to each other.

That is the whole myth in one line: no call that leaves the building tests the local link.

What the relay path actually requires

Every item on Apple's list is mandatory rather than additive. Both devices on the same Wi-Fi network, both signed in to the same Apple Account, both signed in to FaceTime with the phone number enabled, and Calls on Other Devices turned on for the Mac you want to use. The iPhone calling guide is the reference for the current wording.

On a recent iPhone the switch sits under Settings, Apps, Phone, Calls on Other Devices, and your Mac has to appear in that list and be enabled. When the Mac first tries to use the line, macOS asks whether to allow calls from that iPhone. Dismiss that prompt once and the feature stays broken quietly, because nothing asks again.

The Mac side depends on the system version. Recent macOS releases ship a Phone app, older ones route calls through FaceTime. If a tutorial points at a menu you cannot find, check the version before deciding a setting is missing.

Where a VPN genuinely interferes

A VPN client can break relay in three distinct ways, and only the first one is documented. The documented case is a configuration that prevents local networking: macOS warns that such a VPN may interfere with Continuity features, and relay is a Continuity feature. The second is a full tunnel that captures the traffic the Mac would use to reach the iPhone, so the local request leaves for a gateway that has no use for it. The third is a client that applies its own filtering or kill switch to every interface instead of only the tunnel.

A split tunnel that carries only corporate subnets usually leaves the local path alone. That is why the same Mac can pass on one VPN profile and fail on another, and the difference between the two profiles is the useful signal.

Be strict about what the comparison proves. Working without the VPN and failing with it is an interaction, not a diagnosis. It does not name the protocol, port, or interface that was blocked, and inventing routes from that alone makes the next test worthless.

Three failures that get blamed on the VPN

Wi-Fi Calling. This is a carrier feature on the iPhone, not something the Mac inherits. It lets the phone use the carrier's service over Wi-Fi, not every carrier offers it, and it is useless when the iPhone is off, out of range, or on a network that blocks the carrier's endpoints. If your real requirement is calling while the iPhone stays home, relay was the wrong mechanism to test from the start.

Network isolation. Guest networks, client isolation on an access point, and separate VLANs produce exactly the relay symptom, same SSID and no visibility, with no VPN in the picture. If the building's Wi-Fi isolates clients, no setting on your Mac will change the result.

Handoff. Handoff continues an activity across devices. It does not hand your Mac a cellular line and it is not a substitute test. Seeing the Handoff icon appear does tell you the two devices can find each other, which is worth knowing, but it stops well short of proving call routing works.

A test order that produces evidence

Start from a known state: iPhone unlocked and nearby, both devices on the same Wi-Fi, VPN disconnected on the Mac. Place one outgoing call and receive one incoming call. Both directions matter, because they fail for different reasons. Outgoing depends on the Mac reaching the line, while incoming depends on the iPhone treating that Mac as a valid target.

Reconnect the VPN using the profile you actually work with and repeat both calls without changing anything else. If both still work, the VPN is not your variable and you should stop adjusting it. If both break, record the profile name, the client version, and whether local traffic is excluded, then give those three facts to whoever owns the configuration.

If only one direction fails, look at the iPhone's call settings before the tunnel. Asymmetric failure is far more often a per-device toggle than a routing problem, and that one observation saves an afternoon.

What to confirm before you escalate

Work through these five items in order and write down the answer to each: same Wi-Fi network, same Apple Account, phone number enabled in FaceTime, this Mac enabled under Calls on Other Devices, and the macOS allow prompt accepted. Anything you cannot confirm is a free candidate cause.

Then decide what you are optimising for. If calls only need to work at your desk, excluding local traffic from the VPN profile is usually enough and does not weaken the tunnel's purpose. If they need to work while the iPhone is somewhere else, relay is the wrong feature and the carrier question comes first.