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

Reuse network adapter profile on Windows instead of bloating the registry #674

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

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

Is your feature request related to a problem? Please describe.
Currently, netbird on Windows always creates a new network adapter and corresponding network profile when the application starts/restarts. This causes a new network profile to be created in the Windows registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles). After a few restarts, the registry is quickly bloated with leftover profiles, which is not only wasteful but also visually ugly - in the Windows Network Center, the profile shows up with duplicate names like "wt0 (8)" because Windows renames duplicate profiles automatically.

This also prevents network administrators from configuring the interface: Common issues revolve around setting the interface to private (this gets reset by the creation of a new profile) and customizing local firewalls (especially of third party vendors - those are sometimes entirely based on network profiles).

Describe the solution you'd like
Netbird should reuse an existing network profile when creating the TUN device. This appears to be (almost) trivially possible by changing:

index 900e62f..4dac66f 100644
--- a/iface/tun_windows.go
+++ b/iface/tun_windows.go
@@ -41,7 +41,7 @@ func newTunDevice(name string, address WGAddress, port int, key string, mtu int,
 }
 
 func (t *tunDevice) Create() (wgConfigurer, error) {
-	tunDevice, err := tun.CreateTUN(t.name, t.mtu)
+	tunDevice, err := tun.CreateTUNWithRequestedGUID(t.name, &myGUID, t.mtu)
 	if err != nil {
 		return nil, err
 	}

17f5abc653/iface/tun_windows.go (L44C24-L44C33)

This causes wireguard to reuse an existing profile if one with such a GUID exists. The GUID should be deterministic across restarts, possibly generated from the client's public key?

Describe alternatives you've considered
There aren't really any alternatives except accepting this problem or not using Netbird.

Additional context
I'm new to go, so I'm not entirely confident with submitting a PR myself right now. Are you interested in a PR for this?

Originally created by @GermanCoding on GitHub (Mar 3, 2024). **Is your feature request related to a problem? Please describe.** Currently, netbird on Windows always creates a new network adapter and corresponding network profile when the application starts/restarts. This causes a new network profile to be created in the Windows registry (`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles`). After a few restarts, the registry is quickly bloated with leftover profiles, which is not only wasteful but also visually ugly - in the Windows Network Center, the profile shows up with duplicate names like "wt0 (8)" because Windows renames duplicate profiles automatically. This also prevents network administrators from configuring the interface: Common issues revolve around setting the interface to private (this gets reset by the creation of a new profile) and customizing local firewalls (especially of third party vendors - those are sometimes entirely based on network profiles). **Describe the solution you'd like** Netbird should reuse an existing network profile when creating the TUN device. This appears to be (almost) trivially possible by changing: ```diff --git a/iface/tun_windows.go b/iface/tun_windows.go index 900e62f..4dac66f 100644 --- a/iface/tun_windows.go +++ b/iface/tun_windows.go @@ -41,7 +41,7 @@ func newTunDevice(name string, address WGAddress, port int, key string, mtu int, } func (t *tunDevice) Create() (wgConfigurer, error) { - tunDevice, err := tun.CreateTUN(t.name, t.mtu) + tunDevice, err := tun.CreateTUNWithRequestedGUID(t.name, &myGUID, t.mtu) if err != nil { return nil, err } ``` https://github.com/netbirdio/netbird/blob/17f5abc6537c79fb36f4afc7c74b7670108123be/iface/tun_windows.go#L44C24-L44C33 This causes wireguard to reuse an existing profile if one with such a GUID exists. The GUID should be deterministic across restarts, possibly generated from the client's public key? **Describe alternatives you've considered** There aren't really any alternatives except accepting this problem or not using Netbird. **Additional context** I'm new to go, so I'm not entirely confident with submitting a PR myself right now. Are you interested in a PR for this?
saavagebueno added the feature-request label 2025-11-20 05:15:48 -05:00
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@VMax4 commented on GitHub (Apr 3, 2024):

I add that all this happen for sure on Windows 8 and Windows11 for my experience but i suppose that happen to Windows 10 and so on too, but, sure it happen on Ubuntu 22.04 LTS too, where on each reboot a new wt0 is generated and to connect you must delete all the wt0 except for one and then disconnect and then reconnect it, a big bug, hope all this will be fixed soon.
Also, if for a peer (i saw this in Widows 11) login expiration is enabled, then, when it is expired the netbird ui come uninstalled from the system too with no reason i suppose... so to relogin you have to reinstall netbird again

@VMax4 commented on GitHub (Apr 3, 2024): I add that all this happen for sure on Windows 8 and Windows11 for my experience but i suppose that happen to Windows 10 and so on too, but, sure it happen on Ubuntu 22.04 LTS too, where on each reboot a new wt0 is generated and to connect you must delete all the wt0 except for one and then disconnect and then reconnect it, a big bug, hope all this will be fixed soon. Also, if for a peer (i saw this in Widows 11) login expiration is enabled, then, when it is expired the netbird ui come uninstalled from the system too with no reason i suppose... so to relogin you have to reinstall netbird again
saavagebueno commented 2025-11-20 05:15:49 -05:00
Author
Owner
Copy Link

@Svetloslav commented on GitHub (Aug 23, 2024):

This issue is wrongly filed under "feature request". It is not! It is a huge, longstanding bug. You can see it brilliantly resolved in Tailscale. Sad!

@Svetloslav commented on GitHub (Aug 23, 2024): This issue is wrongly filed under "feature request". It is not! It is a huge, longstanding bug. You can see it brilliantly resolved in Tailscale. Sad!
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#674
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?