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

Be able to deploy NetBird under System Account as Always-On-VPN #673

New Issue
Open
opened 2025-11-20 05:15:48 -05:00 by saavagebueno · 18 comments
saavagebueno commented 2025-11-20 05:15:48 -05:00
Owner
Copy Link

Originally created by @PowershellScripter on GitHub (Mar 3, 2024).

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Being able to utilize NetBird as an Always On VPN that can be installed and ran under the MACHINE context.
This means, being able to install the netbird client as the 'SYSTEM' account under windows and have it run the service as that account.

Describe alternatives you've considered
We have tried to use Tailscale under the same context, running the VPN unattended as SYSTEM and Tailscale doesnt have this ability as it never creates the server mode key under the system context. Alot of crafty manipulation of task schedules and scripts had to be done to get it working somewhat as needed.
Itd be nice to have NetBird (a vpn solution that runs under true kernel level Wireguard) be able to run as the system account.

Additional context
This is insanely beneficial for massive scale deployments where companies want to push the vpn out to all their systems and have the ability to setup the VPN without user interaction / userprofile dependency.
Also makes it useful to be able to build custom windows images that get deployed in different states / countries and build the images to be able to connect to the VPN as the system account to join to the companies domain as well as reconnect at boot to be able to pull domain configs etc.

Originally created by @PowershellScripter on GitHub (Mar 3, 2024). **Is your feature request related to a problem? Please describe.** No. **Describe the solution you'd like** Being able to utilize NetBird as an Always On VPN that can be installed and ran under the MACHINE context. This means, being able to install the netbird client as the 'SYSTEM' account under windows and have it run the service as that account. **Describe alternatives you've considered** We have tried to use Tailscale under the same context, running the VPN unattended as SYSTEM and Tailscale doesnt have this ability as it never creates the server mode key under the system context. Alot of crafty manipulation of task schedules and scripts had to be done to get it working somewhat as needed. Itd be nice to have NetBird (a vpn solution that runs under true kernel level Wireguard) be able to run as the system account. **Additional context** This is insanely beneficial for massive scale deployments where companies want to push the vpn out to all their systems and have the ability to setup the VPN without user interaction / userprofile dependency. Also makes it useful to be able to build custom windows images that get deployed in different states / countries and build the images to be able to connect to the VPN as the system account to join to the companies domain as well as reconnect at boot to be able to pull domain configs etc.
saavagebueno added the feature-request label 2025-11-20 05:15:48 -05:00
saavagebueno commented 2025-11-20 05:15:48 -05:00
Author
Owner
Copy Link

@SinghNanak commented on GitHub (Mar 5, 2024):

+1

@SinghNanak commented on GitHub (Mar 5, 2024): +1
saavagebueno commented 2025-11-20 05:15:48 -05:00
Author
Owner
Copy Link

@kjentech commented on GitHub (Apr 16, 2024):

This would be hugely beneficial to everyone who's still very on-prem heavy, but want a more modern enterprise VPN. The case for Always-On VPN is often regulated industries or government, or just enterprises with a large network-IDS infrastructure in place.

As an example, the Danish government has a compliance framework for all government institutions that, among other things, require:

  • VPN on all client endpoints, no matter the OS
  • Deployed in Always-On Mode
  • In a force-tunnel configuration
  • With all connections denied if not connected to the VPN
  • With a loophole that allows traffic to HTTP (tcp/80) and HTTPS (tcp/443) for a limited time at the request of the logged in user to log in to any guest wifi captive portals.

That specific requirement was written with Cisco in mind, as it's the most widely used VPN provider in the Danish government. But it would be super sweet if we could break free from Cisco, as we already have experience with plain Wireguard between servers. Running Wireguard as a service as SYSTEM is a good first step.

@kjentech commented on GitHub (Apr 16, 2024): This would be hugely beneficial to everyone who's still very on-prem heavy, but want a more modern enterprise VPN. The case for Always-On VPN is often regulated industries or government, or just enterprises with a large network-IDS infrastructure in place. As an example, the Danish government has a compliance framework for all government institutions that, among other things, require: - VPN on all client endpoints, no matter the OS - Deployed in Always-On Mode - In a force-tunnel configuration - With all connections denied if not connected to the VPN - With a loophole that allows traffic to HTTP (tcp/80) and HTTPS (tcp/443) for a limited time at the request of the logged in user to log in to any guest wifi captive portals. That specific requirement was written with Cisco in mind, as it's the most widely used VPN provider in the Danish government. But it would be super sweet if we could break free from Cisco, as we already have experience with plain Wireguard between servers. Running Wireguard as a service as SYSTEM is a good first step.
saavagebueno commented 2025-11-20 05:15:48 -05:00
Author
Owner
Copy Link

@PowershellScripter commented on GitHub (May 14, 2024):

Is there any update on if this is possible to do yet or if it will be implemented or not?

@PowershellScripter commented on GitHub (May 14, 2024): Is there any update on if this is possible to do yet or if it will be implemented or not?
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@PowershellScripter commented on GitHub (Aug 24, 2024):

Possible there will be an AlwaysOn VPN option that can be installed and connected at the MACHINE level rather than user?

@PowershellScripter commented on GitHub (Aug 24, 2024): Possible there will be an AlwaysOn VPN option that can be installed and connected at the MACHINE level rather than user?
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@PowershellScripter commented on GitHub (Sep 25, 2024):

Is this something that has been implemented yet or is on the roadmap to be possible?

@PowershellScripter commented on GitHub (Sep 25, 2024): Is this something that has been implemented yet or is on the roadmap to be possible?
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@serossi commented on GitHub (Dec 30, 2024):

when we are at it, also consider the ability to exclude certain ipranges so the client only runs/connects when not within these ranges and dont propagate routes
or else mayham waiting when in local lan

@serossi commented on GitHub (Dec 30, 2024): when we are at it, also consider the ability to exclude certain ipranges so the client only runs/connects when not within these ranges and dont propagate routes or else mayham waiting when in local lan
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@mbaybarsk commented on GitHub (Dec 30, 2024):

@serossi A tunnel within the LAN isn't necessarily mayhem.

@mbaybarsk commented on GitHub (Dec 30, 2024): @serossi A tunnel within the LAN isn't necessarily mayhem.
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@serossi commented on GitHub (Dec 30, 2024):

@mbaybarsk it almost always is and not the right way todo things. thats what 802.1x is for.
which may not even work if you have routes set to wireguard that should go to lan to even authenticate ...
in any case if you warelly want to you need to plan for it and implement it right which oftne isnt possible
so that override/exclusion is a must have for a always on vpn

btw all big vpns have that options, even microsoft ras (shudder) has that option

@serossi commented on GitHub (Dec 30, 2024): @mbaybarsk it almost always is and not the right way todo things. thats what 802.1x is for. which may not even work if you have routes set to wireguard that should go to lan to even authenticate ... in any case if you warelly want to you need to plan for it and implement it right which oftne isnt possible so that override/exclusion is a must have for a always on vpn btw all big vpns have that options, even microsoft ras (shudder) has that option
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@osos commented on GitHub (Mar 23, 2025):

any ETA on this feature. It seems doable on Linux.
We need a system-wide start-on-power-on Netbird service.
We are currently using zerotier, which is able to this. The remaining reason to stay with Zerotier.

@osos commented on GitHub (Mar 23, 2025): any ETA on this feature. It seems doable on Linux. We need a system-wide start-on-power-on Netbird service. We are currently using zerotier, which is able to this. The remaining reason to stay with Zerotier.
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Mar 24, 2025):

FYI: Netbird already runs as an operating-system-wide service which gets started during the boot process.

