[GH-ISSUE #1925] Network Routes only working partially #3740

Open
opened 2026-08-05 00:54:03 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @kladderadeng on GitHub (May 5, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/1925

Describe the problem
Sending a Ping over a Network Route into my LAN works, also when testing Port 80 of a Web Server in my LAN with Test-Netconnection 10.0.0.4 -port 80 works fine, but a Invoke-Webrequest http:/10.0.0.4 or trying to use a Webbrowser to get to that Website fails over the Route.

I defined a Network Route into my LAN and added a Linux Netbird Client (I use the Docker Image netbirdio/netbird:latest, which is 0.27.4) as the Routing peer. The other Netbird Client I am testing the connections is a Windows 2022 Server with Netbird 0.27.4 also.

A clear and concise description of what the problem is.

To Reproduce
Use 2 Netbird Clients. The machine the testing is done from is Windows Server 2022 with Netbird 0.27.4.
The Routing peer attached to the Network Route for Network 10.0.0.0/24 is a Linux Docker container using netbirdio/netbird:latest, which is 0.27.4 also.
Both peers can ping each other.
From the Windows VM you can Ping to the LAN, for example 10.0.0.4.
From the Linux Docker Container, you can Ping to the LAN, for example 10.0.0.4.
From the Windows VM, you can do a Test-Netconnection 10.0.0.4 -port 80 which works fine.
From the Linux Docker Container, you can do a nc -zv 10.0.0.4 80 which works fine.
From the Windows VM, a Invoke-Webrequest http://10.0.0.4 fails with "The underlying connection was closed: An unexpected error occurred on a receive.".
From the Linux Docker Container, you can do a wget http://10.0.0.4 which works fine.

Steps to reproduce the behavior:

  1. Create a new Route to 10.0.0.0/24 and add a linux peer which runs Netbird in Docker and which sits in 10.0.0.0/24.
  2. Put the Route into the Distribution Group All or create a new one, it does not matter. Make sure the Windows VM which should have access to 10.0.0.0/24 is in that group.
  3. Enable the Route and leave Masquerade enabled, also we keep Metric 9999
  4. Watch as the group gets propagated to the Windows VM and how the route is created. Also you can see the Route in the Netbird GUI and when running netbird status -d
  5. Try to Ping a IP in the LAN -> Will work
  6. Try to Test a Port of a System in the LAN -> Will work
  7. Try to do a Invoke-Webrequest on a HTTP address in the LAN or just open one with your Browser (Edge in this case) and it will not work.

Expected behavior
Since Ping and Port testing works, I assumed that traffic flows through the tunnel, but it does not it seems.

Are you using NetBird Cloud?
I am using Netbird Self-Hosted,

NetBird version
Dashboard v2.3.0, Signal v0.27.4, Management 0.27.4.

NetBird status -d output:

image

Here is the output of the netbird Container that is acting as the bridge into the LAN:
image

Additional context
I tried the same with an Android Client, but with the same result. So the route seems to work partially. Since I get an ICMP response, I would assume that data can also flow back, so I am a bit lost about what the problem could be here.
My COTURN Server is dedicated to netbird, has 200 open ports and while testing only 3 peers were connected.

Originally created by @kladderadeng on GitHub (May 5, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/1925 **Describe the problem** Sending a Ping over a Network Route into my LAN works, also when testing Port 80 of a Web Server in my LAN with Test-Netconnection 10.0.0.4 -port 80 works fine, but a Invoke-Webrequest http:/10.0.0.4 or trying to use a Webbrowser to get to that Website fails over the Route. I defined a Network Route into my LAN and added a Linux Netbird Client (I use the Docker Image netbirdio/netbird:latest, which is 0.27.4) as the Routing peer. The other Netbird Client I am testing the connections is a Windows 2022 Server with Netbird 0.27.4 also. A clear and concise description of what the problem is. **To Reproduce** Use 2 Netbird Clients. The machine the testing is done from is Windows Server 2022 with Netbird 0.27.4. The Routing peer attached to the Network Route for Network 10.0.0.0/24 is a Linux Docker container using netbirdio/netbird:latest, which is 0.27.4 also. Both peers can ping each other. From the Windows VM you can Ping to the LAN, for example 10.0.0.4. From the Linux Docker Container, you can Ping to the LAN, for example 10.0.0.4. From the Windows VM, you can do a Test-Netconnection 10.0.0.4 -port 80 which works fine. From the Linux Docker Container, you can do a nc -zv 10.0.0.4 80 which works fine. From the Windows VM, a Invoke-Webrequest http://10.0.0.4 fails with "The underlying connection was closed: An unexpected error occurred on a receive.". From the Linux Docker Container, you can do a wget http://10.0.0.4 which works fine. Steps to reproduce the behavior: 1. Create a new Route to 10.0.0.0/24 and add a linux peer which runs Netbird in Docker and which sits in 10.0.0.0/24. 2. Put the Route into the Distribution Group All or create a new one, it does not matter. Make sure the Windows VM which should have access to 10.0.0.0/24 is in that group. 3. Enable the Route and leave Masquerade enabled, also we keep Metric 9999 4. Watch as the group gets propagated to the Windows VM and how the route is created. Also you can see the Route in the Netbird GUI and when running netbird status -d 5. Try to Ping a IP in the LAN -> Will work 6. Try to Test a Port of a System in the LAN -> Will work 7. Try to do a Invoke-Webrequest on a HTTP address in the LAN or just open one with your Browser (Edge in this case) and it will not work. **Expected behavior** Since Ping and Port testing works, I assumed that traffic flows through the tunnel, but it does not it seems. **Are you using NetBird Cloud?** I am using Netbird Self-Hosted, **NetBird version** Dashboard v2.3.0, Signal v0.27.4, Management 0.27.4. **NetBird status -d output:** ![image](https://github.com/netbirdio/netbird/assets/111387593/8c930dc9-8a63-4d41-b409-6210012226b9) Here is the output of the netbird Container that is acting as the bridge into the LAN: ![image](https://github.com/netbirdio/netbird/assets/111387593/8e3b8daf-2f4b-4c2e-a217-6ca6cd85c52a) **Additional context** I tried the same with an Android Client, but with the same result. So the route seems to work partially. Since I get an ICMP response, I would assume that data can also flow back, so I am a bit lost about what the problem could be here. My COTURN Server is dedicated to netbird, has 200 open ports and while testing only 3 peers were connected.
saavagebueno added the waiting-feedbackroutes labels 2026-08-05 00:54:03 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#3740