VPN Split Tunneling for Local Printers and NAS Access

Your VPN connects successfully, but the printer disappears and the NAS stops responding by name. That does not necessarily mean the tunnel has replaced every local route. Discovery, DNS, overlapping addresses, and a VPN application's kill switch can each produce similar symptoms.

This walkthrough builds a narrow local-access exception on a Linux client you administer. You will identify the right subnet, verify route selection, and test printer and NAS services without disabling your VPN's broader protection or opening access to an entire private address space.

Define the local exception precisely

Assume your home LAN is 192.168.50.0/24, your client is 192.168.50.10, your printer is 192.168.50.40, and your NAS is 192.168.50.60. Substitute actual addresses from your router's lease list. Prefer DHCP reservations so device addresses stay predictable.

Use the Subnet & CIDR Calculator below to confirm the LAN's network address, mask, and usable range. Check whether both devices belong to that subnet. A /24 covers a specific range; it does not mean all addresses beginning with 192.168 are local.

Choose the smallest useful exception. Two host routes may suit a laptop needing only a printer and NAS, while an explicit subnet exception may suit a trusted home lab. Neither choice should grant unsolicited inbound access to your laptop.

Do not apply home-network exceptions on a school or office network without permission. Follow its acceptable-use policy and local law. An unfamiliar Wi-Fi network using the same private subnet is not automatically trusted merely because its addresses match your home setup.

Identify whether routing is actually broken

Capture the current state with the VPN disconnected, then repeat with it connected. On Linux, the main table alone can be misleading because policy routing may consult other tables first.

ip -br address
ip route show table main
ip rule show
ip route show table all
ip route get 192.168.50.40
ip route get 192.168.50.60

For directly attached devices, route lookup should normally select the LAN interface, such as wlan0 or eth0, with an appropriate local source address. If that already happens, adding another route is unlikely to fix a firewall block or failed hostname lookup.

A connected /24 normally beats a VPN default route by longest-prefix matching within the selected table. However, policy rules can select a different table, and a kill switch can reject packets after routing has selected the correct interface.

Compare the results with your VPN application's “Allow LAN traffic” or similarly named setting. Use its supported control first when available. That setting may coordinate routing and firewall rules more safely than a manual route layered on top of an application-managed configuration.

Review WireGuard's quick start if you manage the tunnel yourself. Its AllowedIPs controls cryptographic routing and commonly influences route installation, but it is not a complete host firewall policy.

Add a reversible route only when needed

For a directly attached LAN, a host route uses the local interface rather than the internet gateway. The next example assumes wlan0 is the actual home interface and both devices are on its link. Run it only after verifying those facts and confirming the host routes do not already exist.

sudo ip route add 192.168.50.40/32 dev wlan0
sudo ip route add 192.168.50.60/32 dev wlan0
ip route get 192.168.50.40
ip route get 192.168.50.60
# Roll back the routes created above when the test is complete.
sudo ip route del 192.168.50.40/32 dev wlan0
sudo ip route del 192.168.50.60/32 dev wlan0

These temporary host routes disappear on reboot and do not themselves override every policy-routing rule. If route lookup still selects the tunnel, stop and examine which rule and table won. Do not insert broad high-priority rules without understanding the VPN manager's design.

For a NAS on another home VLAN, the route would instead need the actual reachable router for that VLAN. A gateway must be on a link your client can reach, and inter-VLAN firewall policy must allow the intended service.

If local and remote networks both use 192.168.50.0/24, address overlap is the underlying problem. Host exceptions select which side receives those addresses; they cannot make two different NAS devices at the same address simultaneously distinguishable. Renumbering one network is usually cleaner.

For OpenVPN-specific setup and service checks, see the Raspberry Pi client guide. Retain your administrator's intended remote routes rather than deleting everything pushed by the server.

Separate service access from discovery and DNS

Try each device by its known address before troubleshooting its friendly name. A NAS share can be reachable even when the file browser's network list is empty. Similarly, a printer configured by address can work while automatic discovery fails.

# Test only services actually enabled on your devices.
nc -vz -w 3 192.168.50.40 631
nc -vz -w 3 192.168.50.60 445
getent hosts nas.home.arpa

Port 631 commonly serves IPP printing, and 445 commonly serves SMB shares. A successful TCP connection proves reachability to that port, not successful authentication or permission to print or read files. Use the normal application to finish verification.

Multicast DNS and service discovery generally remain link-local unless deliberately relayed. Routed access to another VLAN does not automatically carry discovery traffic. Avoid enabling multicast reflection across every segment merely to make one device appear in a browser.

A private NAS name may depend on your home router's DNS resolver, while the VPN selects a different resolver. Configure an approved per-domain DNS route where your client supports it, or use a maintained local record. Do not replace all VPN DNS settings with home DNS without considering DNS privacy and remote-name resolution.

The RFC Editor provides the underlying protocol references when you need to distinguish private addressing, naming, and multicast behavior.

Preserve the kill switch and persist carefully

A route exception is not a firewall exception. If the VPN blocks non-tunnel egress, configure its documented LAN allowance rather than flushing firewall rules or disabling protection globally. Limit access to the required destinations and service ports where supported.

If you manage an Ubuntu firewall directly, consult the UFW documentation before combining it with a VPN application's rules. Multiple managers may use different chains or ordering, so an apparent allow rule may not win.

Once temporary testing succeeds, persist the route in the network manager that owns the home connection profile. Bind it to that trusted profile rather than every Wi-Fi connection. Recheck the subnet calculator before widening a host exception into a LAN-wide rule.

Test failure behavior deliberately: disconnect and reconnect the VPN, restart the client, and try an unrelated external destination. Confirm local services still work when intended and that internet egress follows the VPN's documented failure policy.

Key takeaways

• Confirm route selection before changing routes; discovery and firewall failures can look identical.
• Prefer narrow LAN exceptions with stable device addresses and reversible tests.
• Treat service ports, DNS, multicast discovery, and kill-switch rules as separate checks.
• Persist only verified changes on trusted network profiles, then retest reconnect and failure behavior.