How to Fix Split-Tunnel Routes That Hide One Home NAS Subnet

Restore the missing NAS subnet by adding the most specific bidirectional route while leaving the working split-tunnel paths unchanged.

In a home VPN, one NAS network can disappear even though the tunnel connects and other private subnets remain reachable. The usual cause is not the NAS service itself but a missing route, a broader local route that wins, an overlapping home-network prefix, a wrong tunnel gateway, or a return path that does not know how to reach the VPN client. The safest fix is to compare a working subnet with the hidden subnet, correct one route decision at a time, and verify both forward and return traffic before widening the tunnel.

Prove That Only One NAS Subnet Is Missing

Connect the VPN and test three destinations separately: the VPN gateway, one known working private subnet, and the NAS subnet that fails. Use direct IP addresses first so DNS, SMB discovery, and hostnames do not blur the routing result.

Split tunneling sends only selected destination prefixes through the VPN, while other traffic follows the client’s ordinary default route. A practical explanation of subnet-specific split routes shows that a client can treat the VPN network itself as reachable while sending a neighboring private subnet to the wrong gateway.

If the VPN gateway and another remote subnet work, the tunnel and authentication are already established. Keep the diagnosis focused on the missing NAS prefix, route preference, firewall policy, and return path instead of rebuilding the entire VPN configuration.

Compare the Route Chosen for a Working and Failing Address

Inspect the client route table after the tunnel connects and query the selected route for one working remote address and one NAS address. Record the destination prefix, prefix length, metric, interface, and next hop used for each.

A route that exists is not automatically the route that wins. Operating systems normally prefer the longest matching prefix, so a local 192.168.1.0/24 route can override a broader VPN route such as 192.168.0.0/16 for the exact addresses that overlap.

If the NAS address follows the local Wi-Fi or Ethernet gateway, add or advertise a more specific VPN route for the NAS subnet. If it already follows the tunnel, continue to VPN policy, remote forwarding, and return routing rather than adding duplicate client routes.

Remove Overlap Between the Client Network and NAS Network

Compare the private subnet used by the remote client’s current location with the private subnet behind the home VPN. Hotels, offices, mobile hotspots, and other homes frequently reuse common ranges such as 192.168.0.0/24 or 192.168.1.0/24.

A current GlobalProtect discussion describes how a broad split route can conflict with the client’s local private network. The client may believe the NAS address is located on its nearby Wi-Fi and never place the packet into the VPN.

The cleanest long-term fix is to renumber the home NAS VLAN or the remote LAN to a less common prefix. When renumbering is not possible, use a translated VPN subnet, host-specific route, application proxy, or VPN design that deliberately resolves the overlap rather than relying on ambiguous private addresses.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Correct the Split-Tunnel Prefix and Gateway

Review the server-side list of included routes or allowed subnets and confirm that it contains the exact NAS network with the correct mask. A typographical error such as /25 instead of /24 can hide only half of the intended addresses.

A Cisco VPN case found split routes installed with the wrong route gateway even though the VPN address pool itself looked correct. This is why the operational client route matters more than the configured route label.

Remove stale or duplicate routes, reconnect the VPN, and verify that one authoritative route appears for the NAS prefix. Do not add a default route through the tunnel unless full tunneling is the intended design; fixing one subnet should not silently redirect all internet traffic.

Verify Forwarding, Firewall, and the Return Route

Capture or log traffic on the VPN gateway while the client pings the NAS address. If the packet enters the tunnel but never leaves toward the NAS VLAN, inspect IP forwarding, inter-interface firewall rules, and the route from the VPN gateway to that subnet.

A split-tunnel implementation guide emphasizes that route installation must be paired with matching forwarding and firewall policy. A client-side route alone cannot make the VPN gateway forward traffic into another VLAN.

Then confirm the NAS subnet’s router has a route back to the VPN client pool. If replies use the normal internet gateway instead, add the return route or apply carefully scoped source NAT on the VPN gateway. A successful one-way capture without replies is a return-path failure, not a reason to keep changing the client route.

Retest the NAS Service Without Breaking Other Paths

After IP reachability works, test the actual NAS service by IP and then by hostname. Confirm SMB, the web dashboard, or the required app port without assuming a successful ping proves the application path.

The ZimaSpace guide to a missing VPN-to-LAN path provides the adjacent lesson that tunnel connectivity does not guarantee every LAN traffic type follows the same path.

Finish by testing the repaired NAS subnet, one previously working remote subnet, and ordinary internet access. Keep the change only when all three behave as designed, the route survives reconnection, and the client does not need a manual command after every network change.