Subnet routing (network) issues on Windows

[LeveinOvO]

Describe the problem

In general, using Windows as a subnet's "Routing peers" will cause the subnet connection to fail after a reboot. I have been able to accurately reproduce the problem and found a less elegant solution

To Reproduce

Steps to reproduce the behavior:

1. I registered two machines (A/B) on the tencent cloud (any cloud service provider will do), each with a public network IP. And install NetBird.

2. A uses VMware's network tool to simulate a private network: 192.168.10.1/24, and A's address is 192.168.10.1.

3. Normally declare subnet resources in the console: Networks-A: Resources 192.168.10.0/24, Routing Peer 'A'

4. Use the following PowerShell commands on A to enable data forwarding Set-NetIPInterface -InterfaceAlias ​​"VMware Network Adapter VMnet1" -AddressFamily IPv4 -Forwarding Enabled Set-NetIPInterface -InterfaceAlias ​​"wt0" -AddressFamily IPv4 -Forwarding Enabled

5. At this time, B can ping 192.168.10.1. So far, everything is normal. Then restart the computer, and then you will find that the forwarding settings of wt0 have disappeared. This may be a problem with Windows, not Netbird, so I added it manually.

6. Then the problem occurred. I used B to ping 192.168.10.1, but the connection was unavailable. I used wireshark to capture packets and found that the data packets could be sent out through the wt0 interface, but the wt0 interface on the A did not receive any data packets. At this time, B pings A's NetBird IP and it is normal.

7. A less elegant solution is to turn off and then on the active switch in the networks-resouce on the management page, and then the two ends will resume normal communication.

Expected behavior

I hope that after the restart everything will work fine.

Are you using NetBird Cloud?

I use NetBird Cloud

NetBird version

v0.45.1

Is any other VPN software installed?

No, they are all new machines. Firewall is completely closed

Debug output

To help us resolve the problem, please attach the following anonymized status output

NetBird.txt

Create and upload a debug bundle, and share the returned file key:

It seems that this problem will also occur if you restart NetBird without restarting Windows.Therefore, after the package is created, the wt0 forwarding settings are lost. It is still necessary to re-add and restart the active switch to restore to normal. The following captured packets are captured during normal forwarding. After the capture is completed, the forwarding is lost.

netbird.debug.3636774615.zip file key: f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/3ae89da4-92e5-4145-b37d-fa668f0b8742

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

[RHDHV-simon-sutcliffe]

Hi @LeveinOvO thanks for this report it helped me with one issue I was about to deep dive into.

To add a little to this report. On Linux the local LAN IP of the Routing Peer (Networks concept) is reachable when it is part of the IP ranges listed as resources for the network.

On windows hosts however the local IP is not reachable without the addition of these powershell commands to enable routing on the interfaces.

Set-NetIPInterface -InterfaceAlias ​​"Ethernet0" -AddressFamily IPv4 -Forwarding Enabled Set-NetIPInterface -InterfaceAlias ​​"wt0" -AddressFamily IPv4 -Forwarding Enabled

As these commands are not persistent, I added the following registry setting which enables routing for all interfaces

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "IPEnableRouter" -Value 1

I hope this helps you as I think you can solve your issue with the IPEnableRouter reg key but I would like to see this also handled correctly by the NetBird client on Windows systems.

[lixmal]

v0.46.0 adds the option to run with NB_ENABLE_LOCAL_FORWARDING=true, which should circumvent the Windows restriction:

[Environment]::SetEnvironmentVariable("NB_ENABLE_LOCAL_FORWARDING", "true", "Machine")
netbird service restart

Opt-in for now.

[RHDHV-simon-sutcliffe]

@lixmal I can confirm this Environment variable also fixes the issue.