The watch does not have a VPN setting you can open, and that is the first thing to understand. All VPN configuration lives on the paired iPhone, in a profile or inside an app's Network Extension. Whether watch traffic actually crosses that tunnel depends on which link the watch is using at that moment. That single fact explains most of the confusing reports about a watch that keeps working while the phone sits on a VPN, or the reverse.

watchOS has no VPN client to point at

watchOS ships without a VPN configuration screen, so there is no per-watch tunnel to enable or debug. A profile installed on the iPhone applies to the iPhone, and the watch inherits behavior only through the paths the two devices share. Treat any claim about a watch VPN setting as a sign the person is describing the phone's screen.

This is also why MDM teams cannot push a VPN payload to a watch the way they push one to a phone.

What the watch does have is a set of transports, and it picks among them constantly: Bluetooth to the nearby phone, a compatible Wi-Fi network it holds credentials for, or cellular on a model with a plan. Each choice changes who carries the packets, which is the part that matters for your tunnel.

Bluetooth: the phone carries the packets

When the phone is nearby, the watch prefers Bluetooth because it costs far less power than Wi-Fi or cellular. Data from a watch app leaves over that link, arrives at the phone, and then follows the phone's routing and tunnel rules like any other traffic the phone originates or relays. In that state the phone's VPN is genuinely in the path. This is why a watch app can fail with the tunnel up even though the watch never opened a connection of its own.

That relay is not the same as the watch joining the tunnel. The tunnel belongs to the phone's network stack, and the watch has no view of it: no address assignment, no routes of its own, no tunnel status to read. You will not find the watch's traffic as a separate session inside the tunnel.

A useful test is to disable Bluetooth on the phone only and repeat the failing action. If it starts working, the path was the phone relay.

Wi-Fi and cellular: the watch leaves the tunnel

If Bluetooth drops out of range or is disabled, the watch tries a compatible Wi-Fi network it already knows, and a cellular model with service can fall back to the carrier. Apple's watch connectivity guide describes that order and notes that the Wi-Fi icon means the watch is on Wi-Fi rather than talking to the iPhone. Traffic on those paths terminates at the watch, not at the phone.

So the phone's tunnel does not extend to it. The watch's own connections are made by watchOS, using the watch's radios and the credentials it holds, and the phone is not forwarding them. This is the case where a strict all-traffic VPN on the phone can be working perfectly while a watch app still reaches the internet.

The reverse complaint is more common: a watch app fails once the phone's tunnel comes up.

What includeAllNetworks does and does not cover

Apple's routing documentation for Network Extension lists companion-device communication, including traffic to an Apple Watch, among the exceptions it carves out when describing includeAllNetworks. The intent is that a broad tunnel does not break the local link between the two devices. Read that narrowly: it protects the companion channel, not every service a watch app might call.

It also does not certify any particular VPN product, and it says nothing about which transport the watch picked at the moment of failure. A notification arriving late is not evidence that the tunnel dropped it.

Nor does the exception turn a watch on its own Wi-Fi or cellular into a tunneled client. If you need that guarantee, the tunnel has to terminate somewhere the watch's traffic actually passes, and the phone is not on that path.

Read the path before you change the profile

Before touching the VPN configuration, capture three things: the connection the watch reports (phone, Wi-Fi or cellular), whether the phone is within Bluetooth range, and one named action that fails. Then repeat that action with the path unchanged and the VPN off, if policy allows it. A result that only appears with the tunnel up is a tunnel problem, and a result that appears either way is not.

Keep both devices in the same place for both runs, or you will be measuring the room instead of the tunnel.

When the failure survives that comparison, the useful report to a network administrator is narrow: this app, this action, this transport, tunnel on and off. Blanket statements about watch and VPN incompatibility cannot be checked, and they usually hide a captive portal or a blocked service behind a claim about the radio.

Lahatsoratra mifandraika