Per-app VPN or split tunnel? What a Mac route can decide

Two applications open connections to the same office server, and only one of them should use the tunnel. A route cannot express that wish, because routing tables are keyed on destinations and carry no notion of which process opened the socket. What people ask for and what they need are often different things. Separate the two before changing any configuration.

The selector is a destination, never a process

Every routing decision starts with a destination address and ends with an interface. The kernel never asks which binary sent the packet, and on macOS pf does not route by process either, so a firewall rule cannot put one application on a different path. That is why the same server reached by a browser and by a reporting tool takes one path for both. Application-level separation therefore has to come from something other than a route: a VPN plugin that owns the socket, a proxy that takes the connection on the application's behalf, or a separate network stack. None of those is a routing change.

Two applications talking to one address is the cleanest test of a proposed design. If the answer cannot differ between them, the design is destination-based whatever it is called.

What ordinary split tunnelling actually buys

A split tunnel installs routes for the private prefixes and leaves everything else on the physical path. That is usually what the request means: reach the office server through the tunnel, keep public browsing direct. It is simple, every mainstream client supports it, and it is enforced by the same mechanism as any other route. Check the specific destination with route -n get rather than reading the default route, since a split tunnel often leaves the default alone.

Hand-editing the default route is not a conversion to anything. It fights the client's own route restoration and, in clients that install a protection policy, can leave the machine in a state neither you nor the client expects. Configure the split tunnel in the client's supported settings instead.

What per-app VPN on macOS requires

Real per-app VPN on macOS is a Network Extension feature driven by a configuration profile. A management payload maps chosen applications to a VPN configuration, and the system then routes those applications' traffic accordingly. It is a managed deployment, which means an MDM, a signed profile, and an administrator who owns both.

Installing the client by hand does not create that mapping, and the ordinary settings pane does not make applications individually selectable. A vendor may expose its own application rules, and those follow its documentation rather than a general rule.

Three ways to get app-level separation without MDM

Where management is not available, a proxy is the practical answer. Set the application's own proxy configuration, or use a PAC file that selects by destination and protocol for that application alone.

A local proxy terminates the connection and re-originates it through the tunnel, so the application never needs a route. The second option is a separate network stack: a virtual machine or a container with its own default route, which the application reaches over a local address. The third is to accept destination-based routing and drop the requirement, which is honest when both applications may use the tunnel. All three are testable, and none of them pretends that a route knows about processes.

Write the request so the answer is unambiguous

Describe the workflow rather than the mechanism: which application needs which service, whether another application must be kept away from that same service, and what should happen while the tunnel is down. Those three answers choose the design. They also tell the administrator whether the request is a routing change or a deployment project.

Include the excluded-application case explicitly. A client that stops an application when its protected path is unavailable behaves differently from one that lets it fall back to the physical interface, and users notice that difference immediately. Name the expectation in the ticket. Then verify on the actual machine, because the same product often behaves differently on macOS than on Windows, and its macOS documentation is the only reliable source for what its settings do.