Why a Full-Tunnel VPN Hides Your Routed Local VLANs

The "allow local network" switch in a VPN client sounds like it covers everything in the building. In practice it usually adds a few private-address exceptions to the tunnel's default route and stops there. Your storage VLAN is still reachable only if a route for that specific prefix survives the tunnel's arrival, and on many clients it does not.

That is a routing question rather than a VPN setting, which is good news: it has a concrete answer.

What allow-local-network actually covers

Clients implement that option differently. Some add routes for the subnet the machine is attached to, some add the RFC 1918 ranges, and a few only exclude the default gateway. None of them know that your office router also serves a storage VLAN, a lab segment, or a printer subnet, because those prefixes are not on the wire the client can see. Read the client's own documentation for the exact behaviour instead of assuming the label describes your topology.

The distinction matters most in a full-tunnel design, where the client deliberately replaces the default route so that all traffic goes through the VPN. That is the design's whole point, and it is also what makes the local routed networks disappear. They were never covered by a route of their own; they were riding on the default route that has just been replaced. A client cannot route what it does not know exists, and it only learns about prefixes attached to its own interface. Everything else has to be described by someone who knows the topology.

Connected routes stop at the first router

A workstation at 192.168.10.20/24 with gateway 192.168.10.1 gets a connected route for 192.168.10.0/24 automatically. The storage VLAN at 192.168.20.0/24 is a different prefix, reachable only through that gateway, and the workstation has no route for it beyond the default. Before the tunnel comes up, the ordinary default happens to send storage traffic to 192.168.10.1 and everything works.

When the VPN installs a full-tunnel default, packets for 192.168.20.1 follow the new default into the tunnel. The remote gateway has no idea where that prefix lives, so it drops them or forwards them somewhere useless. Nothing was misconfigured on the storage VLAN; its path was borrowed, and the loan was called in.

The temptation is to reach for a broad exception such as a /1 route pair or a second default. Resist it. The narrower the exception, the easier it is to explain, audit, and remove when the network changes.

Put the exception in the table that wins

Within one routing table, a /24 beats a /0 or a /1 by longest-prefix match, so a specific route to the storage VLAN through the local gateway is enough, provided the table is consulted at all. On Linux the ordinary form is short:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Policy routing complicates that guarantee. An earlier rule can send traffic to a table whose own default route points into the tunnel, and the main table holding your /24 is then never reached. Check the rules before assuming the route is authoritative, because a correct-looking entry in the wrong table explains a failure that looks like a broken route.

Then make the entry persistent through the client's supported mechanism or the network manager that owns the interface. A route typed at the prompt disappears at the next reconnect, and a route tied to one Wi-Fi gateway is not portable to the next network the laptop visits.

Names and policy do not follow routes

Fixing the route restores packets, not names. If local devices are resolved through a pushed resolver that knows nothing about them, the mount still fails even though the address is reachable. Local names need a local or split-DNS arrangement, and that is a separate decision from the route exception.

Policy is separate again. A VPN client's local-access filter can deliberately forbid traffic to private ranges, and a route does not override that rule. On an untrusted network, a private address is also not proof that the destination is your storage server, so the exception should be as specific as the route itself.

A contract you can hand over

The finished design should read as a short list: general internet traffic follows the tunnel, and these named local prefixes keep their path through the local router. Write down the prefixes, the next hop, and the DNS suffix that goes with them, and keep the list short enough that someone can verify it without reading a routing table.

Watch for overlap between local and remote ranges. A storage VLAN that shares a prefix with something behind the VPN will resolve to whichever route is more specific, and the resulting behaviour is confusing in a way that looks intermittent. Renumbering one side is usually cheaper than debugging the ambiguity forever.

Test the contract twice: once with the tunnel up and once with it down. If the local path only works in one of those states, the exception is not a contract yet.