AirDrop Missing With a VPN On? Check Local Routing

AirDrop works, then the VPN connects, and the other Mac or iPhone disappears from the share sheet. Nothing in the VPN log mentions discovery, because the failure is usually about local reachability rather than about cryptography. Apple's support page acknowledges that a VPN configuration which restricts local networking can interfere with Continuity and AirDrop, which is a useful hint and not a diagnosis. Start with the cheap checks, then read the routing table, and treat the local-access switch as a decision about your privacy rather than a default to flip.

What Breaks Before the Tunnel Is Even Involved

Both devices need Wi-Fi or Bluetooth enabled and AirDrop set to receive from contacts or from everyone, within its receiving window, and the two accounts have to be discoverable to each other. Setting the receiver to everyone for ten minutes is a legitimate experiment: if the other device appears there, the settings were the problem and the tunnel is innocent. Test with a known recipient instead of judging by whatever the share sheet volunteers.

A browser that loads pages proves the internet path works, not that local discovery does. Keep both devices and the spot where you are standing unchanged, then toggle the VPN and note whether the other device vanishes only while the tunnel is up. If discovery dies with the tunnel and returns without it, the tunnel is the variable and the rest of this list applies. If it fails in both states, the prerequisites need another pass before any network policy changes.

The Share Sheet Empties When the Default Route Moves

A full-tunnel client usually installs a default route through the tunnel plus two half-routes that capture most destinations. A local subnet survives that arrangement only when it has a more specific route; otherwise it disappears into the tunnel. AirDrop itself runs over the AWDL peer-to-peer interface, so a client that filters or aggressively routes local interfaces can interfere while the internet path stays perfect. Four commands cover the interface, the routes, the active connection and the packet filter.

ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40

Read the default line first: if it points at a utun interface and no more specific route covers your subnet, local traffic goes into the tunnel and awareness disappears with it. The 0/1 and 128.0/1 pair is a common full-tunnel shape, because those routes beat the real default without replacing it. An awdl0 line showing an active status and an address rules out the peer-to-peer interface being down. When all three look normal, the restriction comes from client policy or a host filter rather than the route table.

One shape is worth calling out, because it catches people on guest networks, and it is not the half-routes. DHCP installs the address you were just given as an on-link route, and that entry is more specific than either half, so a guest subnet survives the tunnel exactly as a home one does. What removes it is policy rather than routing: a block-local-network preference that installs a reject rule, a host firewall dropping the subnet, or the macOS local-network permission for the client. A normal-looking table with a dead share sheet is therefore the signature of the section after this one, not of the route shape.

A Managed Mac May Not Offer the Local-Access Switch

Many clients expose a preference to allow local network access while the tunnel is up, but that preference is enforced by the client and by the management profile, so it can be locked, hidden or overridden on a managed Mac. A host firewall rule or a security agent can block the peer-to-peer traffic regardless of what the VPN client offers. Look for the switch before you conclude it does nothing. That switch lives in the client's own preferences rather than in macOS network settings, which is why a client whose pane does not show it is usually being governed by a management profile.

Removing management or disabling every filter so one recipient appears trades a controlled configuration for an unknown one. Turn on a local-access option only when it matches the policy you work under, and leave it off on a guest network where local discovery was never wanted.

Prove It With a File, Not an Icon

After changing routing or policy, send an actual file to the intended recipient and confirm that the transfer completes. A name appearing in the sheet is discovery, and discovery returning is not the same thing as a transfer finishing.

If the device still does not appear, compare a second pair of devices on the same network to separate a host problem from a network-wide one. That comparison is faster than toggling VPN options one at a time, and it produces a fact for the ticket. Write down the default interface, the route shape and the state of the local-access switch while the failure is reproducible. The next person will otherwise repeat all four checks from the top.