[GH-ISSUE #5641] Linux client fails to reconnect via LTE after WiFi interface goes down #11825

Open
opened 2026-08-05 01:31:12 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @0xDedSec42 on GitHub (Mar 20, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5641

Describe the problem

When the primary network interface (WiFi) goes down on Linux, the NetBird client fails to automatically reconnect via a secondary interface (LTE/mobile broadband). The client loses its connection to the management server and does not recover on its own, even after a working LTE default route is established.

On mobile platforms (iOS tested), the same scenario works correctly — NetBird reconnects seamlessly when switching from WiFi to cellular.

To Reproduce

  1. Linux peer connected to NetBird via WiFi (wlp109s0)
  2. LTE modem active as secondary interface (wwan0), no default route while WiFi is up
  3. Disable WiFi: nmcli connection down "SSID" or move out of WiFi range
  4. LTE default route is established (verified: curl https://1.1.1.1 works)
  5. Wait 30+ seconds — NetBird does not reconnect

Expected behavior

NetBird should detect that the previously used interface is gone and attempt to reconnect via any available route, similar to how the iOS client handles network switches.

Are you using NetBird Cloud?

Yes, NetBird Cloud (netbird.io).

NetBird version

0.66.4

Is any other VPN software installed?

No.

Debug output

netbird status --detail after WiFi down, before manual reconnect:

Management: Disconnected, reason: rpc error: code = DeadlineExceeded desc = context deadline exceeded
Signal: Disconnected, reason: rpc error: code = Unavailable desc = error reading from server: read tcp [REDACTED]:58330->[REDACTED]:443: read: connection timed out
Peers count: 4/7 Connected

Events:
  [WARNING] DNS
    Message: All upstream servers failed (probe failed)
    Metadata: upstreams: [SUBNET_ROUTER_IP]:53
  [WARNING] NETWORK
    Message: Default route disconnected due to peer unreachability
    Metadata: id: Exit Node, network: 0.0.0.0/0

netbird status --detail after manual netbird down && netbird up via LTE:

Management: Connected
Signal: Connected
Relays: 4/4 Available
Nameservers: 1/1 Available
Peers count: 6/7 Connected
Networks: 0.0.0.0/0, 192.168.16.0/23

Note: A full debug bundle (netbird debug) cannot be captured at the time of the failure because the LTE interface is the only available uplink and uploading the bundle requires a working connection — which is only restored after the manual workaround.

Screenshots

N/A

Additional context

  • Internet connectivity via LTE is confirmed working at the time of failure (curl https://1.1.1.1/cdn-cgi/trace returns a valid response)
  • A subnet router peer on the same network correctly advertises 192.168.16.0/23 and 0.0.0.0/0 and is fully reachable once NetBird reconnects manually
  • iOS client on the same account reconnects automatically and seamlessly when switching from WiFi to cellular — Linux client does not
  • Workaround: NetworkManager dispatcher script runs netbird down && sleep 1 && netbird up & on wlp109s0 down — reliably triggers reconnection

OS: Athena OS (Arch Linux) x86_64, Kernel 6.18.18-1-lts
Interface type: Kernel (WireGuard)
Primary interface: WiFi (wlp109s0)
Secondary interface: LTE via Intel XMM7360 / Fibocom L850-GL (wwan0)

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting
  • 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 @0xDedSec42 on GitHub (Mar 20, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5641 **Describe the problem** When the primary network interface (WiFi) goes down on Linux, the NetBird client fails to automatically reconnect via a secondary interface (LTE/mobile broadband). The client loses its connection to the management server and does not recover on its own, even after a working LTE default route is established. On mobile platforms (iOS tested), the same scenario works correctly — NetBird reconnects seamlessly when switching from WiFi to cellular. **To Reproduce** 1. Linux peer connected to NetBird via WiFi (`wlp109s0`) 1. LTE modem active as secondary interface (`wwan0`), no default route while WiFi is up 1. Disable WiFi: `nmcli connection down "SSID"` or move out of WiFi range 1. LTE default route is established (verified: `curl https://1.1.1.1` works) 1. Wait 30+ seconds — NetBird does not reconnect **Expected behavior** NetBird should detect that the previously used interface is gone and attempt to reconnect via any available route, similar to how the iOS client handles network switches. **Are you using NetBird Cloud?** Yes, NetBird Cloud (netbird.io). **NetBird version** ``` 0.66.4 ``` **Is any other VPN software installed?** No. **Debug output** `netbird status --detail` after WiFi down, before manual reconnect: ``` Management: Disconnected, reason: rpc error: code = DeadlineExceeded desc = context deadline exceeded Signal: Disconnected, reason: rpc error: code = Unavailable desc = error reading from server: read tcp [REDACTED]:58330->[REDACTED]:443: read: connection timed out Peers count: 4/7 Connected Events: [WARNING] DNS Message: All upstream servers failed (probe failed) Metadata: upstreams: [SUBNET_ROUTER_IP]:53 [WARNING] NETWORK Message: Default route disconnected due to peer unreachability Metadata: id: Exit Node, network: 0.0.0.0/0 ``` `netbird status --detail` after manual `netbird down && netbird up` via LTE: ``` Management: Connected Signal: Connected Relays: 4/4 Available Nameservers: 1/1 Available Peers count: 6/7 Connected Networks: 0.0.0.0/0, 192.168.16.0/23 ``` *Note: A full debug bundle (`netbird debug`) cannot be captured at the time of the failure because the LTE interface is the only available uplink and uploading the bundle requires a working connection — which is only restored after the manual workaround.* **Screenshots** N/A **Additional context** - Internet connectivity via LTE is confirmed working at the time of failure (`curl https://1.1.1.1/cdn-cgi/trace` returns a valid response) - A subnet router peer on the same network correctly advertises `192.168.16.0/23` and `0.0.0.0/0` and is fully reachable once NetBird reconnects manually - iOS client on the same account reconnects automatically and seamlessly when switching from WiFi to cellular — Linux client does not - Workaround: NetworkManager dispatcher script runs `netbird down && sleep 1 && netbird up &` on `wlp109s0 down` — reliably triggers reconnection **OS:** Athena OS (Arch Linux) x86_64, Kernel 6.18.18-1-lts **Interface type:** Kernel (WireGuard) **Primary interface:** WiFi (`wlp109s0`) **Secondary interface:** LTE via Intel XMM7360 / Fibocom L850-GL (`wwan0`) **Have you tried these troubleshooting steps?** - [x] Reviewed client troubleshooting - [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:31:12 -04:00
Author
Owner

@fpenezic commented on GitHub (Mar 28, 2026):

Reproducible with PPPoE reconnect behind NAT - tested across multiple versions

I can confirm this bug with a slightly different topology: Raspberry Pi running NetBird behind a home router with PPPoE. The PPPoE connection is on the router, so the Pi's local interface (eth0) never changes - only the WAN IP changes on reconnect, completely invisible to the NetBird client.

Environment:

  • RPI: NetBird client, Raspberry Pi OS, behind NAT (PPPoE on router)
  • Peer: NetBird client, OCI (Oracle Cloud) Ubuntu, kernel WireGuard
  • Self-hosted NetBird server: 0.67.1
  • NetworkMonitor: false in config (but irrelevant here - local interface never changes)

Reproduction steps:

  1. Both peers connected and working normally
  2. Force PPPoE reconnect on router (WAN IP changes)
  3. NetBird does NOT recover automatically - netbird status shows Connected but traffic doesn't flow

Symptoms:

  • netbird status --detail shows Connected, P2P, fresh-looking ICE candidates with new WAN IP
  • WireGuard handshake never completes (last handshake: -)
  • Packets sent, 0 received
  • Log flood in client.log:
WARN wg_watcher.go: WireGuard handshake timed out: 0001-01-01 00:00:00 +0000 UTC
WARN conn.go: WireGuard handshake timeout detected, closing current connection
INFO conn.go: ICE disconnected, set Relay to active connection
INFO worker_ice.go: connection succeeded with offer session: XXXXXXXX
INFO conn.go: configure WireGuard endpoint to: <correct new WAN IP>:51820
WARN wg_watcher.go: WireGuard handshake timed out: <same old timestamp>  ← never updates
  • On the other peer: skipping remote answer message because receiver not ready
  • Loop repeats every ~30 seconds indefinitely

Workaround: sudo netbird down && sudo netbird up on either peer immediately restores connectivity.

Versions tested - all fail to recover after PPPoE reconnect:

  • 0.65.0
  • 0.65.3
  • 0.66.4
  • 0.67.0
  • 0.67.1

Note: bisect testing is ongoing - earlier results suggesting 0.64.6 worked were inconclusive as the recovery may have been coincidental (fresh restart after version change). Further testing needed to identify the exact version where this was introduced.

ICE renegotiation itself works correctly - the new WAN IP is discovered via STUN and propagated to the peer. The failure is specifically in the WireGuard handshake completion after ICE switches between relay and P2P during the reconnect sequence.

<!-- gh-comment-id:4148992161 --> @fpenezic commented on GitHub (Mar 28, 2026): **Reproducible with PPPoE reconnect behind NAT - tested across multiple versions** I can confirm this bug with a slightly different topology: Raspberry Pi running NetBird behind a home router with PPPoE. The PPPoE connection is on the router, so the Pi's local interface (`eth0`) never changes - only the WAN IP changes on reconnect, completely invisible to the NetBird client. **Environment:** - RPI: NetBird client, Raspberry Pi OS, behind NAT (PPPoE on router) - Peer: NetBird client, OCI (Oracle Cloud) Ubuntu, kernel WireGuard - Self-hosted NetBird server: 0.67.1 - `NetworkMonitor: false` in config (but irrelevant here - local interface never changes) **Reproduction steps:** 1. Both peers connected and working normally 2. Force PPPoE reconnect on router (WAN IP changes) 3. NetBird does NOT recover automatically - `netbird status` shows `Connected` but traffic doesn't flow **Symptoms:** - `netbird status --detail` shows `Connected`, P2P, fresh-looking ICE candidates with new WAN IP - WireGuard handshake never completes (`last handshake: -`) - Packets sent, 0 received - Log flood in `client.log`: ``` WARN wg_watcher.go: WireGuard handshake timed out: 0001-01-01 00:00:00 +0000 UTC WARN conn.go: WireGuard handshake timeout detected, closing current connection INFO conn.go: ICE disconnected, set Relay to active connection INFO worker_ice.go: connection succeeded with offer session: XXXXXXXX INFO conn.go: configure WireGuard endpoint to: <correct new WAN IP>:51820 WARN wg_watcher.go: WireGuard handshake timed out: <same old timestamp> ← never updates ``` - On the other peer: `skipping remote answer message because receiver not ready` - Loop repeats every ~30 seconds indefinitely **Workaround:** `sudo netbird down && sudo netbird up` on either peer immediately restores connectivity. **Versions tested - all fail to recover after PPPoE reconnect:** - 0.65.0 - 0.65.3 - 0.66.4 - 0.67.0 - 0.67.1 Note: bisect testing is ongoing - earlier results suggesting 0.64.6 worked were inconclusive as the recovery may have been coincidental (fresh restart after version change). Further testing needed to identify the exact version where this was introduced. ICE renegotiation itself works correctly - the new WAN IP is discovered via STUN and propagated to the peer. The failure is specifically in the WireGuard handshake completion after ICE switches between relay and P2P during the reconnect sequence.
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#11825