Home-Lab Split Tunnel: Route What You Need, Not Everything

The advice that a home lab needs a full tunnel usually comes from a tutorial that had one, not from a requirement. Split tunneling is not the compromised version of a proper VPN; it is the version whose route table you can explain. A lab with five services and a management interface does not need every packet leaving the house to traverse a tunnel. What it needs is an inventory and a route for each item on that inventory.

The myth: split tunneling is a compromise

The myth survives because full tunnel is easier to configure once and harder to debug later. That trade is reasonable for a laptop on public Wi-Fi and wrong for a rack in the basement.

It also hides a second assumption, which is that the lab's addressing has nothing in common with the network you are connecting from.

Inventory the resources before the routes

Write down each lab subnet, the service that lives there, the name you resolve it by, and who is allowed to reach it; the forwarding notes for your gateway describe the return path you are planning against. Add the container ranges and the LAN ranges the remote client may already use, because overlap is the failure this inventory prevents. A route that covers every private address will collide with a home network sooner or later. The inventory is also the test plan, which is why it is worth doing before configuration rather than after.

Assign each resource to a path: through the tunnel, direct, or denied. A resource with no assigned path is the one that generates the confused support question later.

Five rows and a column of decisions beats a route table nobody can read.

The gateway needs a return path

Forwarding on the gateway is only half of it. The lab needs a route back to the client pool, or a supported translation arrangement that makes the return possible. If replies cannot find the client, the tunnel looks connected and every request times out, which is a routing symptom rather than a VPN failure. Check the return path as part of the design, not as a troubleshooting step.

A client pool that overlaps the lab's own addressing is the other half of this problem, and it fails in exactly the same way.

Fix the plan rather than the symptoms when the two ranges collide.

Management and internet roles are separate

Decide whether only lab traffic uses the tunnel or whether it also becomes an internet exit. Do not add a default route solely because a tutorial used one, because that decision changes where every DNS query and update check goes. Preserve an outside path to the VPN endpoint itself, or the tunnel will try to carry its own outer connection. Keep management access narrow and reachable through an approved recovery method.

Private DNS can be selected for lab names without assuming every public query needs the same resolver. That is a resolver decision, not a route decision.

Keeping them separate is what makes the failure modes distinguishable later.

Test from outside, not from the LAN

Use an external authorized connection rather than a test from the same LAN, because a same-LAN test can hide a missing return route completely. Verify a lab address, its private hostname, an intended direct destination and the required failure behaviour. The failure case matters as much as the success case: a resource that should be unreachable must actually be unreachable. Record all four results before you call the design finished.

Then save the route and DNS configuration next to the inventory, with an owner named. When the lab gains another subnet, update both and retest.

An unexplained route that overlaps an existing home network is the default outcome of skipping that step.

The finished design is small, documented and boring, which is exactly what a lab wants from its network. The interesting version is the one that breaks while you are away from home.