[GH-ISSUE #4990] Local subnets relaying due to route metrics. #9662

Open
opened 2026-08-05 01:22:59 -04:00 by saavagebueno · 13 comments
Owner

Originally created by @1nerdyguy on GitHub (Dec 23, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4990

Describe the problem

Been happening for numerous versions now, but I'm having an issue I can't resolve.

I have a multi-vlan environment, as I'd expect many do. One of those vlans, lets say 10.10.10.x/24, I'm publishing as a Network so clients can access it when remote. These clients are all Windows for this discussion

The issue I run into is, when those clients aren't remote, but are on premise and say in the 10.10.11.x/24 subnet, the route distributed by netbird for 10.10.10.x/24 gets placed into the routing table with lower metric than the existing default gateway. As such, any client that tries to access 10.10.10.x/24 will go out through the netbird interface, relay about, and come back to hit that network as if they are remote.

Windows adds like 256 or something to local routes by default, so this is difficult to handle.

The answer would be to not use Netbird when on premise, which I agree with. However, with setup keys vs making users login (for an always-on setup where you identify the device vs user for ACL), this becomes difficult.

Posture checks are not an option without a large amount of overhead in cases of numerous client vlans, and still wanting to use Netbird to access some vlans all the time (air gapped vlans, etc)

To Reproduce
Pass a network through Netbird.
Go into a vlan that has that network OR has L3 access to that network.
Watch how your traffic goes out Netbird vs local resources, adding latency.

Expected behavior
Netbird routes get applied with a metric that doesn't make it lower than the standard windows metrics, allowing local routes to take precedent without manual intervention client side.

Are you using NetBird Cloud?

Both, and is the same on both.

NetBird version

from .38 to now.

Is any other VPN software installed?

No
Debug output

To help us resolve the problem, please attach the following anonymized status output

netbird status -dA

Create and upload a debug bundle, and share the returned file key:

netbird debug for 1m -AS -U

Uploaded files are automatically deleted after 30 days.

Alternatively, create the file only and attach it here manually:

netbird debug for 1m -AS

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @1nerdyguy on GitHub (Dec 23, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4990 **Describe the problem** Been happening for numerous versions now, but I'm having an issue I can't resolve. I have a multi-vlan environment, as I'd expect many do. One of those vlans, lets say 10.10.10.x/24, I'm publishing as a Network so clients can access it when remote. These clients are all Windows for this discussion The issue I run into is, when those clients aren't remote, but are on premise and say in the 10.10.11.x/24 subnet, the route distributed by netbird for 10.10.10.x/24 gets placed into the routing table with lower metric than the existing default gateway. As such, any client that tries to access 10.10.10.x/24 will go out through the netbird interface, relay about, and come back to hit that network as if they are remote. Windows adds like 256 or something to local routes by default, so this is difficult to handle. The answer would be to not use Netbird when on premise, which I agree with. However, with setup keys vs making users login (for an always-on setup where you identify the device vs user for ACL), this becomes difficult. Posture checks are not an option without a large amount of overhead in cases of numerous client vlans, and still wanting to use Netbird to access some vlans all the time (air gapped vlans, etc) **To Reproduce** Pass a network through Netbird. Go into a vlan that has that network OR has L3 access to that network. Watch how your traffic goes out Netbird vs local resources, adding latency. **Expected behavior** Netbird routes get applied with a metric that doesn't make it lower than the standard windows metrics, allowing local routes to take precedent *without* manual intervention client side. **Are you using NetBird Cloud?** Both, and is the same on both. **NetBird version** from .38 to now. **Is any other VPN software installed?** No **Debug output** To help us resolve the problem, please attach the following anonymized status output netbird status -dA Create and upload a debug bundle, and share the returned file key: netbird debug for 1m -AS -U *Uploaded files are automatically deleted after 30 days.* Alternatively, create the file only and attach it here manually: netbird debug for 1m -AS **Screenshots** If applicable, add screenshots to help explain your problem. **Additional context** Add any other context about the problem here. **Have you tried these troubleshooting steps?** - [ ] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [ ] Checked for newer NetBird versions - [ ] Searched for similar issues on GitHub (including closed ones) - [ ] Restarted the NetBird client - [ ] Disabled other VPN software - [ ] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:22:59 -04:00
Author
Owner

@coderabbitai[bot] commented on GitHub (Dec 23, 2025):

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

  • Create Plan
Examples

🔗 Similar Issues

Possible Duplicates

Related Issues

👤 Suggested Assignees

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

<!-- gh-comment-id:3688386578 --> @coderabbitai[bot] commented on GitHub (Dec 23, 2025): <!-- This is an auto-generated issue plan by CodeRabbit --> ### 📝 CodeRabbit Plan Mode Generate an implementation plan and prompts that you can use with your favorite coding agent. - [ ] <!-- {"checkboxId": "8d4f2b9c-3e1a-4f7c-a9b2-d5e8f1c4a7b9"} --> Create Plan <details> <summary>Examples</summary> - [Example 1](https://github.com/coderabbitai/git-worktree-runner/issues/29#issuecomment-3589134556) - [Example 2](https://github.com/coderabbitai/git-worktree-runner/issues/12#issuecomment-3606665167) </details> --- <details> <summary><b>🔗 Similar Issues</b></summary> **Possible Duplicates** - https://github.com/netbirdio/netbird/issues/4765 **Related Issues** - https://github.com/netbirdio/netbird/issues/4950 - https://github.com/netbirdio/netbird/issues/4768 - https://github.com/netbirdio/netbird/issues/3841 - https://github.com/netbirdio/netbird/issues/3903 </details> <details> <summary><b>👤 Suggested Assignees</b></summary> - [mitchplze](https://github.com/mitchplze) - [cheetah747](https://github.com/cheetah747) - [mertcangokgoz](https://github.com/mertcangokgoz) - [drewhemm](https://github.com/drewhemm) - [allancomar](https://github.com/allancomar) </details> --- <details> <summary> 🧪 Issue enrichment is currently in open beta.</summary> You can configure auto-planning by selecting labels in the issue_enrichment configuration. To disable automatic issue enrichment, add the following to your `.coderabbit.yaml`: ```yaml issue_enrichment: auto_enrich: enabled: false ``` </details> 💬 Have feedback or questions? Drop into our [discord](https://discord.gg/coderabbit) or [schedule a call](https://calendly.com/parth-coderabbit/issues-feedback)!
Author
Owner

@1nerdyguy commented on GitHub (Jan 3, 2026):

Problem still exists in 0.61.2

<!-- gh-comment-id:3707533788 --> @1nerdyguy commented on GitHub (Jan 3, 2026): Problem still exists in 0.61.2
Author
Owner

@1nerdyguy commented on GitHub (Jan 15, 2026):

Problem still exists in 0.62.x

<!-- gh-comment-id:3757704198 --> @1nerdyguy commented on GitHub (Jan 15, 2026): Problem still exists in 0.62.x
Author
Owner

@tazaka commented on GitHub (Jan 21, 2026):

Agent 0.64.0

Similar issue with Posture Check / Peer Network Range after network change

I have a similar problem with Posture Checks based on Peer Network Range, where routes tied to Access Policies are not applied correctly after switching networks.

Setup

  • Client connects via Ethernet → gets IP e.g. 10.120.9.10/22
  • Posture Check: Peer Network Range = 10.120.8.0/22Block
  • Routes from Access Policies using this check are not added as expected.

Problem

User switches to WiFi (completely isolated network – only internet access) and disconnects Ethernet.
NetBird agent does NOT detect the change
→ does NOT re-evaluate the Posture Check
→ client still does not receive the routes according to policy
(even though only WiFi → internet is active)

Workarounds that actually work

  • Manually disable the Ethernet interface in Windows (even when already unplugged) → triggers detection → routes are added correctly
  • Or restart NetBird client with only WiFi connected → routes appear correctly

Root cause observation

The agent fails to properly detect changes in the default/active network route.
For comparison: Cloudflare WARP handles this correctly by doing a disconnect/reconnect cycle, which forces re-evaluation of routes.

General feedback

As others have already mentioned – network range detection (office vs public) is generally unreliable in NetBird.
I agree that useful improvements would be:

  • checking public IP address
  • or using some kind of network beacon (like other solutions do)

Most importantly – the active route change detection needs to be fixed for reliable behavior.

Happy to provide logs, debug output or help reproduce if needed.

<!-- gh-comment-id:3777634868 --> @tazaka commented on GitHub (Jan 21, 2026): Agent 0.64.0 ### Similar issue with Posture Check / Peer Network Range after network change I have a similar problem with **Posture Checks** based on **Peer Network Range**, where routes tied to Access Policies are not applied correctly after switching networks. #### Setup - Client connects via **Ethernet** → gets IP e.g. `10.120.9.10/22` - Posture Check: **Peer Network Range** = `10.120.8.0/22` → **Block** - Routes from Access Policies using this check **are not added** as expected. #### Problem User switches to **WiFi** (completely isolated network – only internet access) and disconnects Ethernet. → **NetBird agent does NOT detect the change** → does NOT re-evaluate the Posture Check → client still **does not receive** the routes according to policy (even though only WiFi → internet is active) #### Workarounds that actually work - Manually **disable** the Ethernet interface in Windows (even when already unplugged) → triggers detection → routes are added correctly - Or restart NetBird client with only WiFi connected → routes appear correctly #### Root cause observation The agent fails to properly detect **changes in the default/active network route**. For comparison: **Cloudflare WARP** handles this correctly by doing a disconnect/reconnect cycle, which forces re-evaluation of routes. #### General feedback As others have already mentioned – **network range detection** (office vs public) is generally unreliable in NetBird. I agree that useful improvements would be: - checking **public IP** address - or using some kind of **network beacon** (like other solutions do) Most importantly – the **active route change detection** needs to be fixed for reliable behavior. Happy to provide logs, debug output or help reproduce if needed.
Author
Owner

@JamesTX10 commented on GitHub (Jan 21, 2026):

Can the netbird client be configured to add routes with a higher metric?

On Windows, this can be worked around with a PS script and a task that triggers off the network connected event. I worked with Copilot to create this PS script that when ran as admin, will create the metric-changing script and the task to run it. I picked a metric of 500 to make sure it was always higher than my local network metric. The interface alias for Netbird on my machine is always "wt0".

`# -------------------------------

CONFIG

-------------------------------

$TaskName = "Fix NetBird Metric"
$ScriptPath = "C:\Scripts\Fix-NetBird-Metric.ps1"

-------------------------------

Ensure script directory exists

-------------------------------

$scriptDir = Split-Path $ScriptPath
if (-not (Test-Path $scriptDir)) {
New-Item -ItemType Directory -Path $scriptDir -Force | Out-Null
}

-------------------------------

Write the metric-fix script

-------------------------------

$scriptContent = @'
$adapter = Get-NetIPInterface | Where-Object { $_.InterfaceAlias -like "wt0*" }

if ($adapter) {
foreach ($a in $adapter) {
Write-Output "NetBird interface found: $($a.InterfaceAlias)"
Set-NetIPInterface -InterfaceAlias $a.InterfaceAlias -InterfaceMetric 500
Write-Output "Metric set to 500"
}
} else {
Write-Output "NetBird interface not found"
}
'@

Set-Content -Path $ScriptPath -Value $scriptContent -Encoding UTF8 -Force

-------------------------------

Create scheduled task if missing

-------------------------------

$task = Get-ScheduledTask -TaskName $TaskName -ErrorAction SilentlyContinue

if (-not $task) {
Write-Output "Creating scheduled task '$TaskName'..."

$action = New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$ScriptPath`""

# Trigger 1: Run at logon
$trigger1 = New-ScheduledTaskTrigger -AtLogOn

# Trigger 2: Run when network profile changes (Event ID 10000)
$CIMTriggerClass = Get-CimClass -ClassName MSFT_TaskEventTrigger -Namespace Root/Microsoft/Windows/TaskScheduler:MSFT_TaskEventTrigger
$Trigger2 = New-CimInstance -CimClass $CIMTriggerClass -ClientOnly
    $Trigger2.Subscription =

@"
*[System[Provider[@Name='Microsoft-Windows-NetworkProfile'] and EventID=10000]]
"@
$Trigger2.Enabled = $True

Register-ScheduledTask -TaskName $TaskName `
    -Action $action `
    -Trigger $trigger1, $trigger2 `
    -RunLevel Highest `
    -Description "Forces NetBird interface metric to 500 whenever it reconnects." `
    -User 'System' -Force `
    | Out-Null

Write-Output "Scheduled task created."

} else {
Write-Output "Scheduled task already exists."
}

-------------------------------

Run the metric fix immediately

-------------------------------

Write-Output "Running metric fix now..."
powershell.exe -NoProfile -ExecutionPolicy Bypass -File $ScriptPath`

<!-- gh-comment-id:3780793161 --> @JamesTX10 commented on GitHub (Jan 21, 2026): Can the netbird client be configured to add routes with a higher metric? On Windows, this can be worked around with a PS script and a task that triggers off the network connected event. I worked with Copilot to create this PS script that when ran as admin, will create the metric-changing script and the task to run it. I picked a metric of 500 to make sure it was always higher than my local network metric. The interface alias for Netbird on my machine is always "wt0". `# ------------------------------- # CONFIG # ------------------------------- $TaskName = "Fix NetBird Metric" $ScriptPath = "C:\Scripts\Fix-NetBird-Metric.ps1" # ------------------------------- # Ensure script directory exists # ------------------------------- $scriptDir = Split-Path $ScriptPath if (-not (Test-Path $scriptDir)) { New-Item -ItemType Directory -Path $scriptDir -Force | Out-Null } # ------------------------------- # Write the metric-fix script # ------------------------------- $scriptContent = @' $adapter = Get-NetIPInterface | Where-Object { $_.InterfaceAlias -like "wt0*" } if ($adapter) { foreach ($a in $adapter) { Write-Output "NetBird interface found: $($a.InterfaceAlias)" Set-NetIPInterface -InterfaceAlias $a.InterfaceAlias -InterfaceMetric 500 Write-Output "Metric set to 500" } } else { Write-Output "NetBird interface not found" } '@ Set-Content -Path $ScriptPath -Value $scriptContent -Encoding UTF8 -Force # ------------------------------- # Create scheduled task if missing # ------------------------------- $task = Get-ScheduledTask -TaskName $TaskName -ErrorAction SilentlyContinue if (-not $task) { Write-Output "Creating scheduled task '$TaskName'..." $action = New-ScheduledTaskAction -Execute "powershell.exe" ` -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$ScriptPath`"" # Trigger 1: Run at logon $trigger1 = New-ScheduledTaskTrigger -AtLogOn # Trigger 2: Run when network profile changes (Event ID 10000) $CIMTriggerClass = Get-CimClass -ClassName MSFT_TaskEventTrigger -Namespace Root/Microsoft/Windows/TaskScheduler:MSFT_TaskEventTrigger $Trigger2 = New-CimInstance -CimClass $CIMTriggerClass -ClientOnly $Trigger2.Subscription = @" <QueryList><Query Id="0" Path="Microsoft-Windows-NetworkProfile/Operational"><Select Path="Microsoft-Windows-NetworkProfile/Operational">*[System[Provider[@Name='Microsoft-Windows-NetworkProfile'] and EventID=10000]]</Select></Query></QueryList> "@ $Trigger2.Enabled = $True Register-ScheduledTask -TaskName $TaskName ` -Action $action ` -Trigger $trigger1, $trigger2 ` -RunLevel Highest ` -Description "Forces NetBird interface metric to 500 whenever it reconnects." ` -User 'System' -Force ` | Out-Null Write-Output "Scheduled task created." } else { Write-Output "Scheduled task already exists." } # ------------------------------- # Run the metric fix immediately # ------------------------------- Write-Output "Running metric fix now..." powershell.exe -NoProfile -ExecutionPolicy Bypass -File $ScriptPath`
Author
Owner

@InternetWorkAcct commented on GitHub (Feb 11, 2026):

The current routing metric I see for network resources is 6 which doesn't make sense to me, it's way too low.

I'm currently working around this by pushing a larger /23 route via NetBird, thus the /24 local interface route wins. Add a DHCP option 121 if you have local networks that aren't link-local.

<!-- gh-comment-id:3884648304 --> @InternetWorkAcct commented on GitHub (Feb 11, 2026): The current routing metric I see for network resources is 6 which doesn't make sense to me, it's way too low. I'm currently working around this by pushing a larger /23 route via NetBird, thus the /24 local interface route wins. Add a DHCP option 121 if you have local networks that aren't link-local.
Author
Owner

@1nerdyguy commented on GitHub (Feb 11, 2026):

The current routing metric I see for network resources is 6 which doesn't make sense to me, it's way too low.

I'm currently working around this by pushing a larger /23 route via NetBird, thus the /24 local interface route wins. Add a DHCP option 121 if you have local networks that aren't link-local.

With how the routes are injected, thats where the issue runs in. They're injected with a low rate, and Windows decides to inflate their routes by 255 or more randomly.

<!-- gh-comment-id:3885081017 --> @1nerdyguy commented on GitHub (Feb 11, 2026): > The current routing metric I see for network resources is 6 which doesn't make sense to me, it's way too low. > > I'm currently working around this by pushing a larger /23 route via NetBird, thus the /24 local interface route wins. Add a DHCP option 121 if you have local networks that aren't link-local. With how the routes are injected, thats where the issue runs in. They're injected with a low rate, and Windows decides to inflate their routes by 255 or more randomly.
Author
Owner

@InternetWorkAcct commented on GitHub (Feb 13, 2026):

They're injected with a low rate, and Windows decides to inflate their routes by 255 or more randomly.

Not what I'm seeing on the Windows boxes, with the exception of the /32 peer routes that don't overlap with any RFC1918 networks anyway.
In this example, the NetBird Network resources show a metric of 6 in the table, while the link-local network has a metric of 281, and the DHCP option 121 network has a metric of 26.
I set the netmask to 255.255.254.0, so connecting to a host on 192.168.3.100 will route via the ethernet interface instead of the wireguard tunnel.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1    192.168.2.242     25
       100.87.0.0      255.255.0.0         On-link      100.87.35.41    261
     100.87.35.41  255.255.255.255         On-link      100.87.35.41    261
   100.87.255.255  255.255.255.255         On-link      100.87.35.41    261
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.2.0    255.255.254.0         On-link      100.87.35.41      6 <---
      192.168.2.0    255.255.255.0         On-link     192.168.2.242    281 <---
    192.168.2.242  255.255.255.255         On-link     192.168.2.242    281
    192.168.2.255  255.255.255.255         On-link     192.168.2.242    281
      192.168.3.0    255.255.255.0      192.168.2.1    192.168.2.242     26 <---
    192.168.3.255  255.255.255.255         On-link      100.87.35.41    261
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link     192.168.2.242    281
        224.0.0.0        240.0.0.0         On-link      100.87.35.41    261
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link     192.168.2.242    281
  255.255.255.255  255.255.255.255         On-link      100.87.35.41    261
===========================================================================
Persistent Routes:
  None


<!-- gh-comment-id:3897400321 --> @InternetWorkAcct commented on GitHub (Feb 13, 2026): > They're injected with a low rate, and Windows decides to inflate their routes by 255 or more randomly. Not what I'm seeing on the Windows boxes, with the exception of the /32 peer routes that don't overlap with any RFC1918 networks anyway. In this example, the NetBird Network resources show a metric of 6 in the table, while the link-local network has a metric of 281, and the DHCP option 121 network has a metric of 26. I set the netmask to 255.255.254.0, so connecting to a host on 192.168.3.100 will route via the ethernet interface instead of the wireguard tunnel. ``` IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.242 25 100.87.0.0 255.255.0.0 On-link 100.87.35.41 261 100.87.35.41 255.255.255.255 On-link 100.87.35.41 261 100.87.255.255 255.255.255.255 On-link 100.87.35.41 261 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 192.168.2.0 255.255.254.0 On-link 100.87.35.41 6 <--- 192.168.2.0 255.255.255.0 On-link 192.168.2.242 281 <--- 192.168.2.242 255.255.255.255 On-link 192.168.2.242 281 192.168.2.255 255.255.255.255 On-link 192.168.2.242 281 192.168.3.0 255.255.255.0 192.168.2.1 192.168.2.242 26 <--- 192.168.3.255 255.255.255.255 On-link 100.87.35.41 261 224.0.0.0 240.0.0.0 On-link 127.0.0.1 331 224.0.0.0 240.0.0.0 On-link 192.168.2.242 281 224.0.0.0 240.0.0.0 On-link 100.87.35.41 261 255.255.255.255 255.255.255.255 On-link 127.0.0.1 331 255.255.255.255 255.255.255.255 On-link 192.168.2.242 281 255.255.255.255 255.255.255.255 On-link 100.87.35.41 261 =========================================================================== Persistent Routes: None ```
Author
Owner

@1nerdyguy commented on GitHub (Feb 13, 2026):

Probably poor wording on my part, @InternetWorkAcct . I meant that Windows is inserting their routes with the inflated rate of 281, not that it's adjusting the Netbird routes.

Your solution of putting in the /23 subnet is feasible, but only if you're not utilizing those IP spaces. For us, that would be an issue, as we have back to back /24's through our main space, some of which we would want accessible and some not.

I also have a personal issue with 'masking' a subnet by passing a /23 for a /24. Feels wrong.

<!-- gh-comment-id:3898080184 --> @1nerdyguy commented on GitHub (Feb 13, 2026): Probably poor wording on my part, @InternetWorkAcct . I meant that Windows is inserting their routes with the inflated rate of 281, not that it's adjusting the Netbird routes. Your solution of putting in the /23 subnet is feasible, but only if you're not utilizing those IP spaces. For us, that would be an issue, as we have back to back /24's through our main space, some of which we would want accessible and some not. I also have a personal issue with 'masking' a subnet by passing a /23 for a /24. Feels wrong.
Author
Owner

@InternetWorkAcct commented on GitHub (Feb 13, 2026):

It doesn't feel wrong, it's objectively wrong 😄
However, this works, and this way I don't need to alter the configuration on the hosts themselves.

IMO the real fix would be to adjust the routing metric from the NetBird client to be much higher.

<!-- gh-comment-id:3898219750 --> @InternetWorkAcct commented on GitHub (Feb 13, 2026): It doesn't feel wrong, it's objectively wrong 😄 However, this works, and this way I don't need to alter the configuration on the hosts themselves. IMO the real fix would be to adjust the routing metric from the NetBird client to be much higher.
Author
Owner

@JamesTX10 commented on GitHub (Feb 13, 2026):

Nailed it: "IMO the real fix would be to adjust the routing metric from the NetBird client to be much higher."

I do that with a script on the host. Would be nice if NetBird handled it in the client.

<!-- gh-comment-id:3898407157 --> @JamesTX10 commented on GitHub (Feb 13, 2026): Nailed it: "IMO the real fix would be to adjust the routing metric from the NetBird client to be much higher." I do that with a script on the host. Would be nice if NetBird handled it in the client.
Author
Owner

@mlsmaycon commented on GitHub (Apr 27, 2026):

Hey Folks, thanks for the feedback and for raising the issue.

To give you an update, we are discussing the change in behavior that could fit all major 4 operating systems (macOS, Windows, Linux, and FreeBSD). Once we define that, we will probably add a resource setting to handle that.

<!-- gh-comment-id:4327120275 --> @mlsmaycon commented on GitHub (Apr 27, 2026): Hey Folks, thanks for the feedback and for raising the issue. To give you an update, we are discussing the change in behavior that could fit all major 4 operating systems (macOS, Windows, Linux, and FreeBSD). Once we define that, we will probably add a resource setting to handle that.
Author
Owner

@1nerdyguy commented on GitHub (Jun 8, 2026):

any movement on this? THis, https://github.com/netbirdio/netbird/issues/5114, https://github.com/netbirdio/netbird/issues/4950, and https://github.com/netbirdio/netbird/issues/4906

All seem very close to each other and are large impacts for those wishing to use in a production, enterprise areas. More so than reverse proxy, I'd argue, as it's core to the way the system works as a mesh overly network.

<!-- gh-comment-id:4652576418 --> @1nerdyguy commented on GitHub (Jun 8, 2026): any movement on this? THis, https://github.com/netbirdio/netbird/issues/5114, https://github.com/netbirdio/netbird/issues/4950, and https://github.com/netbirdio/netbird/issues/4906 All seem very close to each other and are large impacts for those wishing to use in a production, enterprise areas. More so than reverse proxy, I'd argue, as it's core to the way the system works as a mesh overly network.
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#9662