SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-06-05 06:52:00 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

[RFC] - Should exit nodes routes be applied by default? #1017

New Issue
Closed
opened 2025-11-20 05:21:50 -05:00 by saavagebueno · 15 comments
saavagebueno commented 2025-11-20 05:21:50 -05:00
Owner
Copy Link

Originally created by @mlsmaycon on GitHub (Jun 25, 2024).

Hello Everyone,

We are working on improving our network routes and enhancing the end-user experience, and we need your input. Specifically, we want to know your expectations regarding the default configuration of the exit node route.

In the scope of your organization, should the exit node route be applied by default on the client side when configured in the dashboard, or should users have the option to choose whether to apply it to their system?

Additionally, with route selection persistence, we plan to store the user's last choice. Therefore, your feedback should focus on the initial route configuration for organizations.

We would greatly appreciate your feedback on this matter. It would be even more helpful if you could share your specific use cases for exit nodes and the number of exit nodes you have in your account. For example, you might have three exit nodes, one per location, to access restricted sites.

Originally created by @mlsmaycon on GitHub (Jun 25, 2024). Hello Everyone, We are working on improving our network routes and enhancing the end-user experience, and we need your input. Specifically, we want to know your expectations regarding the default configuration of the exit node route. In the scope of your organization, should the exit node route be applied by default on the client side when configured in the dashboard, or should users have the option to choose whether to apply it to their system? Additionally, with route selection persistence, we plan to store the user's last choice. Therefore, your feedback should focus on the initial route configuration for organizations. We would greatly appreciate your feedback on this matter. It would be even more helpful if you could share your specific use cases for exit nodes and the number of exit nodes you have in your account. For example, you might have three exit nodes, one per location, to access restricted sites.
saavagebueno added the rfc label 2025-11-20 05:21:50 -05:00
saavagebueno commented 2025-11-20 05:21:51 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 25, 2024):

We will close this RFC on July 1st.

@mlsmaycon commented on GitHub (Jun 25, 2024): We will close this RFC on July 1st.
saavagebueno commented 2025-11-20 05:21:51 -05:00
Author
Owner
Copy Link

@Zaunei commented on GitHub (Jun 25, 2024):

First of all, thank you for asking for feedback 👍

Thanks to the new DNS routes, we can use almost all resources that have IP allowlists even without exit nodes.

So our primary use case for exit nodes is for clients that are logged in abroad and need a different IP when surfing or resources that use IP allowlists that use too many different domains to create DNS routes for everything.

For us, a single exit node is currently sufficient and I would prefer not to have the default route automatically activated in the client. Precisely because it tends to drop connections when you connect to the VPN, it also currently disables IPv6.

What I would be very happy about in the UI client would be a separate selection of exit nodes, separate from the current network route selection. I really like the implementation of Tailcale here:

Screenshot 2024-06-25 at 10 25 22@2x

