Per-App Routing vs Split Tunneling: Key Differences

Per-app routing vs split tunneling compares a selector with a broader policy outcome. Per-app routing chooses a path from application identity, while split tunneling means some eligible traffic uses the VPN and other traffic uses another path; application identity is one way, but not the only way, to create that split.［1］［2］［3］

The complete VPN guide explains routes and tunnel scope. This article focuses on policy vocabulary, precedence, managed deployment, and the evidence needed to prove that a split matches its design.

Key Takeaways

• Per-app routing selects by application identity; split tunneling describes the resulting multi-path policy.
• Split rules can also select destination prefixes, domains, traffic filters, or combinations of attributes.
• Allow lists and exclusion lists have different defaults and failure consequences.
• A route, app rule, DNS decision, and existing connection can each influence the observed path.
• Managed per-app VPN is valuable for organizational boundaries, but it requires stable app identity and policy ownership.

How per-app routing vs split tunneling fit together

Split tunneling is the general case in which protected and ordinary paths coexist. One policy may send private corporate prefixes into a tunnel and use the local internet for everything else. Another may tunnel one application regardless of destination. A third may combine app identity and destination filters.

Per-app routing is therefore a selection dimension. Android allows a VPN builder to establish either an allowed set whose traffic uses the VPN or a disallowed set whose traffic bypasses it; the two lists cannot be used together in the same builder.［1］ Apple deployment supports associating managed applications with a per-app VPN configuration.［2］

Policy question	Per-app routing	Broader split tunneling
Primary selector	Application identity	App, prefix, destination, domain, filter, or policy combination
Typical unit	Package, bundle, or managed app	Network flow matched by policy
Default behavior	Depends on allow-list or exclusion-list model	Depends on default route and rule precedence
Identity dependency	High	Optional
Destination awareness	May be combined with filters	Common for route- or domain-based splits
Management use	Separate organizational and personal apps	Optimize access, reachability, cost, or policy scope
Main failure risk	Wrong or changed app identity	Rule overlap, route/DNS mismatch, or unintended fallback

How do allow lists and exclusion lists differ?

An allow-list model says only named applications enter the VPN. Its default for new or unidentified applications is direct access. This limits scope, but it can fail open relative to a requirement that every work application be protected if a package name changes or enrollment is incomplete.

An exclusion-list model says all applications enter except named exceptions. Its default is broader coverage, but a mistake can send latency-sensitive, local, or policy-exempt traffic into the tunnel. Android's builder documentation makes the allowed/disallowed distinction explicit and requires the app list to be established before the interface is created.［1］

Neither model is inherently safer. Choose the default that matches the consequence of an unknown application. Record package or bundle identifiers from the management source instead of relying on display names, and define what happens when an app is reinstalled, cloned, updated, or replaced.

What does managed per-app VPN add?

Managed deployment binds policy to applications and device-management state rather than asking a user to toggle routes manually. Apple describes per-app VPN associations delivered through device management so managed app traffic can trigger or use a designated VPN configuration.［2］

This creates clearer organizational separation when personal and work applications share a device. It does not automatically classify every background service, extension, embedded browser, or system account as belonging to the parent app. The platform and management documentation define those details.

Policy ownership is essential. The application team, device-management team, and VPN operator must agree on stable identities, deployment ordering, credential lifecycle, and removal behavior. Otherwise, a correct tunnel can still carry the wrong set of applications.

How can split tunneling select destinations instead?

Route-based splitting chooses by destination IP prefix. A profile can install routes only for private networks, or install a default VPN route with explicit direct exceptions. Microsoft VPNv2 policy exposes route lists and traffic filters, illustrating that selection can be defined independently of the application identity alone.［3］

Domain-based policy maps names to actions. It is more readable for changing services, but it introduces resolver timing, aliases, content-delivery addresses, shared hosting, and cached connections. A domain rule may influence DNS or route installation without controlling every later connection made by an application.

Traffic filters can combine application and network attributes. That precision improves least-privilege designs but increases precedence and observability requirements. A human-readable rule such as “work app to private API” must be translated into exact app identity, address family, destination, protocol, and failure behavior.

Why can two split-tunnel rules conflict?

Different policy engines can act at different stages. Device management may select a per-app VPN, the VPN profile may install routes, a local firewall may apply filters, and the application may reuse a connection opened before the rule changed. DNS can return an address outside the expected prefix.

Precedence is platform-specific. A more-specific route normally beats a default route, but a per-app policy can select a different interface context before destination routing. A proxy or browser extension adds another application-level path. This is why TUN and system proxy settings must not be described as equivalent split-tunnel controls.

Write a policy table before testing. For every important flow, list application identity, destination class, address family, expected interface, DNS owner, local-network rule, and failure action. If two rules claim the same flow, document which system owns precedence instead of accepting whichever result appears first.

