Network Routes only working partially #1925
Comments
|
Since you get a response, it's unlikely that's an issue with the route itself. Could you connect to the container and dump some traffic? docker exec -it xxx sh
apk add tcpdump
tcpdump -Ani wt0Then run the http test from the windows box. |
|
Thank you very much @lixmal! Very good idea installing tcpdump, I did not think about that :-) I did as you suggested and tried to open a website at 10.0.0.4, then did a tracert to 10.0.0.4 and then the same again. The webbrowser failed as it did yesterday and the tracert went through. It looks like this:
The tcpdump is obviously a bit longer. In the dump, 100.104.32.248 is the Windows VM from where the tests are executed and 100.104.225.154 is the Netbird client in my LAN that acts as a gateway. I am apologizing in advance for the length. I did not find a good way to post this. If I format it as code, it looks horrible and Quote would require me to enter 464 > ;-) Before the wall of text starts. To me it seems like Masquerading is at least working, since there are packets that should flow from 10.0.0.4 to 100.104.32.248, which is the Windows VM. / # tcpdump -Ani wt0 18:33:19.999821 IP 100.104.32.248.49985 > 10.0.0.4.80: Flags [.], ack 1, win 6146, length 0 18:33:20.591798 IP 100.104.32.248.49984 > 10.0.0.4.80: Flags [P.], seq 1:438, ack 1, win 6146, length 437: HTTP: GET / HTTP/1.1 18:33:20.592355 IP 10.0.0.4.80 > 100.104.32.248.49984: Flags [R], seq 3645237574, win 0, length 0 18:33:21.699722 IP 10.0.0.4.80 > 100.104.32.248.49987: Flags [S.], seq 2277799414, ack 2677292347, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 3], length 0 18:33:22.274174 IP 100.104.32.248.49985 > 10.0.0.4.80: Flags [P.], seq 1:464, ack 1, win 6146, length 463: HTTP: GET / HTTP/1.1 18:33:22.274773 IP 10.0.0.4.80 > 100.104.32.248.49985: Flags [R], seq 3900528977, win 0, length 0 18:33:22.579003 IP 100.104.32.248.49987 > 10.0.0.4.80: Flags [P.], seq 1:464, ack 1, win 6146, length 463: HTTP: GET / HTTP/1.1 18:33:22.880226 IP 100.104.32.248.49987 > 10.0.0.4.80: Flags [P.], seq 1:464, ack 1, win 6146, length 463: HTTP: GET / HTTP/1.1 18:33:22.880877 IP 10.0.0.4.80 > 100.104.32.248.49987: Flags [R], seq 2277799415, win 0, length 0 18:33:23.168613 IP 100.104.32.248.49998 > 10.0.0.4.80: Flags [P.], seq 1:464, ack 1, win 6146, length 463: HTTP: GET / HTTP/1.1 18:33:23.469304 IP 100.104.32.248.49998 > 10.0.0.4.80: Flags [P.], seq 1:464, ack 1, win 6146, length 463: HTTP: GET / HTTP/1.1 18:33:23.469887 IP 10.0.0.4.80 > 100.104.32.248.49998: Flags [R], seq 2340616, win 0, length 0 18:33:28.540009 IP 10.0.0.4.80 > 100.104.32.248.50000: Flags [S.], seq 847636072, ack 1181941310, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 3], length 0 18:33:29.080277 IP 100.104.32.248.49999 > 10.0.0.4.80: Flags [P.], seq 1:464, ack 1, win 6146, length 463: HTTP: GET / HTTP/1.1 18:33:29.080840 IP 10.0.0.4.80 > 100.104.32.248.49999: Flags [R], seq 1626195286, win 0, length 0 18:33:56.775736 IP 100.104.32.248.50026 > 10.0.0.4.80: Flags [.], ack 1, win 6146, length 0 18:33:57.343271 IP 100.104.32.248.50025 > 10.0.0.4.80: Flags [P.], seq 1:464, ack 1, win 6146, length 463: HTTP: GET / HTTP/1.1 18:33:57.343783 IP 10.0.0.4.80 > 100.104.32.248.50025: Flags [R], seq 3326930964, win 0, length 0 |
|
same |
I think it is different. Routes do get created for me as some traffic traverses the tunnels and some not. Maybe the root cause is similar, but the outcome is a bit different. In the end both of us have the issue that we can not utilize the routes ;-) |
|
Just a heads up: |
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:
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:
Here is the output of the netbird Container that is acting as the bridge into the LAN:
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.
The text was updated successfully, but these errors were encountered: