netbird icon indicating copy to clipboard operation
netbird copied to clipboard

From network B to network A everything is ok, but from A to B only ping and traceroute work

Open Nexulo opened this issue 1 year ago • 4 comments

I have a very specific problem:

Network A (external network: 192.168.10.0/24) and network B (my home network: 192.168.184.0/24) are connected via two peers (2x Raspberry Pi 4) via Netbird. I can access all clients on external network A from my home network B. The peer in network A routes all requests correctly to the clients in the network and I can access the WebUI of various clients in this network.

If I am now connected over Wifi to network A and want to access devices located in home network B, only ping and traceroute commands works. The routing etc. all seems to work, because I can ping the devices and traceroute to the devices also works. But I still can't establish an SSH connection to clients in network B, no matter which target device I have. I also cannot access the WebUI from any client in network B. But as i said, ping and traceroute are always working.

Maybe my problem is related to this: https://github.com/netbirdio/netbird/issues/743

Peers:

Network A - 192.168.10.111
Network B - 192.168.184.43

Traceroute from Network B to Network A:

❯ traceroute 192.168.10.111
traceroute to 192.168.10.111 (192.168.10.111), 64 hops max, 40 byte packets
 1  192.168.184.1 (192.168.184.1)  3.522 ms  2.179 ms  2.177 ms
 2  192.168.184.43 (192.168.184.43)  2.513 ms  3.283 ms  2.551 ms
 3  192.168.10.111 (192.168.10.111)  81.484 ms  68.183 ms  63.558 ms

Traceroute from Network A to Network B:

❯ traceroute 192.168.184.43
traceroute to 192.168.184.43 (192.168.184.43), 64 hops max, 40 byte packets
 1  router.asus.com (192.168.10.1)  4.142 ms  2.159 ms  1.905 ms
 2  raspberry-extern (192.168.10.111)  1.924 ms  2.262 ms  1.659 ms
 3  192.168.184.43 (192.168.184.43)  59.853 ms  75.364 ms  64.368 ms

Pings with zero paket loss

❯ ping -c 100 192.168.184.24
PING 192.168.184.24 (192.168.184.24): 56 data bytes
64 bytes from 192.168.184.24: icmp_seq=0 ttl=62 time=63.984 ms
...
64 bytes from 192.168.184.24: icmp_seq=95 ttl=62 time=84.316 ms
64 bytes from 192.168.184.24: icmp_seq=96 ttl=62 time=62.566 ms
64 bytes from 192.168.184.24: icmp_seq=97 ttl=62 time=78.672 ms
64 bytes from 192.168.184.24: icmp_seq=98 ttl=62 time=111.832 ms
64 bytes from 192.168.184.24: icmp_seq=99 ttl=62 time=87.197 ms

--- 192.168.184.24 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss

The strange thing: I can successfully run a curl command in the cli of my peer in network A to a Client in Network B, but when i run the same command on my Mac Book, which is connected to Network A too, i get this (it's stuck and never finishes):

❯ curl -kv 192.168.184.24
*   Trying 192.168.184.24:80...
* Connected to 192.168.184.24 (192.168.184.24) port 80
> GET / HTTP/1.1
> Host: 192.168.184.24
> User-Agent: curl/8.4.0
> Accept: */*
> 

Are you using NetBird Cloud? No i'm using a self-hosted Netbird server.

NetBird version I've installed everything today, so i have the newest version.

NetBird status -d output:

Peers detail:
 raspberry-intern.netbird.selfhosted:
  NetBird IP: 100.92.55.27
  Public key: <>
  Status: Connected
  -- detail --
  Connection type: Relayed
  Direct: true
  ICE candidate (Local/Remote): host/relay
  ICE candidate endpoints (Local/Remote): 192.168.10.111:51820/<>:51820
  Last connection update: 2024-04-05 14:37:12
  Last WireGuard handshake: 2024-04-05 19:28:50
  Transfer status (received/sent) 77.9 KiB/105.7 KiB
  Quantum resistance: false
  Routes: 192.168.184.0/24
  Latency: 74.996393ms

Daemon version: 0.27.1
CLI version: 0.27.1
Management: Connected to https://domain.com:443
Signal: Connected to https://domain.com:443
Relays: 
  [stun:domain.com:3478] is Available
  [turn:domain.com:3478?transport=udp] is Available
Nameservers: 
FQDN: raspberry-extern.netbird.selfhosted
NetBird IP: 100.92.160.180/16
Interface type: Kernel
Quantum resistance: false
Routes: -
Peers count: 1/1 Connected

Nexulo avatar Apr 05 '24 17:04 Nexulo

Or is related to this issue?

https://github.com/netbirdio/netbird/issues/1370

jiangslee avatar Apr 11 '24 08:04 jiangslee

As I understand the problem @ https://github.com/netbirdio/netbird/issues/1370, the pings from A to B don't work there at all, do they? But all pings work for me without any problems, just as I wrote. But when i try to load the WebUI or try the ssh connection from my network A to network B, for example, it never successfully "finish" loading.

As I just read @ https://github.com/netbirdio/netbird/issues/743, there seems to be a problem with the MTU size. One of my networks is connected to internet via 4G router and the other via cable (DOCIS3.1 cable modem). This is exactly how one of my networks is connected, which is why I suspect that I have the same problem.

Nexulo avatar Apr 11 '24 08:04 Nexulo

Sorry, it's possible that I misunderstood your issue.

Horus-k tried to modify the MTU but failed. https://github.com/netbirdio/netbird/issues/1370#issuecomment-1855001191.

Have you tried configuring iptables FORWARD on your Raspberry Pi 4?

The method in this comment works for me and Horus-k. https://github.com/netbirdio/netbird/issues/1370#issuecomment-1893488723

Maybe you can try it.

jiangslee avatar Apr 11 '24 09:04 jiangslee

No problem, thank's anyway!

I will try that https://github.com/netbirdio/netbird/issues/1370#issuecomment-1855001191

I have already applied this configuration to both of my Raspberry Pi 4 devices, which I believe is why all ping requests are successful:

iptables -I FORWARD -o wt0 -j ACCEPT
iptables -t nat -I POSTROUTING -o wt0 -j MASQUERADE

but i did not this and i think i don't have 'br-lan' (or do i have to check that when i'm home and have time)? iptables -I FORWARD -o br-lan -j ACCEPT

Nexulo avatar Apr 11 '24 09:04 Nexulo

It seems to be working now. I can't say exactly what the problem was, but I have set up two new Raspberry Pi's, as these are the two that will be used.

But I won't be able to say for sure for another 1-2 weeks, once everything has been installed at the destination.

Nexulo avatar Apr 29 '24 05:04 Nexulo