DYNR/netbird
2
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-08-05 00:15:26 -04:00
Code Issues 23.5k Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5432] Client network map not synced after client upgrade causes unexpected disconnection #11205

New Issue
Open
opened 2026-08-05 01:28:53 -04:00 by saavagebueno · 0 comments
saavagebueno commented 2026-08-05 01:28:53 -04:00
Owner
Copy Link

Originally created by @gamerslouis on GitHub (Feb 24, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5432

Describe the problem

The client handles network map update events from the management server.
When a client detects that a remote peer’s agentVersion is different from the one stored locally, it removes and recreates the peer connection.

However, when a NetBird client is upgraded, the agentVersion change does not trigger a network map sync event. As a result, other peers may keep an outdated agentVersion in their network map for an extended period of time.
Once a sync is eventually triggered by other conditions, this mismatch causes the peer connection to be removed and recreated, leading to unexpected disconnections.

A clear and concise description of what the problem is.

To Reproduce

  1. Create two NetBird clients and connect them to each other.
  2. Upgrade client A.
  3. Add and then remove an iptables rule to temporarily disconnect client B from the management server, forcing a sync.
  4. Client B will close and recreate the connection with client A.

Expected behavior

One of the following behaviors would be acceptable:

  • A change in agentVersion should not cause peer reconnection.
  • Or, the network map should be synchronized immediately after a client upgrade so that peers have the correct agentVersion.

Are you using NetBird Cloud?

self-host NetBird control plane

NetBird version

upgrade from 0.51.2 to 0.53.0

Is any other VPN software installed?
No

Additional context

The client closes the peer connection through the following call path:

Engine.handleSync
-> Engine.updateNetworkMap
-> Engine.modifyPeers 
-> Engine.removePeer

Relevant code snippet:

func (e *Engine) modifyPeers(peersUpdate []*mgmProto.RemotePeerConfig) error {

	// first, check if peers have been modified
	var modified []*mgmProto.RemotePeerConfig
	for _, p := range peersUpdate {
                 ...
		if currentPeer.AgentVersionString() != p.AgentVersion {
			modified = append(modified, p)
			continue
		}
                 ...
       }

      	for _, p := range modified {
		err := e.removePeer(p.GetWgPubKey())
		if err != nil {
			return err
		}
	}
        ...
}

The client compares AgentVersion, and when a difference is detected, it calls removePeer.

However, after a remote peer is upgraded or restarted, no sync event is sent to other peers, because currently only the following events for peer updates trigger networkMapController.OnPeersUpdated:
• Peer IP change (UpdatePeerIP)
• Peer reconnection after expiration (MarkPeerConnected)

As a result, the outdated agentVersion remains in the network map until a sync is triggered by unrelated events, at which point the peer connection is unexpectedly recreated.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @gamerslouis on GitHub (Feb 24, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5432 **Describe the problem** The client handles network map update events from the management server. When a client detects that a remote peer’s agentVersion is different from the one stored locally, it removes and recreates the peer connection. However, when a NetBird client is upgraded, the agentVersion change **does not trigger a network map sync event**. As a result, other peers may keep an outdated agentVersion in their network map for an extended period of time. Once a sync is eventually triggered by other conditions, this mismatch causes the peer connection to be removed and recreated, leading to unexpected disconnections. A clear and concise description of what the problem is. **To Reproduce** 1. Create two NetBird clients and connect them to each other. 2. Upgrade client A. 3. Add and then remove an iptables rule to temporarily disconnect client B from the management server, forcing a sync. 4. Client B will close and recreate the connection with client A. **Expected behavior** One of the following behaviors would be acceptable: + A change in agentVersion should not cause peer reconnection. + Or, the network map should be synchronized immediately after a client upgrade so that peers have the correct agentVersion. **Are you using NetBird Cloud?** self-host NetBird control plane **NetBird version** upgrade from 0.51.2 to 0.53.0 **Is any other VPN software installed?** No **Additional context** The client closes the peer connection through the following call path: ``` Engine.handleSync -> Engine.updateNetworkMap -> Engine.modifyPeers -> Engine.removePeer ``` Relevant code snippet: ``` func (e *Engine) modifyPeers(peersUpdate []*mgmProto.RemotePeerConfig) error { // first, check if peers have been modified var modified []*mgmProto.RemotePeerConfig for _, p := range peersUpdate { ... if currentPeer.AgentVersionString() != p.AgentVersion { modified = append(modified, p) continue } ... } for _, p := range modified { err := e.removePeer(p.GetWgPubKey()) if err != nil { return err } } ... } ``` The client compares AgentVersion, and when a difference is detected, it calls removePeer. However, after a remote peer is upgraded or restarted, no sync event is sent to other peers, because currently only the following events for peer updates trigger networkMapController.OnPeersUpdated: • Peer IP change (UpdatePeerIP) • Peer reconnection after expiration (MarkPeerConnected) As a result, the outdated agentVersion remains in the network map until a sync is triggered by unrelated events, at which point the peer connection is unexpectedly recreated. **Have you tried these troubleshooting steps?** - [X] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [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
saavagebueno added the triage-needed label 2026-08-05 01:28:53 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2021 Q4
2021 Q4
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
accessibility
accessibility
accessibility
acl
acl
acl
agent
agent
agent
agent
agent
agent
Android
Android
Android
Android
Android
Android
api
api
api
authentik
authentik
authentik
automation
automation
automation
azure
azure
azure
battery-usage
battery-usage
battery-usage
bug
cache
cache
cache
client
client
client
client-ui
client-ui
client-ui
cloud
cloud
cloud
cloud-only
cloud-only
cloud-only
cloudflare
cloudflare
cloudflare
community
community
community
compatibility
compatibility
compatibility
config-idp
config-idp
config-idp
config-issue
config-issue
config-issue
connection
connection
connection
contribution
contribution
contribution
coturn
coturn
coturn
cross-vpn
cross-vpn
cross-vpn
dashboard
dashboard
dashboard
data-usage
data-usage
data-usage
distribution
distribution
distribution
dns
dns
dns
docker
docker
docker
documentation
documentation
documentation
duplicate
duplicate
duplicate
enhancement
enhancement
event-stream
event-stream
event-stream
feature-request
feature-request
feature-request
freebsd
freebsd
freebsd
getting-started
getting-started
getting-started
go
go
go
good first issue
good first issue
good first issue
gui
gui
gui
help wanted
help wanted
help wanted
home-assistant
home-assistant
home-assistant
idp
idp
idp
inconsistency
inconsistency
inconsistency
integration
integration
integration
integrations
integrations
integrations
ios
ios
ios
ipv6
ipv6
ipv6
jwt
jwt
jwt
k8s
k8s
k8s
keycloak
keycloak
keycloak
linux
linux
linux
login
login
login
macos
macos
macos
management-service
management-service
management-service
Medium
Medium
Medium
missing-docs
missing-docs
missing-docs
mobile
mobile
mobile
moved-internal
moved-internal
moved-internal
needs-review
needs-review
needs-review
netbird-ui
netbird-ui
netbird-ui
networking
networking
networking
new-platform
new-platform
new-platform
nginx
nginx
nginx
notification
notification
notification
okta
okta
okta
openwrt
openwrt
openwrt
P2
P2
P2
packaging
packaging
packaging
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
performance
performance
performance
postgres
postgres
postgres
posture-checks
posture-checks
posture-checks
psk
psk
psk
pull-request
Mirrored from GitHub Pull Request
 question
question
question
refactor
refactor
refactor
relay
relay
relay
release
release
release
rfc
rfc
rfc
routes
routes
routes
security
security
security
security-improvement
security-improvement
security-improvement
security-related
security-related
security-related
self-hosting
self-hosting
self-hosting
server
server
server
signal
signal
signal
sleep-issue
sleep-issue
sleep-issue
ssh
ssh
ssh
ssl
ssl
ssl
status
status
status
store
store
store
synology
synology
synology
system-compatibility-issue
system-compatibility-issue
system-compatibility-issue
test-suite
test-suite
test-suite
third-party-integration
third-party-integration
third-party-integration
triage
triage
triage
triage
triage
triage
triage-needed
triage-needed
triage-needed
troubleshooting
troubleshooting
troubleshooting
UX
UX
UX
waiting-feedback
waiting-feedback
waiting-feedback
windows
windows
windows
wontfix
wontfix
wontfix
zitadel
zitadel
zitadel
No Label triage-needed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dynr-servers saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11205
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?