Sidecar and a VPN: Wireless or USB, and What Blocks It

Sidecar turns an iPad into a second display over a direct link between two Apple devices. A VPN that changes routing or blocks local discovery can break that link, and no amount of re-pairing fixes a policy problem. The choice between wireless and cabled Sidecar is a real decision rather than a fallback, and each mode fails differently. Test the display itself before blaming either the tunnel or the tablet.

What Sidecar needs before any VPN

Before a tunnel is involved, Sidecar has its own requirements: compatible models and software, the same Apple Account with two-factor authentication on both devices, and for wireless use, the two devices need to sit close together with Wi-Fi, Bluetooth and Handoff switched on. Neither device may be acting as a hotspot for the other.

Those conditions are easy to check and easy to forget. A Mac tethering to its phone will fail Sidecar for reasons that have nothing to do with a VPN.

Wireless versus cable, honestly compared

Wireless is the convenient mode and the fragile one. It depends on peer-to-peer discovery and a direct link, so anything that filters local multicast or forces traffic through a remote exit can break it. USB avoids that path entirely by carrying the display session over the cable, at the cost of a cable and a trust prompt. Choose USB when the network is managed and you cannot change its policy; choose wireless when both devices sit on a network that permits local traffic.

Neither mode is more secure by definition. The cable removes a network path, while the policy on the devices still decides what may connect.

A cabled session also removes the distance constraint, which matters when the iPad sits on a stand across the room. It does not remove the account requirement or the trust prompt.

Where a VPN client can interfere

A VPN client interferes in two ways: it can change the routing table so local addresses go through the tunnel, and it can apply a local-network policy that blocks peer discovery. Apple's own Sidecar guidance notes that a VPN preventing local networking may interfere with Continuity features. Read your client's settings rather than assuming either outcome.

scutil --nc list

Then check what the client actually installed. A full tunnel that sends every prefix through the gateway carries local discovery traffic to a remote network where the iPad does not exist. Split tunnelling that excludes the local subnet usually restores it. On a managed device you may not be allowed to change that, which is a policy conversation rather than a configuration tweak.

Accept the display, not a proxy signal

Accept the display by using it. Move a window to the iPad, confirm the arrangement is extended rather than mirrored, and work in it long enough to see whether input and refresh hold. An iPad appearing in the Displays list is a beginning, not a result. AirDrop working proves that one service can reach the device and says nothing about the display session.

Record the two device versions, the mode, the VPN profile and the operation you performed. If only the VPN-active case fails, you have a specific local-policy interaction to take to the owner. That record is worth more than a recipe that disabled protection to make a menu item appear, and the Sidecar requirements are the place to confirm the baseline.