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

[mlsmaycon]

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.

[mlsmaycon]

We will close this RFC on July 1st.

[Zaunei]

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:

[Yxnt]

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).

[svardie]

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.

[otaconix]

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.

[W1BTR]

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.

[HappyShr00m]

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.

[svardie]

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.

[mlsmaycon]

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.

[svardie]

@mlsmaycon Hello. Any news on this feauture?

[florian-obradovic]

+1

[Mntz]

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

[mlsmaycon]

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.

[jamie-dit]

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

Thanks

[xryceu]

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