How do you choose the correct selector?

Choose application identity when the security boundary follows managed software: for example, an organizational app should use a private gateway regardless of where its API is hosted. Verify that the platform can identify every relevant helper, extension, or embedded component.

Choose destination prefixes when the boundary follows networks with stable addresses. This is often easier to observe through route tables, but cloud services and shared infrastructure may not fit neat prefixes. Avoid adding broad third-party ranges merely to make an application work.

Choose domains only when the platform defines how names become enforceable network policy. Account for aliases, DNS caching, encrypted DNS, IPv4 and IPv6, and connections to literal IP addresses. A domain label in a UI is not enough evidence by itself.

Combine selectors only when each extra condition solves a documented ambiguity. More rules increase the chance of overlap, stale identity, and partial address-family coverage. The most maintainable policy is the smallest one that expresses the required boundary and has an owner.

How should you validate a split policy?

Build positive and negative tests. A positive test confirms that protected traffic reaches an authorized private or controlled endpoint through the expected tunnel. A negative test confirms that an excluded app or destination uses the permitted direct path—or is blocked if direct access is forbidden.

Test transitions as well as steady state: before enrollment, after profile installation, after app update, after network change, after tunnel restart, and after policy removal. Close existing connections or mark them separately so connection reuse does not masquerade as new routing behavior.

For each test, record the application identity used by policy, destination address, DNS answer, address family, selected interface, egress observation, and server log. Split tunneling that appears broken should be diagnosed against this declared matrix, not against a single public-IP page.

Include failure cases. Stop the tunnel, make the private destination unavailable, and remove authorization in a controlled environment. Determine whether the app blocks, retries, prompts, or falls back directly. That behavior is part of the split-tunnel contract.

Can AethoVPN routing controls be inferred from this comparison?

If you evaluate AethoVPN for this, start from the control it does describe, global mode: with it on, every app's traffic goes through the VPN, and with it off, traffic to websites in your own region skips AethoVPN, a region-based split rather than a per-app selector. Test one local-region site and one foreign site in each state before relying on it. Per-app lists, domain selectors and managed deployment are not part of what AethoVPN documents, so a policy that depends on them belongs with a tool that states them. Start the 3-day trial to compare both states.

Summary

• Per-app routing is one selector; split tunneling is the broader result of routing eligible flows over different paths.
• Allowed and disallowed application sets create opposite defaults for unknown apps.
• Prefix, domain, and traffic-filter policies can create splits without application selection.
• Overlap across management, routing, DNS, proxy, and connection state must be resolved explicitly.
• Validate both intended VPN flows and intended direct or blocked flows across lifecycle transitions.

FAQ

Is per-app routing always split tunneling?

It normally creates a split when selected apps use a VPN and others use another path. However, “split tunneling” remains the broader term and can describe destination-based or domain-based selection without app identity.

Can split tunneling work without a per-app list?

Yes. A VPN can route selected IP prefixes, destinations, domains, or traffic filters while applying the same policy to every application.

Is an allow list safer than an exclusion list?

It depends on the required default. An allow list limits VPN use to known apps but may let a newly unidentified work app connect directly. An exclusion list covers new apps by default but may tunnel software intended to stay outside.

What happens when an app identifier changes?

The old policy may no longer match. Managed deployment should use the stable identity defined by the platform, detect replacement or re-signing where relevant, and specify whether an unmatched app is direct or blocked.

Can a domain rule replace an IP route?

Not universally. Domain policy depends on platform DNS integration and must handle aliases, cached answers, changing addresses, IPv6, and literal-IP connections. Verify how the platform enforces the rule.

Why does an excluded app still show the VPN address?

It may use a helper covered by the VPN, reuse an older connection, query a different address family, or pass through an application proxy. Record identity, destination, route, and connection timing before changing the policy.

Should split traffic fail open or fail closed?

That is a policy decision per flow. Private organizational traffic often needs fail closed, while an explicitly excluded personal app may remain direct. State and test the expected action instead of relying on a product default.

Disclaimer: This article provides general networking and device-management information. Follow organizational policy and the rules of systems you administer.

Sources:

1. Android Developers, “VpnService.Builder”: https://developer.android.com/reference/android/net/VpnService.Builder
2. Apple Platform Deployment, “Per-app VPN overview”: https://support.apple.com/en-asia/guide/deployment/depae3d361d0/web
3. Microsoft Learn, “VPNv2 CSP”: https://learn.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp

Sources checked 12 September 2026.

---

Related Articles:

• Place split policy in the wider VPN model
• Troubleshoot a split-tunnel mismatch
• Separate packet capture from proxy cooperation
• Understand application-specific exit locations