Why Your Mac VPN Drops When You Plug In an iPhone by USB

You plug in an iPhone to charge it, and a minute later the VPN on your Mac stops passing traffic. System Settings shows a new service called iPhone USB, and the obvious move is to delete it. That move is often wrong. The service can be the phone's Personal Hotspot, or it can be a link that Xcode and device tooling use to talk to the phone, and the two behave differently enough that identification has to come before deletion.

Step 1: Read the service the phone actually created

Open System Settings, then Network, and compare the service list with the phone detached and attached. On current macOS the service is listed as iPhone USB. Note whether it is active, where it sits in the service order, and whether the Mac is using it for the default route. Service order matters because macOS picks the highest active service that can reach a destination, not the one whose name you recognise.

Apple's Personal Hotspot guidance describes the mechanism: while Personal Hotspot is enabled on the phone, connecting it by USB can make the Mac use the phone's cellular connection, even when you only meant to charge. That is not a VPN client bug; the routing table is following a service that came up ahead of Wi-Fi.

If the service exists but stays inactive with the phone attached, you are most likely looking at a charge-only connection or a device link rather than a hotspot. Keep that distinction, because the next two steps test it instead of guessing from the icon.

Step 2: Check which route the VPN endpoint uses

Read the route to the VPN server's resolved address, not to a website. route -n get is read-only and prints the interface and gateway the kernel would use, and both lines matter.

scutil --dns | head -20
route -n get 203.0.113.10

The address above is a documentation placeholder. Substitute the endpoint your client shows, and use route -n get -inet6 for an IPv6 endpoint. Compare the output with the phone detached and attached, and do not add or remove routes between the two readings. If the interface changes from en0 to the iPhone USB interface, the hotspot path won the lookup and the VPN's outer connection is now riding cellular.

A route change does not explain every failure. The client can still reach the server and fail later on the tunnel's inner traffic, because the new path has a different MTU or the carrier blocks the protocol. Read the client's own error before changing anything: an outer handshake timeout points at reachability, while an established tunnel that stops passing traffic points at MTU, DNS or policy.

Step 3: Separate a hotspot from a device-communication link

Xcode 15 and later talk to a USB-attached device over a network-based channel that includes link-local IPv6, so a development Mac can show an extra interface that has nothing to do with internet access. Apple's TN3158 technote documents that behaviour and warns that VPN or security filtering can interfere with it. That is the reverse of the hotspot problem: the VPN does not break because the phone offers internet, the device connection breaks because the VPN captures it.

Two observations separate the cases without a packet capture. First, check whether the interface has a routable address and a default route, or only a link-local fe80:: address; link-local only means there is no internet path. Second, quit the VPN and see whether Xcode can reach the device again. If it can, the VPN's routes or content filter are catching the link-local traffic, and the fix belongs in the split-tunnel or filter configuration, not in the Network pane.

ifconfig | grep -A4 -E '^en[0-9]+:'
netstat -rn -f inet6 | head

Do not judge by interface name alone. macOS creates and destroys these interfaces as devices attach, and the en number is allocated at runtime, so the same Mac can show a different number after a reboot or a cable swap.

Step 4: Reproduce the failure with one variable at a time

Once you know which service is involved, reproduce the problem in a fixed order. Start with the phone detached and the VPN connected. Attach the phone with Personal Hotspot off, wait for the Network list to settle, and run the route query again. Detach, enable Personal Hotspot, attach again, and repeat. Write down the interface, gateway and client error for each of the three states, and you have a comparison instead of a memory.

If the VPN fails only in the hotspot state, keep the phone off that path: turn Personal Hotspot off while charging, or move the iPhone USB service below Wi-Fi in the service order. If it fails in every attached state, including with the hotspot off, look at how the client handles a network transition. Some clients tear down the tunnel when the primary service changes and need a reconnect; that is client behaviour, not a phone fault.

Change one thing per attempt. Deleting the service, resetting the VPN configuration and reinstalling the client in the same minute leaves you with a working Mac and no idea which action fixed it.

Step 5: Decide what to keep and what to verify

Leave the device link alone. Removing an interface that Xcode uses does not fix a VPN route, and it breaks device deployment until the next attach. If the hotspot service is genuinely unwanted, turn Personal Hotspot off on the phone first; that is the documented control and it survives a reboot.

If you do remove a service, remove the one you identified and then verify two things: the route to the VPN endpoint is back on the expected interface, and the tunnel passes traffic to an internal address rather than only to the internet. Keep a note of the service order and the client version, because a macOS update can change how the phone appears.

Then classify the failure you actually saw. A handshake timeout, an MTU stall after the tunnel is up and DNS answers coming from the carrier are three different problems with three different fixes. The USB service is the trigger in all three; it is rarely the cause.