VPN on-demant activation for mobile clients #759

Open
opened 2025-11-20 05:17:03 -05:00 by saavagebueno · 3 comments
Owner

Originally created by @pax0707 on GitHub (Apr 1, 2024).

Is your feature request related to a problem? Please describe.
Prevent activation of VPN while connected to the local environment.

Describe the solution you'd like
Implement on-demand VPN activation with the option to exclude WiFi networks at locations that Netbird clients already cover to prevent unnecessary network overhead.

Describe alternatives you've considered
Manually enabling/disabling the VPN is tiresome, especially for other, less technically inclined users.

Additional context
Wireguard client (and some other wireguard-based solutions) already support this option.

Originally created by @pax0707 on GitHub (Apr 1, 2024). **Is your feature request related to a problem? Please describe.** Prevent activation of VPN while connected to the local environment. **Describe the solution you'd like** Implement on-demand VPN activation with the option to exclude WiFi networks at locations that Netbird clients already cover to prevent unnecessary network overhead. **Describe alternatives you've considered** Manually enabling/disabling the VPN is tiresome, especially for other, less technically inclined users. **Additional context** Wireguard client (and some other wireguard-based solutions) already support this option.
saavagebueno added the feature-request label 2025-11-20 05:17:03 -05:00
Author
Owner

@braginini commented on GitHub (Apr 1, 2024):

Hi @pax0707
What kind of network overhead are you experiencing?
Do you use network routes feature?

@braginini commented on GitHub (Apr 1, 2024): Hi @pax0707 What kind of network overhead are you experiencing? Do you use network routes feature?
Author
Owner

@aho-amiblu commented on GitHub (Apr 16, 2024):

Hi, if I may add a comment here:
In our corporate network we have a ton of subnets that is routed quite efficiently via the local "default gateway".
If we deploy routes via the "network routes" feature, they will always be prefered, so all the traffic is running via that routing peer, instead of the (more efficent) direct way.
So it would be nice if those network routes are only active if they cannot be reached directly.

@aho-amiblu commented on GitHub (Apr 16, 2024): Hi, if I may add a comment here: In our corporate network we have a ton of subnets that is routed quite efficiently via the local "default gateway". If we deploy routes via the "network routes" feature, they will always be prefered, so all the traffic is running via that routing peer, instead of the (more efficent) direct way. So it would be nice if those network routes are only active if they cannot be reached directly.
Author
Owner

@braginini commented on GitHub (Apr 17, 2024):

Hi, if I may add a comment here: In our corporate network we have a ton of subnets that is routed quite efficiently via the local "default gateway". If we deploy routes via the "network routes" feature, they will always be prefered, so all the traffic is running via that routing peer, instead of the (more efficent) direct way. So it would be nice if those network routes are only active if they cannot be reached directly.

Thank you for sharing your case @aho-amiblu.
You might be able to achieve the suggested behaviour by using posture checks. You can create one that is blocking access when peer is connected to a specific network (peer network range check) and add it to a policy that allows access to your routing peers. Once the client is in the network with more efficient routes, the posture check will remove access to that routing peer and therefore the NetBird route.

@braginini commented on GitHub (Apr 17, 2024): > Hi, if I may add a comment here: In our corporate network we have a ton of subnets that is routed quite efficiently via the local "default gateway". If we deploy routes via the "network routes" feature, they will always be prefered, so all the traffic is running via that routing peer, instead of the (more efficent) direct way. So it would be nice if those network routes are only active if they cannot be reached directly. Thank you for sharing your case @aho-amiblu. You might be able to achieve the suggested behaviour by using posture checks. You can create one that is blocking access when peer is connected to a specific network (peer network range check) and add it to a policy that allows access to your routing peers. Once the client is in the network with more efficient routes, the posture check will remove access to that routing peer and therefore the NetBird route.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#759