A VPN connection should not automatically turn your local network into a ghost town. If your printer, NAS, or another PC vanishes the moment you connect, the culprit is usually not the device—it is the route Windows chooses for that traffic, or a firewall rule on the destination device. The good news: Windows 10 and Windows 11 include the tools to prove which one it is before you start toggling settings like a network archaeologist.

A laptop connects securely to the cloud and internet alongside a router, printer, and network storage device. First: confirm that local-LAN access is allowed​

Before changing anything, determine whether this is a personal VPN or a work-managed VPN.

Some corporate VPN profiles deliberately force all traffic through the company network and prevent access to the local subnet. This avoids a device acting as an unintended bridge between an untrusted home network and the corporate network. If the PC is managed through Intune, Group Policy, or a company VPN client, do not try to work around that policy. Ask the VPN administrator whether local LAN access, split tunneling, or a local-subnet exclusion is supported.

Microsoft’s VPN documentation distinguishes between:

  • Force tunnel: traffic uses the VPN by default.
  • Split tunnel: Windows routes only specified traffic into the VPN while other destinations use the physical Wi-Fi or Ethernet adapter.
  • Force tunnel with exclusions: most traffic remains in the VPN, but selected destinations—such as the local subnet—stay on the physical network.

That last model is often the best fit for a home printer or NAS: keep the VPN’s protection for normal traffic while allowing only the trusted local subnet to remain reachable.

Record the local network details before connecting​

Disconnect the VPN temporarily, then open Windows Terminal or PowerShell and run:

ipconfig

Under the active Wi-Fi or Ethernet adapter, note:

  • IPv4 Address — for example, 192.168.50.24
  • Subnet Mask — often 255.255.255.0
  • Default Gateway — for example, 192.168.50.1

A mask of 255.255.255.0 normally means the local subnet is:

192.168.50.0/24

Also record the IP address of the device you need. Use a fixed address or DHCP reservation for a printer or NAS where possible. Troubleshooting by name can be misleading because VPN DNS policies may resolve names differently; testing by IP removes that variable.

With the VPN disconnected, test the target directly:

Test-NetConnection 192.168.50.40 -Port 445

Replace 192.168.50.40 with the NAS or PC’s address. TCP port 445 is the standard SMB file-sharing port. A successful result should show:

TcpTestSucceeded: True

For a printer’s web interface, test the port it actually uses, commonly 80 or 443:

Test-NetConnection 192.168.50.60 -Port 443

Do not rely only on ping. Many printers, NAS appliances, and Windows firewall policies ignore ICMP echo requests even when the actual service is reachable.

Connect the VPN and inspect the route​

Now connect the VPN and run the same test again. If it fails only while the VPN is active, inspect the route Windows has for the destination:

Code: 
Get-NetRoute -DestinationPrefix 192.168.50.40/32 |
 Format-Table DestinationPrefix,NextHop,InterfaceAlias,RouteMetric -AutoSize

You can also use the old-school but still useful route table:

route print

Look for these warning signs:

  • A VPN adapter has become the preferred route for your local subnet.
  • The VPN added a low-metric default route, such as 0.0.0.0/0.
  • There is no specific local route for the LAN subnet through Wi-Fi or Ethernet.
  • Your local network and the VPN’s corporate network use the same IP range.

That last one is the notorious address-overlap problem. If both your home router and the corporate network use 192.168.1.0/24, Windows cannot reliably infer whether 192.168.1.50 belongs to your home printer or a corporate host. No firewall tweak can fix an ambiguous map. The clean fix is to change the home LAN to a less common subnet, such as 192.168.50.0/24 or 10.77.20.0/24, or have the VPN administrator address the overlap.

Microsoft documents that a force-tunnel profile adds VPN default routes with a lower metric, which can cause traffic to prefer the VPN unless a more specific route exists for the physical interface.

Fix the routing policy—the right way​

Option 1: Use your VPN client’s “Allow LAN access” setting​

Many commercial VPN applications include a setting with a name such as:

  • Allow LAN traffic
  • Allow access to local network devices
  • Local network sharing
  • Bypass VPN for local network

Use that feature if it exists. It is usually safer than manually editing routes because the VPN client can restore the intended configuration whenever it reconnects.