@Zaunei commented on GitHub (Jun 25, 2024): First of all, thank you for asking for feedback 👍 Thanks to the new DNS routes, we can use almost all resources that have IP allowlists even without exit nodes. So our primary use case for exit nodes is for clients that are logged in abroad and need a different IP when surfing or resources that use IP allowlists that use too many different domains to create DNS routes for everything. For us, a single exit node is currently sufficient and I would prefer not to have the default route automatically activated in the client. Precisely because it tends to drop connections when you connect to the VPN, it also currently disables IPv6. What I would be very happy about in the UI client would be a separate selection of exit nodes, separate from the current network route selection. I really like the implementation of Tailcale here: ![Screenshot 2024-06-25 at 10 25 22@2x](https://github.com/netbirdio/netbird/assets/97038255/618907fe-8b56-44a2-9a24-994b500dcf8d)
saavagebueno commented 2025-11-20 05:21:51 -05:00
Author
Owner
Copy Link

@Yxnt commented on GitHub (Jun 25, 2024):

image
Our company is located in China, so the usage scenarios may be different from those in other countries.

  1. we have multiple offices, when employees travel to office A, we prefer them to manually select the exit node to connect to the network of the target office in order to use some special applications in the local office.
  2. there are some public services that can be used between offices (this is currently being addressed by using different tags).
  3. adding an Exit node now requires setup-key registration to set peers as an Exit node, we might prefer administrators to be able to set normal peers as Exit nodes in the background (instead of having to use setup-key).
@Yxnt commented on GitHub (Jun 25, 2024): ![image](https://github.com/netbirdio/netbird/assets/10323352/4f2d1052-23ba-43df-8549-084ab5ab7d6b) Our company is located in China, so the usage scenarios may be different from those in other countries. 1. we have multiple offices, when employees travel to office A, we prefer them to manually select the exit node to connect to the network of the target office in order to use some special applications in the local office. 2. there are some public services that can be used between offices (this is currently being addressed by using different tags). 3. adding an Exit node now requires setup-key registration to set peers as an Exit node, we might prefer administrators to be able to set normal peers as Exit nodes in the background (instead of having to use setup-key).
saavagebueno commented 2025-11-20 05:21:52 -05:00
Author
Owner
Copy Link

@svardie commented on GitHub (Jun 25, 2024):

For our use case it will be totally fine if exit node route will be enabled by default, but netbird client should remember if user deactivated this route manualy and no reapply it after disconnect or client restart.

@svardie commented on GitHub (Jun 25, 2024): For our use case it will be totally fine if exit node route will be enabled by default, but netbird client should remember if user deactivated this route manualy and no reapply it after disconnect or client restart.
saavagebueno commented 2025-11-20 05:21:52 -05:00
Author
Owner
Copy Link

@otaconix commented on GitHub (Jun 25, 2024):

Preface: I do not use Netbird within the context of an organization. I use it as a sort of VPN for myself, so I can access resources that I do not wish to expose to the internet. Let it be clear that I can't speak for users that have organizational needs.

Personally, I'd like to be able to:

  1. keep the ability to target exit nodes to specific groups as a form of access control (only nodes in specific groups may use exit nodes)
  2. have the client be able to select whether it wants to use an exit node at will. It'd be nice if, as a user, I don't need to login as an administrator to enable/disable the exit node whenever I feel like using one.

I personally have no need to enforce that specific exit nodes are used at all times, but I can see how that could be useful.

@otaconix commented on GitHub (Jun 25, 2024): Preface: I do not use Netbird within the context of an organization. I use it as a sort of VPN for myself, so I can access resources that I do not wish to expose to the internet. Let it be clear that I can't speak for users that have organizational needs. Personally, I'd like to be able to: 1. keep the ability to target exit nodes to specific groups as a form of access control (only nodes in specific groups may use exit nodes) 2. have the client be able to select whether it wants to use an exit node at will. It'd be nice if, as a user, I don't need to login as an administrator to enable/disable the exit node whenever I feel like using one. I personally have no need to enforce that specific exit nodes are used at all times, but I can see how that could be useful.
saavagebueno commented 2025-11-20 05:21:52 -05:00
Author
Owner
Copy Link

@W1BTR commented on GitHub (Jun 27, 2024):

I certainly think it should be appliable through the web UI. Currently this can be done by setting a group, but configuring a group's defaults would be good.

The biggest issue is simply that they all enable by default. A device cannot have access to an exit node without being forced to be connected to all of them on boot.

This is especially an issue on workstations, where the netbird trayicon doesnt even start, and it connects to all exit nodes. I'm constantly forgetting this is a thing and wondering why my connection is dropping or Im getting poor latency (compared to what I should be getting) or I am unable to reach LAN devices.

Personally, I think it should be a group option. Either in a dedicated "groups" tab or in policies, I believe you should be able to configure certain groups with the following options:

Group Exit Route Options (set per exit node):

  1. Off by Default (user settings will save on reboot)
  2. On by Default (user settings will save on reboot)
  3. Force On (exit nodes are forced on)

This would allow a few things. First, it resolves the issues we're facing that means we have to customize netbird's local config on every boot. Second, it still allows us to set it as default if we want to, in an easy and scallable way (we can quickly change for all members of a group, quickly add clients to an exit node with a group). Third, it still allows powerful combinations and customization that netbird excells with.

@W1BTR commented on GitHub (Jun 27, 2024): I certainly think it should be appliable through the web UI. Currently this can be done by setting a group, but configuring a group's defaults would be good. The biggest issue is simply that they all enable by default. A device cannot have access to an exit node without being **forced** to be connected to all of them on boot. **This is especially an issue on workstations, where the netbird trayicon doesnt even start, and it connects to all exit nodes.** I'm constantly forgetting this is a thing and wondering why my connection is dropping or Im getting poor latency (compared to what I should be getting) or I am unable to reach LAN devices. Personally, I think it should be a group option. Either in a dedicated "groups" tab or in policies, I believe you should be able to configure certain groups with the following options: **Group Exit Route Options (set per exit node):** 1. Off by Default (user settings will save on reboot) 2. On by Default (user settings will save on reboot) 3. Force On (exit nodes are forced on) This would allow a few things. First, it resolves the issues we're facing that means we have to customize netbird's local config on every boot. Second, it still allows us to set it as default if we want to, in an easy and scallable way (we can quickly change for all members of a group, quickly add clients to an exit node with a group). Third, it still allows powerful combinations and customization that netbird excells with.
saavagebueno commented 2025-11-20 05:21:52 -05:00
Author
Owner
Copy Link

@HappyShr00m commented on GitHub (Jul 2, 2024):

I am using VyOS as router and been trying to use netbird with it and having a cloud exit node on a virtualized VyOS instance, however, been having all sorts of issues. For example, on a client VyOS router connected to an exit node, the speeds are extremely slow (2Mbps) compared to 600Mbps if client is installed on a normal debian server. I think, on the client side, there should be an option to provide the routing automatically or leave it for the end user to choose which interface / addresses to route through the exit node. basically I would like netbird to have the ability to be least intrusive on a system where the use can specify how routing is done for more advanced use cases.

this will make netbird much more customizable and less intrusive on a system that is already managing routing and firewall (specifically in this case is vyos. and I would say this also applies to opnsense, pfsense and so on.

also, regarding the speeds, I'm still unable to find the problem. however, i'm relatively new to netbird, but really liking it so far. so all the best and hope this gets more attention. Thanks for your great efforts and awesome software.

@HappyShr00m commented on GitHub (Jul 2, 2024): I am using VyOS as router and been trying to use netbird with it and having a cloud exit node on a virtualized VyOS instance, however, been having all sorts of issues. For example, on a client VyOS router connected to an exit node, the speeds are extremely slow (2Mbps) compared to 600Mbps if client is installed on a normal debian server. I think, on the client side, there should be an option to provide the routing automatically or leave it for the end user to choose which interface / addresses to route through the exit node. basically I would like netbird to have the ability to be least intrusive on a system where the use can specify how routing is done for more advanced use cases. this will make netbird much more customizable and less intrusive on a system that is already managing routing and firewall (specifically in this case is vyos. and I would say this also applies to opnsense, pfsense and so on. also, regarding the speeds, I'm still unable to find the problem. however, i'm relatively new to netbird, but really liking it so far. so all the best and hope this gets more attention. Thanks for your great efforts and awesome software.
saavagebueno commented 2025-11-20 05:21:52 -05:00
Author
Owner
Copy Link

@svardie commented on GitHub (Jul 3, 2024):

We recently have different issues with exit-nodes on by default. Mostly with resources in local network. So off by deafault would be preferrable. Or, as mentioned above, it should be defined from admin panel, which user group have it on by default, which is not etc.

@svardie commented on GitHub (Jul 3, 2024): We recently have different issues with exit-nodes on by default. Mostly with resources in local network. So off by deafault would be preferrable. Or, as mentioned above, it should be defined from admin panel, which user group have it on by default, which is not etc.
saavagebueno commented 2025-11-20 05:21:52 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jul 10, 2024):

Thank you, folks, for your feedback on whether exit node routes should be applied by default.

We understand the mixed opinions but recognize the need for flexibility and control. The main point that we got is that we shouldn't enable it by default but instead offer an option to force it to be enabled for specific groups.

That said, our plan is to not enable this feature by default, allowing users to configure it through the admin panel by either applying it as a setting to groups or at the route configuration level. It will depend on our UX work, but hopefully, we will achieve a good option.

Your input on ensuring connection stability and managing local network resources is invaluable and will guide our implementation strategy in the coming releases.

I am closing the RFC now, but feel free to respond to it.

@mlsmaycon commented on GitHub (Jul 10, 2024): Thank you, folks, for your feedback on whether exit node routes should be applied by default. We understand the mixed opinions but recognize the need for flexibility and control. The main point that we got is that we shouldn't enable it by default but instead offer an option to force it to be enabled for specific groups. That said, our plan is to not enable this feature by default, allowing users to configure it through the admin panel by either applying it as a setting to groups or at the route configuration level. It will depend on our UX work, but hopefully, we will achieve a good option. Your input on ensuring connection stability and managing local network resources is invaluable and will guide our implementation strategy in the coming releases. I am closing the RFC now, but feel free to respond to it.
saavagebueno commented 2025-11-20 05:21:52 -05:00
Author
Owner
Copy Link

@svardie commented on GitHub (Oct 3, 2024):

@mlsmaycon Hello. Any news on this feauture?

@svardie commented on GitHub (Oct 3, 2024): @mlsmaycon Hello. Any news on this feauture?
saavagebueno commented 2025-11-20 05:21:53 -05:00
Author
Owner
Copy Link

@florian-obradovic commented on GitHub (Nov 25, 2024):

+1

@florian-obradovic commented on GitHub (Nov 25, 2024): +1
saavagebueno commented 2025-11-20 05:21:53 -05:00
Author
Owner
Copy Link

@Mntz commented on GitHub (Dec 4, 2024):

Optional Exit Nodes would be great! Hope this gets added soon.

@Mntz commented on GitHub (Dec 4, 2024): Optional Exit Nodes would be great! Hope this gets added soon.
saavagebueno commented 2025-11-20 05:21:53 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Dec 4, 2024):

An update about the change. We've just released the first step towards what was discussed here.

With 0.34.0 your route selection will be persistent across daemon restarts or upgrades.

Soon, we will work on adding support to optional exit nodes with an override option configured in the management console.

@mlsmaycon commented on GitHub (Dec 4, 2024): An update about the change. We've just released the first step towards what was discussed here. With 0.34.0 your route selection will be persistent across daemon restarts or upgrades. Soon, we will work on adding support to optional exit nodes with an override option configured in the management console.
saavagebueno commented 2025-11-20 05:21:53 -05:00
Author
Owner
Copy Link

@jamie-dit commented on GitHub (Jan 15, 2025):

Great to hear @mlsmaycon Is there an updated PR for optional exit nodes?

Thanks

@jamie-dit commented on GitHub (Jan 15, 2025): Great to hear @mlsmaycon Is there an updated PR for optional exit nodes? Thanks
saavagebueno commented 2025-11-20 05:21:53 -05:00
Author
Owner
Copy Link

@xryceu commented on GitHub (May 10, 2025):

Hello everyone, are there any updates on this topic? Maybe a planned release date or something like that?

@xryceu commented on GitHub (May 10, 2025): Hello everyone, are there any updates on this topic? Maybe a planned release date or something like that?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label rfc
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#1017
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?