[GH-ISSUE #3992] Multiple Exit Nodes - Metric Not Honoured #7773

Open
opened 2026-08-05 01:14:31 -04:00 by saavagebueno · 3 comments
Owner

Originally created by @washcroft on GitHub (Jun 17, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/3992

Describe the problem

In our deployment, we have multiple exit nodes, each assigned to a different user group, and one default exit node for the "All" group.

Everybody logging into Netbird will get the All group, and therefore the default exit node, but if you're also a member of more specially privileged group, you'll get access to more exit nodes which themselves can access more resources.

However it seems the metric isn't being honoured in this situation, even though the default exit node has the highest metric (9999), higher than all other exit nodes, traffic is still being routed through this exit node.

To Reproduce

See screenshots.

Expected behavior

As described above.

Are you using NetBird Cloud?

Self-hosted

NetBird version

0.47.1

Is any other VPN software installed?

No

Screenshots

Image

Image

Debug
Upload Key:
6790e8695d8c5e42d2ca22af0f62b9d2ac51312c633b35f798432aa6a93c0263/2f79283e-c81a-484f-82d7-bbac92d72c3f

status output.txt

Additional context

None

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 @washcroft on GitHub (Jun 17, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/3992 **Describe the problem** In our deployment, we have multiple exit nodes, each assigned to a different user group, and one default exit node for the "All" group. Everybody logging into Netbird will get the All group, and therefore the default exit node, but if you're also a member of more specially privileged group, you'll get access to more exit nodes which themselves can access more resources. However it seems the metric isn't being honoured in this situation, even though the default exit node has the highest metric (9999), higher than all other exit nodes, traffic is still being routed through this exit node. **To Reproduce** See screenshots. **Expected behavior** As described above. **Are you using NetBird Cloud?** Self-hosted **NetBird version** 0.47.1 **Is any other VPN software installed?** No **Screenshots** ![Image](https://github.com/user-attachments/assets/04393e97-2c7c-4eeb-a9aa-6611853df49e) ![Image](https://github.com/user-attachments/assets/6eaeb682-10dc-453f-828a-56ca3d267e6e) **Debug** Upload Key: 6790e8695d8c5e42d2ca22af0f62b9d2ac51312c633b35f798432aa6a93c0263/2f79283e-c81a-484f-82d7-bbac92d72c3f [status output.txt](https://github.com/user-attachments/files/20774839/status.output.txt) **Additional context** None **Have you tried these troubleshooting steps?** - [X] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [X] Checked for newer NetBird versions - [X] Searched for similar issues on GitHub (including closed ones) - [X] Restarted the NetBird client - [X] Disabled other VPN software - [X] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:14:31 -04:00
Author
Owner

@nazarewk commented on GitHub (Jun 17, 2025):

  1. metric is in no way related to the operating system route metric
  2. metric is considered only within the scope of a single Network Route object. Effectively when considering more than one routing peer grouped under the Network Route in the UI
<!-- gh-comment-id:2980360319 --> @nazarewk commented on GitHub (Jun 17, 2025): 1. `metric` is in no way related to the operating system route metric 2. `metric` is considered only within the scope of a single Network Route object. Effectively when considering more than one routing peer grouped under the Network Route in the UI
Author
Owner

@washcroft commented on GitHub (Jun 17, 2025):

@nazarewk thank you, that makes sense - am I missing something in how I would achieve this, or is avoiding overlapping groups the only way?

<!-- gh-comment-id:2980664424 --> @washcroft commented on GitHub (Jun 17, 2025): @nazarewk thank you, that makes sense - am I missing something in how I would achieve this, or is avoiding overlapping groups the only way?
Author
Owner

@joachimtingvold commented on GitHub (Jun 8, 2026):

@washcroft, in theory, you should be able to add multiple exit-nodes to the same exit-node entry, like this:

Image

I have not yet tested how the metric applies in this case, or what would happen if you have different distribution groups for the multiple entries.

The metric should be taken into account here. The only "downside" is that you no longer have a way to manually override the exit-nodes on the client (i.e. you cannot select one exit node over another). Since nodes cannot be member of multiple exit-nodes, you can't have a separate exit-nodes in addition to this "combined" exit-node.

Personally I stumbled upon this because I wanted to have exit-nodes at home, but also on my VPS. However, since the metric is not taken into account for separate nodes, I basically have to choose between these two options:

  1. Combined exit-node with automatic failover based on metric, but no way to manually override to a separate node.
  2. Separate exit-nodes with manual failover, and make sure to disable the ones you don't want on every client manually (or use the "auto apply" for one, and then people have to manually override).

Currently I also don't know how you would make sure the clients use the "closest" exit-node (if you have multiple). I'm traveling to South-America soon, and I'm considering renting a VPS located within South-America temporarily to use as an exit-node. Its not a big problem for me to manually select this node during my trip, but would be nice if it could be done automatically. I guess you might be able to use the optional "Access Control Group", and then combine this with some ACL-logic based on posture checks based on region/countries.

Ideally it would be nice if exit-nodes could be chosen based on latency (i.e. choose the one with the lowest latency).

<!-- gh-comment-id:4651486150 --> @joachimtingvold commented on GitHub (Jun 8, 2026): @washcroft, in theory, you should be able to add multiple exit-nodes to the same exit-node entry, like this: <img width="1213" height="229" alt="Image" src="https://github.com/user-attachments/assets/a75c41ed-1f6f-45ca-8b9a-a4c51dc8374b" /> I have not yet tested how the metric applies in this case, or what would happen if you have different distribution groups for the multiple entries. The metric **_should_** be taken into account here. The only "downside" is that you no longer have a way to manually override the exit-nodes on the client (i.e. you cannot select one exit node over another). Since nodes cannot be member of multiple exit-nodes, you can't have a separate exit-nodes in addition to this "combined" exit-node. Personally I stumbled upon this because I wanted to have exit-nodes at home, but also on my VPS. However, since the metric is not taken into account for separate nodes, I basically have to choose between these two options: 1. Combined exit-node with automatic failover based on metric, but no way to manually override to a separate node. 2. Separate exit-nodes with manual failover, and make sure to disable the ones you don't want on every client manually (or use the "auto apply" for one, and then people have to manually override). Currently I also don't know how you would make sure the clients use the "closest" exit-node (if you have multiple). I'm traveling to South-America soon, and I'm considering renting a VPS located within South-America temporarily to use as an exit-node. Its not a big problem for me to manually select this node during my trip, but would be nice if it could be done automatically. I guess you might be able to use the optional "Access Control Group", and then combine this with some ACL-logic based on posture checks based on region/countries. Ideally it would be nice if exit-nodes could be chosen based on latency (i.e. choose the one with the lowest latency).
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#7773