Option 2: Enable split tunneling for a personal Windows VPN profile​

For a Windows built-in VPN profile that you own and are authorized to modify, open PowerShell as Administrator and first list profiles:

Get-VpnConnection

Then enable split tunneling for the appropriate connection:

Set-VpnConnection -Name "Your VPN Name" -SplitTunneling $true -PassThru

Replace "Your VPN Name" with the exact profile name.

This is a broad change: traffic outside the VPN’s defined internal routes can use your normal network connection. That may be appropriate for a personal VPN, but it may not meet an employer’s security requirements. Microsoft’s Set-VpnConnection command supports changing the split-tunneling behavior of an existing native Windows VPN profile.

Disconnect and reconnect the VPN after changing the profile, then repeat your connectivity test.

Option 3: Ask IT for a narrowly scoped local-subnet exclusion​

For managed Windows VPN deployments, the preferred solution is usually an administrator-configured exclusion route for the local subnet, not a user-created workaround.

Windows VPN profiles can define routes that explicitly use the physical interface rather than the VPN. Microsoft’s VPNv2 configuration documentation calls this an ExclusionRoute; it can direct a specified destination prefix over the physical network while the broader VPN policy remains in force.

For example, an administrator could permit only 192.168.50.0/24 locally while all other destinations remain protected by the force-tunnel VPN. That is precise, auditable, and considerably less adventurous than turning every laptop into a dual-homed networking experiment.

Check Windows Firewall on the PC or NAS side​

If the route is correct but file sharing still fails, inspect the destination device. A firewall rule on the NAS, printer, or Windows PC may be rejecting the connection.

For a Windows PC that is hosting a shared folder or printer:

  • Open Windows Security.
  • Select Firewall & network protection.
  • Select Allow an app through firewall.
  • Ensure File and Printer Sharing is permitted for the appropriate trusted network profile.
  • For deeper inspection, open Windows Defender Firewall with Advanced Security.
  • Under Inbound Rules, verify that File and Printer Sharing (SMB-In) rules are enabled where appropriate.

The Windows Defender Firewall with Advanced Security MMC console opens with firewall rule nodes available, including Outbound Rules in the left navigation pane.

Microsoft’s SMB troubleshooting guidance specifically identifies TCP 445 and the File and Printer Sharing (SMB-In) inbound rules as checks when an SMB connection fails.

Avoid the tempting “solution” of disabling Microsoft Defender Firewall altogether. That removes an important layer of protection and tells you almost nothing about which rule was actually blocking the connection.

For a NAS or printer, check its own management console for:

  • An IP allowlist or trusted-subnet setting
  • A firewall feature
  • SMB/file-sharing service status
  • Printer web-management restrictions
  • A changed IP address after DHCP lease renewal

Validate the repair safely​

Once routing and firewall settings are corrected, test only the service you need:

Test-NetConnection 192.168.50.40 -Port 445

For SMB shares, try the IP-based path in File Explorer:

\\192.168.50.40\ShareName

For a printer, open its known IP address in a browser or print a Windows test page. If direct IP access works but the device does not appear under Network in File Explorer, that is a discovery issue—not necessarily a connectivity failure. Network discovery uses separate protocols and firewall rules; direct access is the more meaningful test.

The short version​

When a VPN blocks local devices, work through the problem in this order:

  • Confirm that local access is permitted by VPN policy.
  • Test the printer, NAS, or PC by IP address with the VPN disconnected.
  • Reconnect the VPN and inspect the route selected for that address.
  • Check for overlapping local and corporate IP ranges.
  • Prefer the VPN client’s official LAN-access setting or an administrator-managed exclusion route.
  • Verify the destination’s firewall and SMB or printer service.
  • Test the exact port and service instead of relying on device discovery or ping.

A VPN should be a secure tunnel, not a trapdoor beneath your home office. Once Windows has an unambiguous route to the local subnet and the destination firewall permits the requested service, your printer, NAS, and local PCs can coexist with the VPN without drama—or at least with the kind of drama that ends in a green TcpTestSucceeded line.

 

Last edited by a moderator:
Click to expand...
You must log in or register to reply here.