[GH-ISSUE #4471] Client Reauthentication After token expiration is not smooth and seamless. #9189

Open
opened 2026-08-05 01:21:12 -04:00 by saavagebueno · 5 comments
Owner

Originally created by @anshumanFPII on GitHub (Sep 9, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4471

Describe the problem
When the NetBird client token expires, the re-authentication popup on Windows and macOS is unreliable and often does not appear at all. This confuses end-users, requiring IT support assistance to manually re-authenticate them. The process should be seamless and predictable. On Linux, there is also no straightforward prompt to re-authenticate via CLI, which complicates the user experience.

To Reproduce
Steps to reproduce the behavior:

  1. Install and run NetBird client (Windows/macOS/Linux).
  2. Let the client token expire (e.g., after inactivity or token lifetime).
  3. Observe that the expected re-authentication popup often does not show (Windows/macOS).
  4. On Linux, there is no clear CLI-driven re-authentication prompt.
  5. User remains disconnected until manual IT intervention.

Expected behavior

  • On Windows/macOS: A reliable popup should always appear when re-authentication is required, automatically opening the default browser for login.
  • On Linux: A clear CLI prompt should guide the user through re-authentication.
  • Overall: The re-authentication process should be seamless and user-friendly without IT support dependency.

Are you using NetBird Cloud?
Self-hosted NetBird control plane.

NetBird version
0.56.1

Is any other VPN software installed?
No.

Screenshots
N/A (popups often do not appear).

Additional context
This is a usability issue that leads to confusion among non-technical users. Making re-authentication seamless will significantly improve adoption and reduce IT support overhead.

Have you tried these troubleshooting steps?


Feature request 1: Reliable re-authentication flow

Introduce a reliable, cross-platform re-authentication mechanism:

  • On Windows/macOS → Always trigger a popup that launches the default browser for login when a token expires.
  • On Linux → Provide a clear CLI prompt or command to re-authenticate seamlessly.
  • Ensure the process is consistent, predictable, and user-friendly to minimize IT support intervention.

Feature request 2: Auto-update support for self-hosted setups

Add a mechanism for automatic updates:

  • Server-side: Provide an option for self-hosted control plane components (management, signal, dashboard, etc.) to auto-update or notify admins when an update is available.
  • Client-side: Enable auto-update (with optional admin control) for NetBird clients running on Windows, macOS, and Linux.
  • This ensures users and servers are always running the latest, most secure, and compatible versions without manual intervention.
Originally created by @anshumanFPII on GitHub (Sep 9, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4471 **Describe the problem** When the NetBird client token expires, the re-authentication popup on Windows and macOS is unreliable and often does not appear at all. This confuses end-users, requiring IT support assistance to manually re-authenticate them. The process should be seamless and predictable. On Linux, there is also no straightforward prompt to re-authenticate via CLI, which complicates the user experience. **To Reproduce** Steps to reproduce the behavior: 1. Install and run NetBird client (Windows/macOS/Linux). 2. Let the client token expire (e.g., after inactivity or token lifetime). 3. Observe that the expected re-authentication popup often does not show (Windows/macOS). 4. On Linux, there is no clear CLI-driven re-authentication prompt. 5. User remains disconnected until manual IT intervention. **Expected behavior** * On Windows/macOS: A reliable popup should *always* appear when re-authentication is required, automatically opening the default browser for login. * On Linux: A clear CLI prompt should guide the user through re-authentication. * Overall: The re-authentication process should be seamless and user-friendly without IT support dependency. **Are you using NetBird Cloud?** Self-hosted NetBird control plane. **NetBird version** `0.56.1` **Is any other VPN software installed?** *No*. **Screenshots** N/A (popups often do not appear). **Additional context** This is a usability issue that leads to confusion among non-technical users. Making re-authentication seamless will significantly improve adoption and reduce IT support overhead. **Have you tried these troubleshooting steps?** * [x] Reviewed [[client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client)](https://docs.netbird.io/how-to/troubleshooting-client) * [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 --- ### Feature request 1: Reliable re-authentication flow Introduce a reliable, cross-platform re-authentication mechanism: * On Windows/macOS → Always trigger a popup that launches the default browser for login when a token expires. * On Linux → Provide a clear CLI prompt or command to re-authenticate seamlessly. * Ensure the process is consistent, predictable, and user-friendly to minimize IT support intervention. ### Feature request 2: Auto-update support for self-hosted setups Add a mechanism for automatic updates: * **Server-side:** Provide an option for self-hosted control plane components (management, signal, dashboard, etc.) to auto-update or notify admins when an update is available. * **Client-side:** Enable auto-update (with optional admin control) for NetBird clients running on Windows, macOS, and Linux. * This ensures users and servers are always running the latest, most secure, and compatible versions without manual intervention.
saavagebueno added the triage-needed label 2026-08-05 01:21:12 -04:00
Author
Owner

@1nerdyguy commented on GitHub (Sep 9, 2025):

The auto-update is a work in process that's been announced, but no release date. I'm not a huge fan of it, personally, and prefer to update packages through a system dedicated to doing just that vs otherwise, but that's just me.

<!-- gh-comment-id:3270658180 --> @1nerdyguy commented on GitHub (Sep 9, 2025): The auto-update is a work in process that's been announced, but no release date. I'm not a huge fan of it, personally, and prefer to update packages through a system dedicated to doing just that vs otherwise, but that's just me.
Author
Owner

@anshumanFPII commented on GitHub (Sep 9, 2025):

@1nerdyguy Thanks for clarifying and I understand your perspective about preferring updates through a package manager or a dedicated system — that definitely makes sense for production environments where admins need tight control.

At the same time, in self-hosted scenarios with many non-technical users, relying only on manual or package-manager updates can quickly become a support burden. A lot of end-users never touch package managers, and IT ends up fielding “why isn’t my client working?” tickets simply because they’re on an outdated build.

I think the best middle ground would be to make an auto-update:

  • Optional / opt-in: disabled by default so that administrators who prefer controlled package updates can keep their workflow unchanged.
  • Configurable: something like an auto_update = true/false in the client and server configs (or a CLI flag).
  • Secure & verifiable: only pulling signed, verified releases.
  • Flexible: still publishing via package managers (apt/yum, Homebrew, Chocolatey, winget, etc.) for those who prefer the traditional approach.

This way both worlds are covered:

  • Admins who want full control keep using package managers and ignore the built-in updater.
  • Teams that need a “set it and forget it” client for non-technical end-users can enable auto-update and reduce IT support overhead.

So rather than replacing the package-manager flow, auto-update would just be an additional, opt-in convenience layer. That balance could make everyone happy while still improving usability for less technical setups.

<!-- gh-comment-id:3270710540 --> @anshumanFPII commented on GitHub (Sep 9, 2025): @1nerdyguy Thanks for clarifying and I understand your perspective about preferring updates through a package manager or a dedicated system — that definitely makes sense for production environments where admins need tight control. At the same time, in self-hosted scenarios with many non-technical users, relying only on manual or package-manager updates can quickly become a support burden. A lot of end-users never touch package managers, and IT ends up fielding “why isn’t my client working?” tickets simply because they’re on an outdated build. I think the best middle ground would be to make an auto-update: * **Optional / opt-in**: disabled by default so that administrators who prefer controlled package updates can keep their workflow unchanged. * **Configurable**: something like an `auto_update = true/false` in the client and server configs (or a CLI flag). * **Secure & verifiable**: only pulling signed, verified releases. * **Flexible**: still publishing via package managers (apt/yum, Homebrew, Chocolatey, winget, etc.) for those who prefer the traditional approach. This way both worlds are covered: * Admins who want full control keep using package managers and ignore the built-in updater. * Teams that need a “set it and forget it” client for non-technical end-users can enable auto-update and reduce IT support overhead. So rather than replacing the package-manager flow, auto-update would just be an additional, opt-in convenience layer. That balance could make everyone happy while still improving usability for less technical setups.
Author
Owner

@anshumanFPII commented on GitHub (Nov 5, 2025):

any updates?

<!-- gh-comment-id:3493360386 --> @anshumanFPII commented on GitHub (Nov 5, 2025): any updates?
Author
Owner

@cphinxxx commented on GitHub (Mar 23, 2026):

We are an MSP using NetBird with Microsoft Entra ID SSO and peer login expiration enabled.

We are having the same issue: when the session expires, end users receive no (reliably) visible notification as mentioned in this post and NetBird simply remains disconnected. This causes confusion and increased helpdesk tickets because users believe they are still connected.

We would strongly benefit from a reliable, enforced re-authentication popup or system notification when login is required — especially on Windows.

This is critical for usability in managed environments.

<!-- gh-comment-id:4114835977 --> @cphinxxx commented on GitHub (Mar 23, 2026): We are an MSP using NetBird with Microsoft Entra ID SSO and peer login expiration enabled. We are having the same issue: when the session expires, end users receive no (reliably) visible notification as mentioned in this post and NetBird simply remains disconnected. This causes confusion and increased helpdesk tickets because users believe they are still connected. We would strongly benefit from a reliable, enforced re-authentication popup or system notification when login is required — especially on Windows. This is critical for usability in managed environments.
Author
Owner

@qq-i commented on GitHub (Apr 17, 2026):

+1 This often drops the connection for me (and my users) in the middle of the workday. It would be great if at least a popup would happen BEFORE it drops your connection (with a countdown maybe) so users have a chance to re-authenticate.
Other solutions for this disruptive behavior are also welcome. Fast resolution would be very much appreciated.

<!-- gh-comment-id:4266184850 --> @qq-i commented on GitHub (Apr 17, 2026): +1 This often drops the connection for me (and my users) in the middle of the workday. It would be great if at least a popup would happen BEFORE it drops your connection (with a countdown maybe) so users have a chance to re-authenticate. Other solutions for this disruptive behavior are also welcome. Fast resolution would be very much appreciated.
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#9189