Unexpected WireGuard interface restart during GlobalProtect connection

[ressys1978]

Describe the problem

When connecting GlobalProtect VPN on Windows or macOS, NetBird tears down and recreates its WireGuard interface. This immediately kills all active TCP sessions (e.g., SSH). The teardown happens even though routes remain valid.

Windows NetworkProfile logs show a sequence of interface/profile events (4002 → 10002 → 10000 → 20002 → 4004 → 10001) that correspond precisely to the moment NetBird destroys and recreates its interface.

This does not happen to wireguard or any other VPN software when GlobalProtect connects, just netbird.

netbird.debug.2761929254.zip

To Reproduce

Steps to reproduce the behavior:

1. Connect to a stable network (Wi-Fi or Ethernet).
2. Start NetBird VPN and Connect
3. Initiate an active TCP session (e.g., SSH) over NetBird.
4. Connect to GlobalProtect VPN (corporate client).
5. Netbird then gives "Connection to service lost" Error, and reconnects, but all SSH sessions are dropped.

Expected behavior

The Tunnel should survive transient network or firewall/profile changes triggered by GlobalProtect, without destroying the interface or dropping existing TCP sessions. TCP connections should remain active, similar to plain WireGuard behavior.

Are you using NetBird Cloud?

Self-Hosted

NetBird version

v0.62.1, but tested it all the way down to v0.60.0 and it occurs.

Is any other VPN software installed?

Yes. GlobalProtect, and Wireguard.

Debug output

Debug attached

Screenshots

n/a

Additional context

Add any other context about the problem here.

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

[aviralgarg05]

I would like to solve this issue, please assign me this issue

[mlsmaycon]

It seems like that Global connec causes some changes in the node's local network and that triggered our network monitor:

2026-01-08T14:15:36-04:00 INFO client/internal/networkmonitor/check_change_windows.go:69: Network monitor: default route added: via 0.0.0.0 @ 22 (Ethernet 5)
2026-01-08T14:15:38-04:00 INFO client/internal/engine.go:1805: Network monitor: detected network change, triggering client restart
2026-01-08T14:15:38-04:00 INFO client/internal/engine.go:1779: restarting engine
2026-01-08T14:15:38-04:00 INFO client/internal/engine.go:1782: cancelling client context, engine will be recreated

This happens because the other services adds a default route and that is usually a trigger for our client to restart. There is no workaround except for disabling the network monitor with the following command, but this means that you might have issues with computer switching to different networks.

netbird down
netbird up --network-monitor=false

[ressys1978]

@mlsmaycon

From my understanding is it should ignore that if the interface is a SoftInterface. I have other VPNs that add default routes when connected and they don't experience the same issue. For example an OpenVPN based VPN that uses a TAP Adapter. The Adapter used by GlobalProtect is "PANGP Virtual Ethernet Adapter Secure", which is a SoftwareInterface.

I've been fiddling around with the code locally, and have managed to fix where it breaks (at least for me and a couple of my users in testing). When I have time, and if someone else doesn't beat me to it, I'll submit a Pull Request to fix it on Windows so that "PANGP Virtual Ethernet Adapter Secure" is detected as a SoftInterface and treated as such.

I don't have a Mac that I can use (yet) to try and figure out how to fix it for MacOS.