Everything works until you connect the corporate VPN. Then your local NAS disappears, the printer goes “offline,” and that one IoT light switch becomes a philosophical concept. The VPN didn’t just add a secure path to work; it quietly rewired your whole network.
This is almost never “a Windows bug.” It’s routing and DNS doing exactly what they were told to do—just not what you expected. Let’s fix it the right way: with split tunneling, explicit routes, predictable metrics, and tests that tell you what decision to make next.
What actually breaks when LAN access dies
When a VPN “breaks local LAN access,” people blame encryption, tunnels, firewalls, or the vibes. In practice, it’s usually one of these:
- Your default route changed (0.0.0.0/0 and/or ::/0) to point at the VPN adapter. Now “anything not explicitly local” goes into the tunnel—including the thing you thought was local.
- Your route to the local subnet lost because the VPN injected a broader route that wins. Example: you’re on 192.168.1.0/24 at home, but the VPN pushes 192.168.0.0/16 and suddenly your home LAN is “corporate” now.
- Route selection is correct but metrics aren’t. Windows picks the lowest metric, then the most specific prefix. If the VPN adapter is configured with an aggressively low metric, it will “win” too often.
- DNS changes. Your DNS servers flip to corporate resolvers that can’t resolve local names (or deliberately refuse), so “nas” and “printer” stop resolving even though IP connectivity is fine.
- Policy blocks local LAN. Some VPN clients intentionally add filters (WFP rules) to prevent local access while connected. That’s not split tunneling; that’s “no local breakout.”
- IPv6 got involved. Windows prefers IPv6 when available. A VPN that only handles IPv4 plus a LAN that advertises IPv6 can lead to surprising behavior unless you know what routes exist.
The fix is rarely “turn on split tunneling” as a magic checkbox. The fix is: define what should go through the tunnel, define what should stay local, then enforce it with routes and DNS behavior you can explain to the next person on call.
Nine facts and history nuggets you can use at parties (or incident calls)
- Split tunneling was controversial before it was trendy. Early enterprise VPNs preferred “full tunnel” because it reduced risk of bridging corporate and untrusted networks on the same host.
- Windows has used the same core route selection logic for decades. Longest prefix match wins; if tied, the lowest metric wins. The GUIs change. The math doesn’t.
- “Use default gateway on remote network” was the original UX trap. On older Windows clients, that checkbox decided whether the VPN installed a 0.0.0.0/0 route via the tunnel.
- Corporate VPN clients started pushing routes aggressively as networks got bigger. When you have dozens of internal prefixes, it’s easier to push “summary routes.” That’s also how you accidentally swallow home subnets.
- Always On VPN made split tunneling a governance problem. Once VPN becomes “always connected,” route and DNS hygiene stops being a nice-to-have and becomes daily life.
- DNS is the modern battleground. Many security programs care more about DNS leakage than raw routing, so VPN clients now manipulate DNS in increasingly creative ways.
- NRPT exists because Windows realized DNS needs policy, not hope. Name Resolution Policy Table lets you say “these domains go to these DNS servers,” which is split tunneling for DNS.
- Metric auto-tuning can be “helpful” until it isn’t. Windows can auto-assign interface metrics based on link speed. Your VPN virtual NIC can report nonsense and win routing wars.
- Overlapping private IP space is the long-running office tragedy. RFC1918 gave everyone the same three private ranges; unsurprisingly, everyone reused the same /24s. Then VPNs arrived with summary routes and ate home networks for breakfast.
Fast diagnosis playbook (check first/second/third)
If you need to get from “VPN broke my LAN” to root cause in five minutes, do it in this order:
First: determine whether it’s routing or DNS
- Try reaching a local device by IP address (not name). If IP works but name doesn’t, you’re in DNS-land.
- If IP fails, you’re in routing/firewall-land. Don’t guess; read the route table.
Second: inspect routes that would capture your LAN
- Look for 0.0.0.0/0 via VPN (full tunnel).
- Look for large/summarized private routes pushed by VPN (like 192.168.0.0/16) that overlap your home subnet.
- Confirm the local subnet route still exists and has sane metrics.
Third: check if the VPN client is enforcing local-LAN blocking
- Some clients install Windows Filtering Platform rules. Routing can be perfect and packets still die.
- Check active firewall rules, profile changes, and whether “Public” profile suddenly applied.
Fourth: verify adapter metrics and interface priority
- If two routes are similarly specific, metric decides. A VPN metric of 1 is basically an opinion, and it’s usually the wrong one.
That’s your triage ladder: IP vs DNS, then routes, then filters, then metrics.
Hands-on tasks: commands, outputs, decisions (12+)
All of these are “real tasks”: a command, what the output means, and what you do next. Use an elevated PowerShell when needed. You’re not here to click around; you’re here to control the system.
Task 1: Identify whether name resolution is the only problem
cr0x@server:~$ ping 192.168.1.10
Pinging 192.168.1.10 with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=2ms TTL=64
Ping statistics for 192.168.1.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)What it means: Layer 3 connectivity to the device exists. Routing to the LAN is probably fine.
Decision: If “ping nas” fails but pinging its IP works, skip route tweaking and go straight to DNS tasks.
Task 2: Prove the name lookup path (and which DNS server answered)
cr0x@server:~$ nslookup nas
Server: corp-dns01.example
Address: 10.20.30.40
*** corp-dns01.example can't find nas: Non-existent domainWhat it means: Your system is asking corporate DNS, which doesn’t know your home “nas” hostname.
Decision: Fix DNS split behavior (NRPT, suffix search lists, or local DNS servers) rather than messing with routes.
Task 3: Inspect the active interface configuration (spot the VPN takeover)
cr0x@server:~$ ipconfig /all
Ethernet adapter Ethernet:
IPv4 Address. . . . . . . . . . . : 192.168.1.50
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
PPP adapter CorpVPN:
IPv4 Address. . . . . . . . . . . : 10.99.12.34
Default Gateway . . . . . . . . . : 10.99.12.34
DNS Servers . . . . . . . . . . . : 10.20.30.40
DNS Suffix Search List. . . . . . : corp.exampleWhat it means: VPN is advertising itself as a gateway and pushing corporate DNS. This is typical for full tunnel (or poorly configured split tunnel).
Decision: Check routing table next to see whether 0.0.0.0/0 is now via CorpVPN.
Task 4: Read the routing table like you mean it
cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.99.12.34 10.99.12.34 5
10.0.0.0 255.0.0.0 10.99.12.34 10.99.12.34 5
192.168.1.0 255.255.255.0 192.168.1.50 192.168.1.50 25
===========================================================================What it means: Default route is via VPN. Local subnet route still exists, so local traffic should still be local—unless a broader overlapping route exists or filtering blocks it.
Decision: Search for routes that overlap your home network (like 192.168.0.0/16) or check if the VPN client blocks local LAN via firewall/WFP.
Task 5: Look for the classic overlap route that eats your LAN
cr0x@server:~$ route print | findstr 192.168.
192.168.0.0 255.255.0.0 10.99.12.34 10.99.12.34 5
192.168.1.0 255.255.255.0 192.168.1.50 192.168.1.50 25What it means: You have both 192.168.0.0/16 via VPN and 192.168.1.0/24 local. The /24 is more specific, so it should win. But if your LAN is actually 192.168.0.0/24, you’re toast: the VPN’s /16 wins over your local /24 only if your local route is missing or wrong.
Decision: Confirm your actual local prefix and ensure an explicit local route exists for it. If the VPN pushes a route that exactly matches your local prefix, only policy changes (or renumbering) fixes it cleanly.
Task 6: Show which interface Windows will use to reach a local IP
cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 192.168.1.10 | ft -AutoSize"
DestinationPrefix NextHop InterfaceAlias RouteMetric ifIndex PolicyStore
----------------- ------- -------------- ---------- ------ -----------
192.168.1.0/24 0.0.0.0 Ethernet 25 12 ActiveStoreWhat it means: For 192.168.1.10, Windows selects Ethernet (local). Good.
Decision: If this shows the VPN interface instead, you need to fix route specificity or metrics (or remove the conflicting route the VPN installed).
Task 7: Confirm whether the VPN connection is configured for split tunneling
cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -Name 'CorpVPN' | Select-Object Name,SplitTunneling,RememberCredential,AuthenticationMethod | Format-List"
Name : CorpVPN
SplitTunneling : False
RememberCredential : True
AuthenticationMethod : MSChapv2What it means: Split tunneling is disabled. Expect a default route via VPN.
Decision: If policy allows, enable split tunneling and then explicitly add corporate routes (not the other way around).
Task 8: Enable split tunneling (Windows built-in VPN)
cr0x@server:~$ powershell -NoProfile -Command "Set-VpnConnection -Name 'CorpVPN' -SplitTunneling $True -PassThru | Select-Object Name,SplitTunneling"
Name SplitTunneling
---- --------------
CorpVPN TrueWhat it means: Windows will stop forcing a default route through the VPN (depending on how the VPN server pushes routes). You now need explicit routes to corporate networks.
Decision: Immediately add routes for corporate prefixes (or rely on pushed routes if they’re correct). Verify with route print after reconnect.
Task 9: Add an explicit route to a corporate subnet via the VPN interface
cr0x@server:~$ powershell -NoProfile -Command "Add-VpnConnectionRoute -ConnectionName 'CorpVPN' -DestinationPrefix '10.20.0.0/16' -PassThru | ft -AutoSize"
ConnectionName DestinationPrefix
-------------- -----------------
CorpVPN 10.20.0.0/16What it means: You’re doing split tunneling properly: only corporate traffic goes to the tunnel.
Decision: Repeat for all required internal prefixes. Don’t add huge “just in case” routes; that’s how you capture the user’s LAN again.
Task 10: Validate that default route is back to local gateway (after reconnect)
cr0x@server:~$ route print | findstr /c:" 0.0.0.0"
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.50 10What it means: Internet/default traffic is local again. VPN should only handle the prefixes you routed to it.
Decision: If 0.0.0.0 still points at the VPN, your client/server is enforcing full tunnel. Stop fighting the OS and move to “allow local LAN” policy or client settings (if available).
Task 11: Inspect interface metrics (the silent tie-breaker)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceAlias,InterfaceMetric,NlMtu,ConnectionState | ft -AutoSize"
InterfaceAlias InterfaceMetric NlMtu ConnectionState
-------------- -------------- ----- ---------------
CorpVPN 5 1400 Connected
Ethernet 25 1500 Connected
Wi-Fi 55 1500 DisconnectedWhat it means: VPN has a lower metric, so if it installs any route of similar specificity, it’ll likely win.
Decision: If routing is unstable, set explicit metrics: raise VPN metric or lower LAN metric as appropriate. Be careful: some VPN clients reset metrics on connect.
Task 12: Set an interface metric for the VPN adapter (when you control it)
cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'CorpVPN' -InterfaceMetric 50"
What it means: No output is normal. You changed the preference order.
Decision: Re-check with Get-NetIPInterface and then Find-NetRoute. If the VPN client keeps flipping it back, you need client-side policy or vendor configuration, not hand-tuned metrics.
Task 13: Trace the packet path to a “local” host that fails
cr0x@server:~$ tracert 192.168.1.10
Tracing route to 192.168.1.10 over a maximum of 30 hops
1 25 ms 24 ms 25 ms 10.99.12.34
2 * * * Request timed out.What it means: Your “local” traffic is going into the VPN (first hop is the VPN gateway/interface). That’s a routing problem, not a printer problem.
Decision: Fix the route table: ensure there’s an explicit on-link route for your local subnet via Ethernet/Wi‑Fi, and remove/avoid conflicting VPN routes.
Task 14: Check whether Windows firewall profile flipped (and is blocking discovery/SMB)
cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | ft -AutoSize"
Name InterfaceAlias NetworkCategory IPv4Connectivity IPv6Connectivity
---- -------------- --------------- ---------------- ---------------
HomeNetwork Ethernet Private Internet NoTraffic
CorpVPN CorpVPN Public Internet NoTrafficWhat it means: VPN interface is on Public profile. Some environments also cause the primary profile to become Public, which breaks file/printer discovery and inbound rules.
Decision: If your LAN profile became Public, fix the network category (where policy allows) or adjust firewall rules for required services (SMB, mDNS, LLMNR, WS-Discovery) carefully.
Task 15: Inspect active firewall rules that might block local subnet while VPN is connected
cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Outbound | ? DisplayName -match 'VPN|Block|Local' | Select-Object -First 8 DisplayName,Action,Profile | ft -AutoSize"
DisplayName Action Profile
----------- ------ -------
Block local subnets when VPN active Block AnyWhat it means: The VPN client (or corporate policy) installed an explicit block rule. Routing tweaks won’t help.
Decision: You need a policy exception (“allow local LAN access”), a different VPN posture, or a separate trusted network design. Don’t cargo-cult route changes against a firewall block.
Task 16: Verify DNS servers and per-interface DNS assignment
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | ft -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet {192.168.1.1}
CorpVPN {10.20.30.40,10.20.30.41}What it means: DNS is split per interface, but Windows’ resolver behavior may still prefer corporate DNS for single-label names or certain suffix searches.
Decision: Use FQDNs for corporate services, configure a suffix search list intentionally, or use NRPT so corp domains go to corp DNS while everything else stays local.
Split tunneling on Windows: how it really works
Split tunneling means: only traffic destined for specific remote networks goes through the VPN. Everything else—your local LAN, your home internet breakout, your random printer web UI—stays on the local network.
Full tunnel means: the VPN becomes your default gateway. That’s simpler for security teams (one choke point), and sometimes required for compliance. It’s also how you end up trying to print via a data center three states away.
On Windows, split tunneling is ultimately expressed as routes:
- In full tunnel, you get 0.0.0.0/0 via VPN.
- In split tunnel, you get only corporate prefixes via VPN.
- Local subnet routes remain on-link (Ethernet/Wi‑Fi).
Three models you’ll see in the wild
- Windows built-in VPN (IKEv2/SSTP/L2TP) with Set-VpnConnection
Works well when you control both endpoints or can push sane routes. Good for Always On VPN style setups. - Third-party client that injects routes and firewall rules
You can sometimes configure split tunnel in the client, but the client may also enforce “block local LAN” with WFP rules. Read the vendor settings; don’t assume Windows knobs apply. - “Split tunnel” that isn’t
Some setups call themselves split tunnel because they exclude a couple internet services, but still send all private ranges through the tunnel. That’s not split tunneling; that’s selective misery.
What you should do, opinionatedly
- Prefer route-based split tunneling. Declare corporate prefixes explicitly. Keep them as narrow as possible. Summary routes are fine only if you own the address plan and it won’t overlap users.
- Don’t rely on “metrics magic.” Metrics are tie-breakers, not design tools. Use explicit prefixes first.
- Assume overlapping RFC1918 ranges will happen. If your corp network uses 192.168.0.0/16, you’ve basically chosen to fight every home router on Earth.
One quote worth keeping in your head during VPN design reviews: paraphrased idea from John Ousterhout: “Good engineering is about complexity management.” Routing complexity always collects interest.
DNS: the quieter way VPNs break your LAN
Routing gets all the attention because it’s visible: route tables, gateways, hop counts. DNS failures feel like ghosts. You type \\nas and Windows shrugs. You try \\192.168.1.10 and it works. That’s not supernatural; that’s the resolver doing what it’s configured to do.
Why VPN DNS causes local pain
- Corporate DNS doesn’t know your local names. Single-label names like
nasorprinteroften rely on local suffix search, mDNS, LLMNR, or your home router’s DNS proxy. - Corporate DNS may intentionally block private reverse lookups. Security teams sometimes harden resolvers to refuse “weird” queries from clients, including local reverse DNS patterns.
- Windows may prefer one interface’s DNS for certain queries. Per-interface DNS exists, but name resolution behavior depends on suffixes, policies, and whether the VPN client sets interface priority.
Practical DNS strategy that doesn’t make you cry
- Use FQDNs for corporate services. Don’t depend on suffix search for production tools. It’s convenient until it isn’t.
- Use NRPT to send corp domains to corp DNS. That’s clean split tunneling for names.
- Keep local DNS for local names. If you want
nasto resolve, your system needs a resolver that knows it (home router, local DNS server, hosts file as a last resort).
Joke #1: DNS is like a phone book, except it’s wrong more often and you still call it “critical infrastructure.”
NRPT and name resolution strategies (Windows Pro tricks)
NRPT (Name Resolution Policy Table) lets you say: “For these namespaces, use these DNS servers.” It’s the grown-up version of hoping Windows picks the right DNS interface.
Typical pattern:
- For corp.example and maybe a couple internal zones, use corporate DNS servers reachable over VPN.
- For everything else, keep using local DNS (home router, ISP, whatever your LAN provides).
NRPT is usually managed via Group Policy in enterprises. But for diagnosis, it’s useful to inspect what’s already there.
cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object Namespace,NameServers,DirectAccessDnsServers,Comment | ft -AutoSize"
Namespace NameServers DirectAccessDnsServers Comment
--------- ---------- ---------------------- -------
.corp.example {10.20.30.40,10.20.30.41} {} What it means: Queries for *.corp.example will go to the corporate DNS servers listed.
Decision: If there’s no NRPT and your VPN is hijacking DNS globally, ask for NRPT-based split DNS or configure “use default gateway on remote network” plus explicit DNS policies—depending on your org’s security posture.
Three corporate mini-stories from the trench
Mini-story 1: The incident caused by a wrong assumption (overlapping address space)
A mid-sized company rolled out a new VPN client profile after a merger. The network team had summarized internal routes to keep configuration tidy: one broad private prefix, pushed to every client. On paper, it was elegant. In reality, it assumed employees didn’t have the same RFC1918 ranges at home.
Monday morning, the helpdesk queue went feral. “Can’t print,” “can’t reach home NAS,” “Zoom is fine but my smart thermostat app is dead,” and the best one: “My kid’s game console says it’s in another country.” That last one wasn’t strictly the VPN’s fault, but it didn’t help morale.
The first responders chased firewall rules and driver issues because the VPN connected successfully and corporate apps worked. The trick was noticing a pattern: the failures were always to 192.168.0.0-ish devices. People with 10.0.0.0/24 home networks were mostly fine.
Route tables told the story: a big 192.168.0.0/16 route via the VPN, “because corporate uses lots of 192.168.*.” Employees’ home routers also used… 192.168.*. Packets for the home printer went into the tunnel, hit a corporate router that had no idea where “Bob’s HP LaserJet” lived, and died quietly.
The fix wasn’t clever; it was responsible. They stopped pushing the broad prefix and instead pushed specific corporate subnets. Longer term, they committed to an internal address plan that didn’t collide with consumer defaults. The incident ended when they replaced an assumption with an inventory.
Mini-story 2: The optimization that backfired (metrics and “faster VPN”)
A different org had a performance complaint: “VPN is slow.” Someone noticed the VPN adapter had a higher interface metric than Wi‑Fi, and decided to “optimize” by forcing the VPN metric to 1. The change was rolled out via a script. It was fast. It was also wrong.
For a few users, corporate apps seemed snappier. For many others, local services degraded in subtle ways: file copies to the home NAS started timing out, local backups stalled, and printers became unreliable. Not completely dead—just flaky enough to produce endless tickets and no single smoking gun.
What happened is the classic: with a super-low VPN metric, Windows preferred the VPN for routes that weren’t strictly nailed down, especially when multiple interfaces were up (Ethernet and Wi‑Fi) and some routes were equally specific. Add a little DHCP churn, and route selection would flip at inconvenient times.
The rollback fixed it. Then they did the adult version: they left metrics mostly automatic, enabled split tunneling properly, and pushed explicit corporate routes. Performance improved for the right reasons: less unnecessary traffic through the tunnel, fewer retransmits, fewer broken local flows.
Mini-story 3: The boring but correct practice that saved the day (standard diagnostics and route snapshots)
A financial services team had an internal rule: every remote-access incident gets a “network snapshot” attached to the ticket. No exceptions. It was boring. People complained. Then it paid for itself repeatedly.
When a new VPN profile rollout triggered scattered reports of “LAN unreachable,” the on-call engineer didn’t guess. They compared two snapshots from one affected user: before VPN connect and after. The delta was obvious: a default route via VPN and a new block rule named exactly like what it did.
Because they had consistent artifacts—ipconfig /all, route print, interface metrics, DNS servers—they could escalate with precision: “Your client policy is installing outbound blocks to local subnets when connected. This is not a user route issue.”
The security team acknowledged it quickly because it was measurable, not emotional. They created an approved exception group for users who needed local LAN access (lab environments, on-site techs) and documented the risk. The boring practice—repeatable diagnostics—kept the debate grounded in facts instead of screenshots.
Common mistakes: symptom → root cause → fix
This section is the stuff that shows up in tickets, Slack threads, and your least favorite meetings.
1) “VPN connected, but I can’t access my printer/NAS”
Symptom: Local device by name fails; sometimes by IP fails too.
Root cause: Full tunnel default route via VPN, or VPN blocks local subnet via firewall/WFP.
Fix: If allowed, enable split tunneling and add explicit corporate routes. If policy blocks local LAN, request the “allow local LAN” setting or an exception profile. Validate with tracert and firewall rule inspection.
2) “By IP it works, by hostname it fails”
Symptom: ping 192.168.1.10 works; ping nas fails.
Root cause: Corporate DNS is now your primary resolver, and it can’t resolve local names.
Fix: Use NRPT to route corp domains to corp DNS. Keep local DNS for local names. Or use FQDNs / static entries where appropriate.
3) “Some local IPs work, others don’t”
Symptom: Can reach 192.168.1.1 but not 192.168.1.10 while on VPN.
Root cause: Overlapping routes or a pushed summary route capturing part of the LAN, or a specific block rule targeting ranges.
Fix: Compare Find-NetRoute for working vs non-working destinations. Remove/avoid conflicting VPN routes. Narrow corporate prefixes. If it’s a block rule, fix policy rather than routes.
4) “Local shares disappear only when on Wi‑Fi, not on Ethernet”
Symptom: Behavior changes with access medium.
Root cause: Different local subnets, different metrics, different DNS servers, or different firewall profiles per interface.
Fix: Check Get-NetConnectionProfile and Get-NetIPInterface on both. Standardize metrics and DNS per interface. Confirm routes for the exact local prefix you’re on.
5) “Everything is slow after enabling split tunneling”
Symptom: Corporate apps slow, internet fine.
Root cause: Missing corporate routes, so traffic hairpins incorrectly (e.g., going out locally and failing back), or DNS queries for corp domains going to public DNS then timing out.
Fix: Add the right corporate prefixes with Add-VpnConnectionRoute and implement split DNS (NRPT). Validate with tracert to corp endpoints and nslookup for corp FQDNs.
6) “VPN works, but only one internal app is unreachable”
Symptom: Most corp resources work; one subnet doesn’t.
Root cause: That subnet’s route wasn’t pushed/added, or it overlaps a local range and loses.
Fix: Find-NetRoute -RemoteIPAddress x.x.x.x for that app server. Add a specific route via VPN or fix overlap by renumbering (yes, really) or using NAT on the VPN concentrator.
7) “After VPN connect, Windows says network is Public and discovery dies”
Symptom: Devices aren’t discoverable; SMB browsing fails; inbound rules don’t match.
Root cause: Network category changed to Public, often triggered by VPN adapter behavior or NLA confusion.
Fix: Correct network category where permitted, or create explicit firewall rules for required services on the right profile. Don’t just disable the firewall unless you enjoy audit findings.
Joke #2: “Just disable the firewall” is the networking equivalent of fixing a rattling car by turning up the radio.
Checklists / step-by-step plan (boring on purpose)
Step-by-step: fix a Windows built-in VPN profile for split tunneling
- Inventory what must go through VPN. List corporate prefixes and domains required for work. If your list is “everything,” you’re doing full tunnel and should admit it.
- Enable split tunneling. Use
Set-VpnConnection -SplitTunneling $True. - Add routes for each corporate prefix. Use
Add-VpnConnectionRouteper prefix. - Reconnect VPN. Route changes often apply cleanly after reconnect.
- Validate routes. Confirm default route is local, and corporate prefixes route to VPN.
- Fix DNS behavior. Use NRPT for corp zones. Ensure local names still resolve using local DNS (or move to FQDNs).
- Lock in metrics only if needed. If route selection is unstable, adjust interface metrics—but beware client resets.
- Document the decision. Split tunneling is a security posture. Make the risk explicit and approved.
Checklist: what to capture for a reproducible “VPN breaks LAN” ticket
- Local subnet (e.g., 192.168.1.0/24), gateway IP, and whether Wi‑Fi/Ethernet
ipconfig /allbefore and after connecting VPNroute printbefore and after connecting VPNGet-NetIPInterface(metrics) andGet-NetConnectionProfile(firewall profile)- One failing test by name and by IP (
ping nasandping 192.168.1.10) nslookupfor both a corporate FQDN and a local nametracertto one local IP and one corporate IP- Any VPN client setting labeled “block local network” / “allow LAN access”
FAQ
1) Why does my VPN kill access to 192.168.1.x devices?
Either the VPN becomes your default gateway (full tunnel), or it pushes routes that overlap your home subnet. Check route print and look for 0.0.0.0/0 via VPN or broad 192.168.0.0/16 routes.
2) Is split tunneling insecure?
It can be, if your endpoint is unmanaged or if you’re effectively bridging untrusted networks and corporate access without controls. In managed environments, split tunneling is common with compensating controls (EDR, posture checks, DNS policies, per-app VPN, strong identity). Security is a design, not a checkbox.
3) I enabled split tunneling but corporate apps stopped working. What did I miss?
You likely removed the default route via VPN but didn’t add routes for all required corporate prefixes, or DNS for corp domains is still going to local resolvers. Add missing routes and implement split DNS (NRPT) for corporate namespaces.
4) Why does \\nas fail but \\192.168.1.10 works?
DNS (or LLMNR/mDNS) is the culprit. Your VPN probably set corporate DNS as primary, and that DNS can’t resolve your local single-label names. Fix with NRPT, FQDN usage, or local DNS settings.
5) Can I just add a static route for my home subnet?
Sometimes. If the VPN pushes a route that conflicts, a more specific local route can win. But if the VPN installs firewall blocks or if the conflict is exact (same prefix length), static routes won’t save you. Also, many VPN clients reapply routes on connect.
6) Why does the VPN client have an “Allow LAN access” toggle?
Because some clients intentionally block local subnets while connected to prevent split-horizon risks (like malware reaching corporate through a compromised LAN). That toggle usually controls firewall/WFP behavior, not just routes.
7) What about IPv6—should I disable it?
Don’t disable IPv6 as a first move. First, inspect IPv6 routes and whether the VPN supports IPv6. If you have IPv6 on LAN and the VPN only handles IPv4, you can end up with weird asymmetry. Fix by ensuring consistent policy: either support IPv6 properly or define how IPv6 traffic should be handled.
8) How do I know if Windows is sending traffic to the VPN or local interface?
Use Find-NetRoute -RemoteIPAddress to see the chosen interface for a destination, and tracert to confirm the first hop. If hop 1 is a VPN gateway/interface, you’re not staying local.
9) My company forbids split tunneling. Am I stuck?
Maybe, but you still have options: request an official “allow local LAN” exception, use a dedicated non-overlapping home subnet (renumber your LAN), or use a separate device for local resources. Fighting policy with hacked routes usually loses—and creates uglier incidents.
10) Why does this happen more with home networks than office networks?
Home networks commonly use default consumer subnets (192.168.0.0/24, 192.168.1.0/24). Enterprises that push broad private routes collide with those defaults. Offices typically have managed address plans and fewer overlaps—ideally.
Conclusion: next steps you can actually do today
If your VPN breaks local LAN access, stop treating it like a spooky client bug. It’s routing, DNS, or policy—usually in that order.
- Run the fast diagnosis: test by IP vs name, then inspect routes, then check for firewall/WFP blocks, then metrics.
- Make a call: If policy allows, implement real split tunneling (explicit corporate routes). If policy forbids it, pursue “allow LAN” exceptions or fix overlap by renumbering your home subnet.
- Fix DNS intentionally: NRPT for corporate zones, local DNS for local names, and fewer single-label hostnames in workflows.
- Standardize evidence: capture
ipconfig /all,route print, and key PowerShell outputs before/after connect. It turns arguments into engineering.
Do it once, document it, and the next time someone says “the VPN ate my printer,” you’ll have an answer that’s better than a sigh.