Windows client installs metric-1 wt0 routes for LAN-native subnet and blackholes native traffic

[sayak-brm]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Client / Agent, Peer connectivity, Routes / Exit nodes

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

Windows

NetBird version and upgrade status

Client: 0.78.2 (Windows GUI + Debian LXC router, same release line)
Management: 0.78.2
Signal: 0.78.2 (combined netbird-server image)
Relay: 0.78.2

Did this work before?

No, this never worked

Regression details

No response

Summary

Client installs metric-1 wt0 routes for a LAN it is natively attached to, blackholing native traffic to that LAN via the mesh router.

What is broken?
LAN-native + mesh peer receiving Networks routes for its own local subnet sends on-link traffic into wt0 instead of the physical adapter.

Current behavior

192.168.1.0/24 via wt0 metric 1
192.168.1.10/32 via wt0 metric 1
192.168.1.7/32 via wt0 metric 1
shadowing native 192.168.1.0/24 via vEthernet metric 256. Ping to two critical LAN hosts fails with timeouts, no client/router error logged. Disabling the router withdraws routes cleanly in 2-3s. Reproduced 3/3, outage bound by watchdog. GUI Enable Client Routes off alone did not stop install without restart.

Expected behavior

Client should not shadow a working directly-connected route with a tunnel route. Either skip install when prefix is locally attached, install at a metric that does not beat the native route, or require explicit opt-in. At minimum GUI toggle should warn restart is required.

Steps to reproduce

1. Configure Network Home LAN with resources 192.168.1.0/24, 192.168.1.10/32, 192.168.1.7/32, router peer on same L2 (192.168.1.20), masquerade true, metric 100.
2. Grant a Windows peer that is natively on 192.168.1.0/24 policy access to those resources.
3. Run Get-NetRoute baseline, then PUT /api/networks/{id}/routers/{id} {"enabled":true}.
4. Observe within ~10s: new wt0 metric 1 entries appear, ping to native .6 / .10 fails.

• Trigger: router enable for a Network the local peer has access to while locally attached.
• Frequency: 3/3 deterministic.
• Timing: fail ~10s after enable, recover 2-3s after disable.

Environment and topology

Peer A (affected): Windows 11 desktop, native 192.168.1.x/24 via Hyper-V external switch, mesh 100.86.x.x/16 via wt0.
Peer B (router): Debian 12 LXC on same bridge, LAN 192.168.1.20/24, mesh 100.86.x.x.
Same LAN or different networks: same physical L2 (192.168.1.0/24).
NAT/CGNAT/corporate firewall/mobile network: None. Flat home LAN.
Other VPN software: None.
Firewall, DNS, endpoint security: Pi-hole at .10 is itself a victim; router nft clean on disable.
Routes, DNS, policies, posture checks, or SSH rules involved: Networks resources above, router peer_groups: [routing-peers], peer in Home LAN group via legacy broad policy.
IdP, reverse proxy, or browser involved: Traefik in front of self-hosted control plane for API only.

Self-hosted details, if available

Deployment method: custom Docker Compose, combined server + Traefik.
Management/signal/relay/dashboard versions: 0.78.2 combined image.
Reverse proxy: Traefik.
IdP/provider: N/A to repro.
STUN/TURN/coturn/relay details: N/A, peers direct/relay unaffected.
Relevant component logs: no errors observed client or router side; failure is silent wrong-egress.

Logs, status output, or debug evidence

Baseline (router disabled):
`192.168.1.0/24 via vEthernet metric 256`, `100.86.0.0/16 via wt0 metric 256`, no `wt0` entry for `192.168.1.x`.
During outage:
`192.168.1.10/32 via wt0 1`, `192.168.1.7/32 via wt0 1`, `192.168.1.0/24 via wt0 1` + native `/24 via vEthernet 256` shadowed. Full `Get-NetRoute` capture and watchdog ping logs available. No `proxy_arp` in codebase. Debug bundle not attached, can provide `netbird status -dA` on request.

Related issues or discussions

Related issue/discussion: #4990 Local subnets relaying due to route metrics.
Why this may be the same: same Windows metric-precedence symptom for on-prem clients, likely same root cause. Propose linking.
Related issue/discussion: #7215 FreeBSD /32 shadowing mesh subnets.
Why this may be the same: same silent-blackhole class, different trigger (peer-LAN /32 via physical GW vs Networks /24+/32 via wt0 metric 1). Cross-platform analog only.

Impact

Affected users/peers: any peer simultaneously LAN-native and mesh-authorized for that LAN. 1 host confirmed, pattern affects all such Windows peers; code path exists on Linux/macOS/BSD.
Business or production impact: loss of hypervisor + DNS admin access from primary workstation during enable.
Workaround available: Yes. Disable Networks router restores in seconds. Client DisableClientRoutes works only after full restart (down/up), not live toggle. Least-privilege group removal also avoids install.

Additional context

Code pointers for triage: client/internal/routemanager/systemops/systemops_windows.go:274 hardcodes Metric = 1; client/internal/routemanager/static/route.go:37, systemops_generic.go:212 install path; local-subnet guard is BSD-only in systemops_generic.go:124-130 and only for legacy exclusion routes, not AddVPNRoute; client/server/server.go:481-542 + client/internal/connect.go:663 + routemanager/manager.go:141 show toggle needs restart.

[sayak-brm]

Do not shadow locally-attached routes (all desktop platforms). Extend the existing BSD-only guard to AddVPNRoute everywhere. Today systemops_generic.go:124-130 skips only legacy exclusion routes on darwin/BSD, while AddVPNRoute (systemops_nonlinux.go:32, systemops_linux.go:175, Windows via systemops_windows.go:262) only calls validateRoute, which allows local subnets. Check isPrefixInLocalSubnets() before genericAddVPNRoute() and skip with a debug log. This fixes Windows/Linux/macOS/BSD with one predicate. Linux advanced-routing already prefers main via rule priority, so the guard is a no-op there; legacy routing and Windows/macOS/BSD need it.

Stop hardcoding Windows metric 1. systemops_windows.go:274 route.Metric = 1 always beats native 256. Even with (1), use a metric that cannot win over directly-connected routes, e.g. read the best non-wt0 candidate via GetBestInterface() and install at native+10, or a high fixed value like 5000 as Tailscale does. This turns any missed guard into latency, not blackhole.

---

Issue: #7566
PR: #7567