Full tunnel or split tunnel? Start with what the traffic needs to do

Full tunnel directs ordinary internet traffic through a tunnel’s exit. Split tunnel directs selected traffic through it while other connections take another path. Choose by the destinations and source identity you need, the local resources that must remain reachable, and the behavior your supported client can enforce.

A laptop might need an approved source address for a partner service, access to a nearby printer and an ordinary connection to everything else. A server might need its internet traffic to use an agreed exit while preserving local dependencies. List those connections before selecting a routing policy.

Define routing scope and split-tunnel selectors

A split-tunnel selection can be based on destination routes or, in a platform that supports it, applications. The supported selector determines which traffic can be separated; an application selector cannot be assumed from destination-route support.

These are broad descriptions. They do not specify how local networks, DNS, tunnel transport or operating-system exceptions behave. Even a design using an internet default route may retain more specific local routes. WireGuard’s routing documentation shows why the routes carrying tunnel traffic and the tunnel’s own transport need deliberate treatment.

A split policy also needs an answer to “selected how?” An IP prefix, a hostname and an application are different kinds of selector. Support for one does not imply support for the others.

Match the routing policy to required connections

Choose a few real examples from the device’s work. For each, record the destination, who starts the connection and the result that matters.

A partner API may require a recognized source IP. An internal service may require a private route. A local device may need to remain reachable without taking an internet exit. A software update may simply need a working path under the organization’s policy.

Now ask which connections must share the same routing treatment. If the requirement concerns only one provider, a destination-based design might eventually be appropriate. If the requirement covers the device’s internet traffic broadly, a full-tunnel design may be easier to state. Neither conclusion establishes that a particular product or client implements it.

Hostnames deserve attention. A service can use several addresses or additional endpoints. Routing a single IP observed during a test may not cover the application’s later connections. Record who will maintain the destination set if the chosen system depends on one.

Fibmesh Outbound currently uses full-tunnel intent

The current Fibmesh Outbound policy sets full-tunnel intent for all enabled profile modes, including IPv4 and IPv6 default routes. Choosing a mode does not create a released destination-specific or per-application rule. Destination-specific routing remains planned.

There is one active egress profile per organization. Enabling another disables the previous profile, so switching profiles requires understanding the affected endpoints and workloads. It is an organizational policy change, not an isolated preference for one browser tab.

A created profile is also not evidence of a provisioned exit. Delivery, assigned identity where applicable, client support and observed traffic still need verification.

Public IPs has a different starting point: an assigned address for supported infrastructure. Its supported arrangements can also serve outgoing identity. If your requirement needs a routing arrangement that differs from current Outbound behavior, have that requirement assessed rather than treating the product names as interchangeable switches.

Check IPv4, IPv6 and DNS independently

An IPv4 test does not describe an IPv6 connection. Include both families when the workload and deployment use them. If one family is unavailable, define the supported behavior explicitly; do not leave an unintended alternate path to chance.

Check Domain Name System (DNS) resolution separately. Which resolver receives the query, and can it answer the names the application uses? Resolving a name and connecting to its result are different operations. One successful lookup does not prove that the resulting application traffic uses the expected route.

Platform controls matter here. Android’s VPN documentation describes route configuration, application selection and always-on behavior as separate mechanisms. Their existence in the operating system does not establish that Fibmesh exposes or supports them in a released client.

Test disconnection, restart and route restoration

If the selected exit becomes unavailable, should the workload stop or use another permitted connection? That answer affects business behavior and source-IP restrictions. Agree it before a disruption.

Current full-tunnel intent is not a promise of an advanced kill switch, automatic failover or identical all-packet behavior on every native platform. Test the supported client’s behavior when disconnected, after a restart and after a change of underlying connection.

Record ordinary restoration too. A device that can use the tunnel but cannot recover its intended route after an approved disable has not passed the whole operating test.

A useful routing decision can be written without relying on either label: these connections use this exit, these local resources remain reachable, these address families are supported, and this is what happens when the path fails. Once that statement is clear, “full” or “split” becomes a convenient description rather than an assumption.