From a8ba9d014959a5d9aa7d9789c5598cbe37673c6a Mon Sep 17 00:00:00 2001 From: riccardom Date: Fri, 11 Sep 2026 15:51:49 +0200 Subject: [PATCH] [client] Apply the published upload destination at login too MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Engine.Start receives the login response's NetbirdConfig but only runs it through PopulateNetbirdConfig, so handleDebugUploadUpdate never saw it: the destination the management server publishes reached the engine only on the first sync afterwards. A debug bundle requested in that window resolved no published destination and fell back to the service NetBird runs, even on a deployment that had configured its own — the opposite of what configuring it is for. Seen with a remote job triggered shortly after the peer reconnected: the job succeeded against NetBird's upload service while the account setting named a different host. --- client/internal/engine.go | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/client/internal/engine.go b/client/internal/engine.go index 7f3042b7c..e2ff901ed 100644 --- a/client/internal/engine.go +++ b/client/internal/engine.go @@ -615,6 +615,13 @@ func (e *Engine) Start(netbirdConfig *mgmProto.NetbirdConfig, mgmtURL *url.URL) log.Warnf("failed to populate DNS cache: %v", err) } + // The login response carries the same NetbirdConfig a sync does, but Start + // does not run it through updateNetbirdConfig. Without this, a bundle + // requested between login and the first sync sees no published destination + // and falls back to the service NetBird runs, even where the deployment + // configured its own. + e.handleDebugUploadUpdate(netbirdConfig.GetDebug()) + e.routeManager = routemanager.NewManager(routemanager.ManagerConfig{ Context: e.ctx, PublicKey: e.config.WgPrivateKey.PublicKey().String(),