Handoff Stops Working When the VPN Connects: What to Check

Open a page on the iPhone, walk to the Mac, and the Dock icon does not appear. Turn the VPN off and it works. That sequence looks like a VPN problem, and it often is, but not for the reason people assume: Handoff is a local, device-to-device feature, and the tunnel is interfering with the local part rather than the internet part.

Fix one task and one pair of devices

Pick a single Handoff-capable task, such as a web page in Safari or a draft in Notes, and a single pair of devices. Keep the app, the accounts and the physical positions identical while you change one variable at a time. A test that moves three things at once produces an observation you cannot use.

Handoff is task continuation, not screen casting or file sharing. If the requirement is to mirror a display or mount a share, you are debugging a different feature with different prerequisites.

Write the exact task down, because the verifier of any fix is that same task working.

The prerequisites are local, not remote

Apple's Handoff requirements are nearby compatible devices, Wi-Fi and Bluetooth enabled on both, the same Apple Account signed in, and Handoff turned on. Check the account used for Continuity rather than the account that bought an app, because those can differ on a shared Mac. Then confirm that the app and the task actually support Handoff, since an arbitrary app staying open proves nothing. Those checks are cheap, and they are the first things to rule out.

All of that happens over local radios. Bluetooth advertises the activity and Wi-Fi carries the payload, which is why the devices have to be near each other even when both have internet access.

None of it depends on the public address either device uses.

What the VPN client does to local traffic

A full-tunnel client can capture the local subnet along with everything else, and some clients do exactly that unless you allow local network access. Apple warns that VPN configurations preventing local networking can interfere with Continuity features. That is a statement about the client's policy, not about one specific blocked port.

Many clients expose a local-access exception; read what it permits before enabling it, and prefer the vendor's supported option over editing firewall rules by hand.

If the client has no such option, the design decision belongs to whoever owns the deployment.

What a shared exit does not buy you

Two devices using the same VPN server share an egress address, and that is all they share. It does not create the Bluetooth advertisement, it does not put them on the same local link, and it does not fix a mismatched Apple Account. Treating a common public address as the prerequisite is a category error that leads to pointless client changes.

Subscriber isolation on the VPN service is also a different question from two nearby devices continuing a task, so opening forwarding between subscribers is not a Handoff step.

A router-based VPN changes which policy applies to the devices, and it still does not supply a missing radio or account.

Decide with the policy owner, then verify both results

Three conditions decide the fix. Does the prerequisite chain hold with the VPN off? Does the client have a supported local-access option, and does policy allow it? And can you verify the change without weakening the protection the tunnel exists for? If the third answer is no, the change needs the administrator rather than a workaround.

After an approved change, confirm both outcomes: the task continues on the nearby device, and the applications that need the tunnel keep their intended access and blocking behavior.

Record the exception next to that connection's configuration, or the next profile update will quietly remove it.