Does Internet Sharing Put Your Other Devices on the VPN?

Turning on Internet Sharing does not extend the VPN to everything on your desk. The two features answer different questions. Sharing decides which connection feeds the Mac and which interfaces hand that connection out, while a VPN decides where the Mac's own traffic goes. Whether the second device inherits the tunnel depends on routing, on the client's policy, and on what the gateway is willing to forward, which is three things the Sharing panel knows nothing about.

The myth: sharing the connection shares the tunnel

When someone says it works, what they usually observed is that the tablet behind the Mac loaded a page. That observation is consistent with several different paths, including one where the page went straight out of the physical uplink while the Mac's browser used the tunnel. One successful page load distinguishes nothing. It proves only that some path exists.

A second device does not inherit a session. It gets an address from the Mac, sends packets to the Mac, and the Mac decides what to do with them according to its own routing table and its own firewall state. That decision happens per connection rather than per device. Two devices behind the same Mac can take different paths when the rules differ.

What the Sharing panel actually chooses

In System Settings, the Internet Sharing controls ask for a source connection and for the interfaces that other devices will use. The source is the Mac's uplink, and Apple's own guide warns that careless sharing can disrupt the network you are attached to.

Nothing in that dialog names a VPN as the gateway for forwarded traffic. Picking Ethernet as the source does not mean the tunnel is ignored, and it does not mean the tunnel is used either; it means the Mac's physical interface is the declared uplink, and the routing table still decides.

The available options also depend on the hardware. A Mac with no Ethernet port, or one where a dock is not connected, will not offer the choice a tutorial assumes. Check the panel you actually have before designing anything around it.

How a forwarded packet finds its way

Downstream devices are hidden behind NAT, and the Mac rewrites their addresses before sending anything upstream. If the tunnel owns the default route at that moment, the rewritten packets may well go through it, which is why the arrangement appears to work in a quick test.

Appearance is not policy. A desktop VPN client is built around the Mac's own traffic, and its kill switch usually enforces rules for local applications rather than for a LAN behind the machine. When the tunnel drops, the Mac may keep forwarding for its guests with no blocking rule at all.

There is also the version question. A provider that documented sharing support on an older macOS release may have changed behaviour since, and a tutorial that shows a native VPN entry in the source list may describe an interface your current client never creates.

So test the path rather than trusting the design. Run a request from the second device and watch it at both ends, because that is the only evidence that survives a client update. A test you can repeat after the next update is worth more than a configuration you merely believe in.

Choose the coverage boundary deliberately

If the second device can run the approved client, that is the stronger arrangement. It gets its own profile, its own identity and its own policy, and the Mac merely supplies the underlying network.

If it cannot run a client, then you need either a documented sharing feature from the VPN provider or an approved gateway that forwards on the device's behalf. Both come with an owner and a defined end, which is more than a checkbox can offer.

Employers often require the per-device model anyway, because one machine's session representing four others is a different trust decision from four enrolled devices.

What to verify before you promise it

Check the second device's actual destination, not the Mac's. A private service and a public exit are different tests, and passing one says nothing about the other.

Check both address families and name resolution. A setup that tunnels IPv4 while leaving IPv6 on the physical link produces a device that looks protected in a browser and leaks in everything else.

Then check the disconnected state. Turn the tunnel off and repeat the test from the second device; if it still reaches the internet, the arrangement was sharing a connection and never sharing a VPN, which is a fine outcome as long as nobody wrote it down as the other thing.