Two Mac Login Accounts Do Not Split VPN Traffic

Two login accounts on the same Mac look like two separate worlds until the network arrives. A tunnel started in one session can still change what the other session experiences, depending on which client owns it and what policy comes with it. Describe the separation you need before choosing a mechanism to enforce it. The order matters, because a mechanism picked first tends to redefine the requirement around itself.

Three questions do most of the work: whose applications need which private resources, whether both sessions must be active at once, and what those applications are allowed to do when their tunnel is unavailable.

Start from the traffic, not the account list

Account switching is an identity boundary, not a routing boundary. macOS loads a VPN configuration for the account that owns it, but the interface, its routes and any system-wide policy it installs belong to the machine. If the requirement is that only one person's applications enter the corporate network, the design has to say so in terms of applications and destinations, not in terms of who is logged in. Otherwise the second account inherits whatever the first one's client left behind.

Write the required behaviour in a sentence: one user's mail and file access follow the managed tunnel, the other user's browsing stays on the home connection, and neither path inherits the other's default route. That sentence is testable; a login-switching story usually is not.

Profile channel and traffic scope are different things

Apple supports managed VPN arrangements delivered per user or per device, and a deployment guide describes those models along with provider-dependent integration. The delivery channel says who receives and owns the configuration. It does not by itself define which traffic is captured, because the client implementation and the configured policy still decide that.

Where a documented user-aware or application-aware mode can express the requirement, that is the shortest path. Then verify the actual applications and identities rather than trusting names: two copies of the same app are not two different network paths, and a profile that lists an app does not guarantee that its helper processes are covered.

A guest system is a real boundary with real limits

A virtual machine gives you a separate operating system with its own network stack, so a guest can run its own tunnel and its own applications without touching the host's routes. That is a stronger separation than a second login account, and it is also more work to maintain. Decide whether that cost buys a boundary you actually need before proposing it.

The virtual network mode still needs review. Whether the guest is bridged, NATed or isolated determines what it can reach and what can reach it, and host applications do not become guest applications because the guest happens to be connected. Check the blocking policy too, or a dropped guest tunnel will fall back to the host's path in a way nobody intended.

A proxy is narrower than a user account

One host application can reach a real proxy service that runs in an approved guest or container, and that covers the traffic the application actually sends through the supported protocol. It does not cover every process owned by that Mac account, and it does not cover traffic the application sends outside the proxy protocol.

Another caution on shared machines: a TCP listener bound to host loopback is not a username check. Restricting a proxy to the local machine keeps it off the network, but it does not authorize one local user over another who is already logged in. Keep the service's authentication explicit if that distinction matters.

Prove the boundary with two tests

Run both paths and observe them separately. Under the intended account, open the application that needs the private resource and confirm it reaches the managed service; under the other account, confirm ordinary browsing keeps the home path. Then break the tunnel deliberately and check the fallback behaviour for each side, because that is where most designs quietly fail. Run the checks in the same hour too, so a changed network does not contaminate the comparison.

If a container or guest runs the tunnel, add a third check: confirm that a native Mac application outside it still behaves as designed. Choose the simplest arrangement whose scope you can demonstrate, and do not label virtual machines universally necessary or account switching universally sufficient before running those tests.