It cannot be qualified as Always-on-VPN for compliance fulfillment in terms of:

  • preventing internet access until the VPN is running,
  • preventing connections from leaking outside the VPN,

but otherwise already works in terms of:

  • surviving reboots,
  • starting the client before the user logs in (by default it runs as root or Administrator),
  • possibility to run on a pre-baked operating system image,

Personally I am already making good use of the last point by carrying a customized NixOS install-iso on a USB drive with me:

  • it is a read-only image,
  • The ISO holds an ephemeral Setup Key (which doesn't have access to anything, but is accessible from selected Peers),
  • the Setup Key is encoded as a sops secret decryptable with a specific set of YubiKeys (using age-plugin-yubikey),
  • I also carry the required Yubikey with me,
@nazarewk commented on GitHub (Mar 24, 2025): FYI: Netbird already runs as an operating-system-wide service which gets started during the boot process. It cannot be qualified as Always-on-VPN for compliance fulfillment in terms of: - preventing internet access until the VPN is running, - preventing connections from leaking outside the VPN, but otherwise already works in terms of: - surviving reboots, - starting the client before the user logs in (by default it runs as `root` or `Administrator`), - possibility to run on a pre-baked operating system image, Personally I am already making good use of the last point by carrying a customized NixOS install-iso on a USB drive with me: - it is a read-only image, - The ISO holds an ephemeral Setup Key (which doesn't have access to anything, but is accessible from selected Peers), - the Setup Key is encoded as a `sops` secret decryptable with a specific set of YubiKeys (using `age-plugin-yubikey`), - I also carry the required Yubikey with me,
saavagebueno commented 2025-11-20 05:15:50 -05:00
Author
Owner
Copy Link

@PowershellScripter commented on GitHub (Apr 8, 2025):

FYI: Netbird already runs as an operating-system-wide service which gets started during the boot process.

It cannot be qualified as Always-on-VPN for compliance fulfillment in terms of:

  • preventing internet access until the VPN is running,
  • preventing connections from leaking outside the VPN,

but otherwise already works in terms of:

  • surviving reboots,
  • starting the client before the user logs in (by default it runs as root or Administrator),
  • possibility to run on a pre-baked operating system image,

Personally I am already making good use of the last point by carrying a customized NixOS install-iso on a USB drive with me:

  • it is a read-only image,
  • The ISO holds an ephemeral Setup Key (which doesn't have access to anything, but is accessible from selected Peers),
  • the Setup Key is encoded as a sops secret decryptable with a specific set of YubiKeys (using age-plugin-yubikey),
  • I also carry the required Yubikey with me,

The ideal is to be able to setup and initiate the VPN without an actual user account (ex. Windows "SYSTEM" account)

With tailscale, you CANNOT authenticate the vpn (with an auth key) using the SYSTEM account as it never creates the 'sever key' in the config file, causing the vpn to not survive a reboot. But, if you use the auth key with a user account, it will register the 'server key' in the config and tie it to that user account, at which point the --unattended switch will survive reboots, even if the user becomes disabled.

This made it to where we had to setup 2 scheduled tasks (one under system, the second under 'built-in' users) for automation purposes

The original curiosity question is if we can force the connection using an auth key using the windows system account and it survive reboots?

@PowershellScripter commented on GitHub (Apr 8, 2025): > FYI: Netbird already runs as an operating-system-wide service which gets started during the boot process. > > It cannot be qualified as Always-on-VPN for compliance fulfillment in terms of: > > * preventing internet access until the VPN is running, > * preventing connections from leaking outside the VPN, > > but otherwise already works in terms of: > > * surviving reboots, > * starting the client before the user logs in (by default it runs as `root` or `Administrator`), > * possibility to run on a pre-baked operating system image, > > Personally I am already making good use of the last point by carrying a customized NixOS install-iso on a USB drive with me: > > * it is a read-only image, > * The ISO holds an ephemeral Setup Key (which doesn't have access to anything, but is accessible from selected Peers), > * the Setup Key is encoded as a `sops` secret decryptable with a specific set of YubiKeys (using `age-plugin-yubikey`), > * I also carry the required Yubikey with me, The ideal is to be able to setup and initiate the VPN without an actual user account (ex. Windows "SYSTEM" account) With tailscale, you CANNOT authenticate the vpn (with an auth key) using the SYSTEM account as it never creates the 'sever key' in the config file, causing the vpn to not survive a reboot. But, if you use the auth key with a user account, it will register the 'server key' in the config and tie it to that user account, at which point the --unattended switch will survive reboots, even if the user becomes disabled. This made it to where we had to setup 2 scheduled tasks (one under system, the second under 'built-in' users) for automation purposes The original curiosity question is if we can force the connection using an auth key using the windows system account and it survive reboots?
saavagebueno commented 2025-11-20 05:15:50 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Apr 8, 2025):

I don't fully understand what are the "system account" and "server key" concepts, but the way NetBird works I see no reasons for it not to work with Setup Keys (Netbird concept) and why it wouldn't persist the configuration across reboots (it stores everything in C:\ProgramData\netbird\config.json).

The service is already running as a system-wide service, and the Setup Key itself is not tied to any specific user account (be it Windows or Netbird user account), so you should be fine.

@nazarewk commented on GitHub (Apr 8, 2025): I don't fully understand what are the "system account" and "server key" concepts, but the way NetBird works I see no reasons for it not to work with Setup Keys (Netbird concept) and why it wouldn't persist the configuration across reboots (it stores everything in `C:\ProgramData\netbird\config.json`). The service is already running as a system-wide service, and the Setup Key itself is not tied to any specific user account (be it Windows or Netbird user account), so you should be fine.
saavagebueno commented 2025-11-20 05:15:50 -05:00
Author
Owner
Copy Link

@kammerdiener commented on GitHub (Jun 8, 2025):

Hey @nazarewk -- Your response is encouraging to things. Reading through this thread and looking at Netbird there is a specific set of things I am attempting to accomplish.

Ideally as I run various IT type things I think it could solve some of my problems. I am wanting to migrate the various ADs and file servers into a Datacenter. Rather than setting up a site to site I would rather just have each of the clients establish and maintain their own connection with the servers through NetBird. Traditionally this is done through an Always On VPN and the Windows computers establishing this at boot so that authentication can be done against the AD server no matter where they are (as long as they have an internet connection).

It sounds like based on what you are saying this is possible. Curious if there is a different way to install it on Windows. I can ultimately roll the package out through Group Policy or deploy it through the other management software that I use. We have a few Mac computers but those I believe can be handled through user accounts with NetBird as we don't bind them to the domain so having the VPN up at boot is a lower concern.

Curious to hear your thoughts and if I am understanding this correctly. I have been a long time TailScale user but have always felt like it is lacking the more "Enterprise" features that are necessary so this is super intriguing to me.

@kammerdiener commented on GitHub (Jun 8, 2025): Hey @nazarewk -- Your response is encouraging to things. Reading through this thread and looking at Netbird there is a specific set of things I am attempting to accomplish. Ideally as I run various IT type things I think it could solve some of my problems. I am wanting to migrate the various ADs and file servers into a Datacenter. Rather than setting up a site to site I would rather just have each of the clients establish and maintain their own connection with the servers through NetBird. Traditionally this is done through an Always On VPN and the Windows computers establishing this at boot so that authentication can be done against the AD server no matter where they are (as long as they have an internet connection). It sounds like based on what you are saying this is possible. Curious if there is a different way to install it on Windows. I can ultimately roll the package out through Group Policy or deploy it through the other management software that I use. We have a few Mac computers but those I believe can be handled through user accounts with NetBird as we don't bind them to the domain so having the VPN up at boot is a lower concern. Curious to hear your thoughts and if I am understanding this correctly. I have been a long time TailScale user but have always felt like it is lacking the more "Enterprise" features that are necessary so this is super intriguing to me.
saavagebueno commented 2025-11-20 05:15:50 -05:00
Author
Owner
Copy Link

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

It sounds like based on what you are saying this is possible. Curious if there is a different way to install it on Windows. I can ultimately roll the package out through Group Policy or deploy it through the other management software that I use. We have a few Mac computers but those I believe can be handled through user accounts with NetBird as we don't bind them to the domain so having the VPN up at boot is a lower concern.

cross-posting with some of my explanations from Slack discussion with extra comments:

kdn: we're not supporting user-level installations on any platform
kdn: they're (almost) all system-wide daemons controlled by user-scoped CLI

This might be different for Android (not sure how it runs there).

While not officially supported, the service default definitions are very simple and quite easily adjustable (as soon as you forego netbird service install step).
It is possible to customize the process (run as unprivileged user etc.) if you take enough care on Linux (see the unofficial NixOS module), probably on MacOS and Windows too, but I don't know enough about service management there to be certain.

nicolas: So but if I deployed it through group policy is there a machine key aspect that allows it to connect?
kdn: so if you're doing SSO login it's still running system-wide, but the user needs to provide credentials to finish connecting after logging in to the device

kdn: Setup Keys are meant for non-interactive logins
kdn: you set those up once, then the login is remembered throughout of lifetime of config.json file on the machine or Peer object in the API

@nazarewk commented on GitHub (Jun 11, 2025): > It sounds like based on what you are saying this is possible. Curious if there is a different way to install it on Windows. I can ultimately roll the package out through Group Policy or deploy it through the other management software that I use. We have a few Mac computers but those I believe can be handled through user accounts with NetBird as we don't bind them to the domain so having the VPN up at boot is a lower concern. cross-posting with some of my explanations from Slack discussion with extra comments: > kdn: we're not supporting user-level installations on any platform > kdn: they're (almost) all system-wide daemons controlled by user-scoped CLI This *might* be different for Android (not sure how it runs there). While not officially supported, the service default definitions are very simple and quite easily adjustable (as soon as you forego `netbird service install` step). It is possible to customize the process (run as unprivileged user etc.) if you take enough care on Linux (see [the unofficial NixOS module](https://github.com/NixOS/nixpkgs/blob/8c927f204f993e7ad6ed464898800d9e1fa6b8f1/nixos/modules/services/networking/netbird.nix)), probably on MacOS and Windows too, but I don't know enough about service management there to be certain. > nicolas: So but if I deployed it through group policy is there a machine key aspect that allows it to connect? > kdn: so if you're doing SSO login it's still running system-wide, but the user needs to provide credentials to finish connecting after logging in to the device > kdn: Setup Keys are meant for non-interactive logins > kdn: you set those up once, then the login is remembered throughout of lifetime of config.json file on the machine or Peer object in the API
saavagebueno commented 2025-11-20 05:15:50 -05:00
Author
Owner
Copy Link

@ordovice commented on GitHub (Jun 11, 2025):

Solutions such as Enclave (also wireguard based) accomplish this by registering the device via a registration key (Enclave technically runs as a system service and then there's a userspace component for login/management). When registered via device key, you can assign policy tags to the registration key and then use those tags in the policies. authentication is also allowed as a secondary set of trust requirements and you can assign the authentication as a trust requirement for the registered device and use sso groups to assign other routes/policies/peer pairs to the device.

@ordovice commented on GitHub (Jun 11, 2025): Solutions such as Enclave (also wireguard based) accomplish this by registering the device via a registration key (Enclave technically runs as a system service and then there's a userspace component for login/management). When registered via device key, you can assign policy tags to the registration key and then use those tags in the policies. authentication is also allowed as a secondary set of trust requirements and you can assign the authentication as a trust requirement for the registered device and use sso groups to assign other routes/policies/peer pairs to the device.
saavagebueno commented 2025-11-20 05:15:50 -05:00
Author
Owner
Copy Link

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

Does Enclave do anything to function as Always-On-VPN (don't allow internet access until connected to VPN)?

@nazarewk commented on GitHub (Jun 12, 2025): Does Enclave do anything to function as Always-On-VPN (don't allow internet access until connected to VPN)?
saavagebueno commented 2025-11-20 05:15:51 -05:00
Author
Owner
Copy Link

@PowershellScripter commented on GitHub (Aug 12, 2025):

I don't fully understand what are the "system account" and "server key" concepts, but the way NetBird works I see no reasons for it not to work with Setup Keys (Netbird concept) and why it wouldn't persist the configuration across reboots (it stores everything in C:\ProgramData\netbird\config.json).

The service is already running as a system-wide service, and the Setup Key itself is not tied to any specific user account (be it Windows or Netbird user account), so you should be fine.

By "system account" and "server key" concepts, I mean using a setup key to authenticate the machine via the system account itself rather than an actual user.
Windows uses a "SYSTEM" (service) account, which has root level access beyond the local Administrative account. When using Headscale, if I use a terminal shell, ran as the SYSTEM account and try to use a "Setup Key", the "server key" that usually gets registered in a Tailscale client config file (thats used to re-auth on reboot survivals) doesnt actually get created properly, causing the connection to not survive a reboot (tailscale client background service is only authorized to reconnect without user login if a "server key" is registered).

In a JSON file for the server config, when a USER profile authenticates with a setup key, the JSON looks like this

{
"_current/S-1-5-21-2446339334-2862487693-2873601763-12939": "cHJvZmlsZS1mYzBh",
..other stuff...
"server-mode-start-key": "cHJvZmlsZS1mYzBh"
}

when trying to do the same thing as the SYSTEM account, it looks like this:

{
"S-1-5-18": "cHJvZmlsZS1mYzBh",
..other stuff...
"server-mode-start-key": ""
}

because the server key never gets created when running the auth connection from a shell, it wont survive a reboot. This makes alot of extra steps as I have to create scheduled tasks that run as both the system account and builtin/users in order to make this work.

  • The SYSTEM account task creates the initial connection so I can add the windows system to our domain.
  • On reboot, it runs the SYSTEM account task again to reconnect in the background to sync group policies, then reboots after sync.
  • SYSTEM account task runs again so that it connects back to the domain network prior to user login so a domain account can actually sign in.
  • Once the user account logs in, the BUILTIN/USERS task runs that connects to the VPN one final time to register the "server key" to survive reboots from that point on.

A bunch of steps for something that should only need to be ran once and survive reboots.

Because we have mutliple locations across the US, I bake the connection scripts into a custom windows image (that each IT tech has a copy of) that does all the driver package installs, VPN connections, domain joining, group policy syncs, etc all automated (4 hours of windows imaging cut to 20 min) and the part with the most steps and multiple points of failure is the vpn because it has to be authenticated 4 times, 3 by the SYSTEM account and 1 by the user account. If I can use machine auth (background powershell script) with a setup key and it survives reboots from that point forward, that would eliminate alot of my automation steps.

I plan to setup netbird in our environment soon, so Ill be able to test this. I was just coming back to this post to clarify what I meant in my previous post, hopefully it makes more sense now.

@PowershellScripter commented on GitHub (Aug 12, 2025): > I don't fully understand what are the "system account" and "server key" concepts, but the way NetBird works I see no reasons for it not to work with Setup Keys (Netbird concept) and why it wouldn't persist the configuration across reboots (it stores everything in `C:\ProgramData\netbird\config.json`). > > The service is already running as a system-wide service, and the Setup Key itself is not tied to any specific user account (be it Windows or Netbird user account), so you should be fine. By "system account" and "server key" concepts, I mean using a setup key to authenticate the machine via the system account itself rather than an actual user. Windows uses a "SYSTEM" (service) account, which has root level access beyond the local Administrative account. When using Headscale, if I use a terminal shell, ran as the SYSTEM account and try to use a "Setup Key", the "server key" that usually gets registered in a Tailscale client config file (thats used to re-auth on reboot survivals) doesnt actually get created properly, causing the connection to not survive a reboot (tailscale client background service is only authorized to reconnect without user login if a "server key" is registered). In a JSON file for the server config, when a USER profile authenticates with a setup key, the JSON looks like this ``` { "_current/S-1-5-21-2446339334-2862487693-2873601763-12939": "cHJvZmlsZS1mYzBh", ..other stuff... "server-mode-start-key": "cHJvZmlsZS1mYzBh" } ``` when trying to do the same thing as the SYSTEM account, it looks like this: ``` { "S-1-5-18": "cHJvZmlsZS1mYzBh", ..other stuff... "server-mode-start-key": "" } ``` because the server key never gets created when running the auth connection from a shell, it wont survive a reboot. This makes alot of extra steps as I have to create scheduled tasks that run as both the system account and builtin/users in order to make this work. - The SYSTEM account task creates the initial connection so I can add the windows system to our domain. - On reboot, it runs the SYSTEM account task again to reconnect in the background to sync group policies, then reboots after sync. - SYSTEM account task runs again so that it connects back to the domain network prior to user login so a domain account can actually sign in. - Once the user account logs in, the BUILTIN/USERS task runs that connects to the VPN one final time to register the "server key" to survive reboots from that point on. A bunch of steps for something that should only need to be ran once and survive reboots. Because we have mutliple locations across the US, I bake the connection scripts into a custom windows image (that each IT tech has a copy of) that does all the driver package installs, VPN connections, domain joining, group policy syncs, etc all automated (4 hours of windows imaging cut to 20 min) and the part with the most steps and multiple points of failure is the vpn because it has to be authenticated 4 times, 3 by the SYSTEM account and 1 by the user account. If I can use machine auth (background powershell script) with a setup key and it survives reboots from that point forward, that would eliminate alot of my automation steps. I plan to setup netbird in our environment soon, so Ill be able to test this. I was just coming back to this post to clarify what I meant in my previous post, hopefully it makes more sense now.
saavagebueno commented 2025-11-20 05:15:51 -05:00
Author
Owner
Copy Link

@PowershellScripter commented on GitHub (Sep 1, 2025):

@osos @nazarewk @kammerdiener @ordovice @serossi @kjentech @SinghNanak @mbaybarsk

I was able to finally test this and verify that you can in fact install this at the SYSTEM level with a setup key and it survives reboots and doesnt register to a user profile, it submits as a "Default" profile. (This is a valid "Always On" solution)

However, the client is rather spotty with locking down the settings in the client itself. You can lock certain things down, but they still show as options in the client. Also, if you add the connection before adding the env variables, the client will crash. it crashes when trying to reconfigure the adapter.

Also, [ netbird up --interface-name=NetBirdVPN ] doesnt work. but someone else reported this for Mac, but it seems to be effecting all clients.

@PowershellScripter commented on GitHub (Sep 1, 2025): @osos @nazarewk @kammerdiener @ordovice @serossi @kjentech @SinghNanak @mbaybarsk I was able to finally test this and verify that you can in fact install this at the SYSTEM level with a setup key and it survives reboots and doesnt register to a user profile, it submits as a "Default" profile. (This is a valid "Always On" solution) However, the client is rather spotty with locking down the settings in the client itself. You can lock certain things down, but they still show as options in the client. Also, if you add the connection before adding the env variables, the client will crash. it crashes when trying to reconfigure the adapter. Also, [ netbird up --interface-name=NetBirdVPN ] doesnt work. but someone else reported this for Mac, but it seems to be effecting all clients.
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 feature-request
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#673
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?