[GH-ISSUE #2656] Cannot even ping the local IP [OS: Ubuntu 24.04.1 LTS, ARCH: amd x64] #5571

Open
opened 2026-08-05 01:03:58 -04:00 by saavagebueno · 7 comments
Owner

Originally created by @pilinux on GitHub (Sep 27, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2656

How I installed

curl -sSL https://pkgs.netbird.io/debian/public.key | sudo gpg --dearmor --output /usr/share/keyrings/netbird-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/netbird-archive-keyring.gpg] https://pkgs.netbird.io/debian stable main' | sudo tee /etc/apt/sources.list.d/netbird.list

sudo apt install netbird
netbird login --setup-key <...> --preshared-key <...>
netbird up --enable-rosenpass

Status

netbird status

OS: linux/amd64
Daemon version: 0.29.4
CLI version: 0.29.4
Management: Connected
Signal: Connected
Relays: 2/2 Available
Nameservers: 1/1 Available
FQDN: xxx.netbird.cloud
NetBird IP: 100.82.x.xxx/16
Interface type: Kernel
Quantum resistance: true
Routes: -
Peers count: 1/z Connected

Problem

netbird local IP on this machine is 100.82.x.xxx

does not work: ping 100.82.x.xxx

another peer on the network is 100.82.y.yyy

obviously also does not work when I do ping from this machine (x) to another peer (y).

Beside this machine (Ubuntu 24.04), all my other peers (macOS, Ubuntu 22.04) are working fine.

Note: I am using netbird SaaS platform (not self-hosted).

netbird status -d

OS: linux/amd64
Daemon version: 0.29.4
CLI version: 0.29.4
Management: Connected to https://api.netbird.io:443
Signal: Connected to https://signal.netbird.io:443
Relays:
  [stun:stun.netbird.io:5555] is Available
  [turns:turn.netbird.io:443?transport=tcp] is Available
Nameservers:
  [1.1.1.1:53, 1.0.0.1:53] for [.] is Available
FQDN: xxx.netbird.cloud
NetBird IP: 100.82.x.xxx/16
Interface type: Kernel
Quantum resistance: true
Routes: -
Peers count: 1/z Connected
Originally created by @pilinux on GitHub (Sep 27, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2656 ## How I installed ```sh curl -sSL https://pkgs.netbird.io/debian/public.key | sudo gpg --dearmor --output /usr/share/keyrings/netbird-archive-keyring.gpg echo 'deb [signed-by=/usr/share/keyrings/netbird-archive-keyring.gpg] https://pkgs.netbird.io/debian stable main' | sudo tee /etc/apt/sources.list.d/netbird.list sudo apt install netbird netbird login --setup-key <...> --preshared-key <...> netbird up --enable-rosenpass ``` ## Status `netbird status` ``` OS: linux/amd64 Daemon version: 0.29.4 CLI version: 0.29.4 Management: Connected Signal: Connected Relays: 2/2 Available Nameservers: 1/1 Available FQDN: xxx.netbird.cloud NetBird IP: 100.82.x.xxx/16 Interface type: Kernel Quantum resistance: true Routes: - Peers count: 1/z Connected ``` ## Problem netbird local IP on this machine is `100.82.x.xxx` does not work: `ping 100.82.x.xxx` another peer on the network is `100.82.y.yyy` obviously also does not work when I do ping from this machine (x) to another peer (y). Beside this machine (Ubuntu 24.04), all my other peers (macOS, Ubuntu 22.04) are working fine. Note: I am using netbird SaaS platform (not self-hosted). `netbird status -d` ``` OS: linux/amd64 Daemon version: 0.29.4 CLI version: 0.29.4 Management: Connected to https://api.netbird.io:443 Signal: Connected to https://signal.netbird.io:443 Relays: [stun:stun.netbird.io:5555] is Available [turns:turn.netbird.io:443?transport=tcp] is Available Nameservers: [1.1.1.1:53, 1.0.0.1:53] for [.] is Available FQDN: xxx.netbird.cloud NetBird IP: 100.82.x.xxx/16 Interface type: Kernel Quantum resistance: true Routes: - Peers count: 1/z Connected ```
saavagebueno added the waiting-feedbacktriage-neededlinux labels 2026-08-05 01:03:58 -04:00
Author
Owner

@mgarces commented on GitHub (Sep 27, 2024):

Hi @pilinux,
Which groups are those peers inserted to? Do you have a Policy that allows communication between them?

<!-- gh-comment-id:2378916492 --> @mgarces commented on GitHub (Sep 27, 2024): Hi @pilinux, Which groups are those peers inserted to? Do you have a Policy that allows communication between them?
Author
Owner

@pilinux commented on GitHub (Sep 27, 2024):

Hi @mgarces
They all are in the default group. Bidirectional communication is on for all ports for the moment.

image
<!-- gh-comment-id:2378953419 --> @pilinux commented on GitHub (Sep 27, 2024): Hi @mgarces They all are in the default group. Bidirectional communication is on for all ports for the moment. <img width="1229" alt="image" src="https://github.com/user-attachments/assets/b8aa1854-888e-43fe-8260-2a6a6fdcb688">
Author
Owner

@mgarces commented on GitHub (Sep 27, 2024):

can you do a tcpdump on both ends, just to check if traffic is flowing in that direction?
Just for the sake of testing, please create a specific group for those peers, and create a new Policy just for them.
You can run the tcpdump with:

tcpdump -i any -nn host <NB_IP_ADDRESS>

On on end, replace the IP with the remote Netbird address, and on the remote, with your local Netbird address.
Also, can you paste here the output netbird status -d for both peers?

<!-- gh-comment-id:2378968986 --> @mgarces commented on GitHub (Sep 27, 2024): can you do a `tcpdump` on both ends, just to check if traffic is flowing in that direction? Just for the sake of testing, please create a specific group for those peers, and create a new Policy just for them. You can run the `tcpdump` with: ``` tcpdump -i any -nn host <NB_IP_ADDRESS> ``` On on end, replace the IP with the remote Netbird address, and on the remote, with your local Netbird address. Also, can you paste here the output `netbird status -d` for both peers?
Author
Owner

@pilinux commented on GitHub (Sep 27, 2024):

All machines are assigned to a new network on netbird cloud platform.

  • Machine A: working fine
  • Machine B: working fine
  • Machine C: doesn't work

On all three machines: net.ipv4.icmp_echo_ignore_all = 0

Machine A:

  • local ip assigned by netbird = 100.82.a.aaa
  • ping -I wt0 100.82.a.aaa => OK

Machine B:

  • local ip assigned by netbird = 100.82.b.bbb
  • ping -I wt0 100.82.b.bbb => OK

Machine C:

  • local ip assigned by netbird = 100.82.c.ccc
  • ping -I wt0 100.82.c.ccc => all packets are lost

Tests only on machine C:

terminal 1

sudo tcpdump -i any -nn host 100.82.c.ccc

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

17:34:32.817064 lo    In  IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 1, length 64
17:34:33.833506 lo    In  IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 2, length 64
17:34:34.857515 lo    In  IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 3, length 64
17:34:35.881541 lo    In  IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 4, length 64
17:34:36.905549 lo    In  IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 5, length 64
17:34:37.929549 lo    In  IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 6, length 64

6 packets captured
13 packets received by filter
0 packets dropped by kernel

terminal 2:

ping -I wt0 100.82.c.ccc
--- 100.82.c.ccc ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5112ms

Tests using machine A and C:

terminal 1 (machine A):

sudo tcpdump -i any -nn host 100.82.c.ccc

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

17:41:09.234046 wt0   In  IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 1, length 64
17:41:09.234158 wt0   Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 1, length 64
17:41:10.258846 wt0   In  IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 2, length 64
17:41:10.258883 wt0   Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 2, length 64
17:41:11.282977 wt0   In  IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 3, length 64
17:41:11.283021 wt0   Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 3, length 64
17:41:12.306984 wt0   In  IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 4, length 64
17:41:12.307054 wt0   Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 4, length 64
17:41:13.331089 wt0   In  IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 5, length 64
17:41:13.331155 wt0   Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 5, length 64
17:41:14.355046 wt0   In  IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 6, length 64
17:41:14.355082 wt0   Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 6, length 64
17:41:15.378944 wt0   In  IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 7, length 64
17:41:15.378977 wt0   Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 7, length 64

14 packets captured
15 packets received by filter
0 packets dropped by kernel

netbird status -d:

 machinec.netbird.cloud:
  NetBird IP: 100.82.c.ccc
  Public key: ...
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): host/prflx
  ICE candidate endpoints (Local/Remote): <IP>:51820/<IP>:51820
  Relay server address:
  Last connection update: 6 hours, 31 minutes ago
  Last WireGuard handshake: 23 seconds ago
  Transfer status (received/sent) 103.1 KiB/40.8 KiB
  Quantum resistance: true
  Routes: -
  Latency: 15.294023ms

OS: linux/arm64
Daemon version: 0.29.4
CLI version: 0.29.4
Management: Connected to https://api.netbird.io:443
Signal: Connected to https://signal.netbird.io:443
Relays:
  [stun:stun.netbird.io:5555] is Available
  [turns:turn.netbird.io:443?transport=tcp] is Available
Nameservers:
  [1.1.1.1:53, 1.0.0.1:53] for [.] is Available
FQDN: aaa.netbird.cloud
NetBird IP: 100.82.a.aaa/16
Interface type: Kernel
Quantum resistance: true
Routes: -
Peers count: 1/4 Connected

terminal 1 (machine C):

sudo tcpdump -i any -nn host 100.82.a.aaa

tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

17:41:09.224558 wt0   Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 1, length 64
17:41:09.239350 wt0   In  IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 1, length 64
17:41:10.249497 wt0   Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 2, length 64
17:41:10.263987 wt0   In  IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 2, length 64
17:41:11.273462 wt0   Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 3, length 64
17:41:11.288227 wt0   In  IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 3, length 64
17:41:12.297440 wt0   Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 4, length 64
17:41:12.312155 wt0   In  IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 4, length 64
17:41:13.321538 wt0   Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 5, length 64
17:41:13.336378 wt0   In  IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 5, length 64
17:41:14.345542 wt0   Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 6, length 64
17:41:14.360319 wt0   In  IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 6, length 64
17:41:15.369540 wt0   Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 7, length 64
17:41:15.384098 wt0   In  IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 7, length 64

14 packets captured
15 packets received by filter
0 packets dropped by kernel

terminal 2 (machine C):

ping -I wt0 100.82.a.aaa

--- 100.82.a.aaa ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6145ms

netbird status -d:

 machinea.netbird.cloud:
  NetBird IP: 100.82.a.aaa
  Public key: ...
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): srflx/host
  ICE candidate endpoints (Local/Remote): <IP>:51820/<IP>:51820
  Relay server address:
  Last connection update: 6 hours, 27 minutes ago
  Last WireGuard handshake: 29 seconds ago
  Transfer status (received/sent) 19.7 KiB/63.5 KiB
  Quantum resistance: true
  Routes: -
  Latency: 15.325518ms

OS: linux/amd64
Daemon version: 0.29.4
CLI version: 0.29.4
Management: Connected to https://api.netbird.io:443
Signal: Connected to https://signal.netbird.io:443
Relays:
  [stun:stun.netbird.io:5555] is Available
  [turns:turn.netbird.io:443?transport=tcp] is Available
Nameservers:
  [1.1.1.1:53, 1.0.0.1:53] for [.] is Available
FQDN: ccc.netbird.cloud
NetBird IP: 100.82.c.ccc/16
Interface type: Kernel
Quantum resistance: true
Routes: -
Peers count: 1/4 Connected

Note: Also, no way to SSH into machine C over netbird.

<!-- gh-comment-id:2379688298 --> @pilinux commented on GitHub (Sep 27, 2024): All machines are assigned to a new network on netbird cloud platform. - Machine A: working fine - Machine B: working fine - Machine C: doesn't work On all three machines: `net.ipv4.icmp_echo_ignore_all = 0` ## Machine A: - local ip assigned by netbird = 100.82.a.aaa - `ping -I wt0 100.82.a.aaa` => OK ## Machine B: - local ip assigned by netbird = 100.82.b.bbb - `ping -I wt0 100.82.b.bbb` => OK ## Machine C: - local ip assigned by netbird = 100.82.c.ccc - `ping -I wt0 100.82.c.ccc` => all packets are lost ## Tests only on machine C: ### terminal 1 ``` sudo tcpdump -i any -nn host 100.82.c.ccc tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 17:34:32.817064 lo In IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 1, length 64 17:34:33.833506 lo In IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 2, length 64 17:34:34.857515 lo In IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 3, length 64 17:34:35.881541 lo In IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 4, length 64 17:34:36.905549 lo In IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 5, length 64 17:34:37.929549 lo In IP 100.82.c.ccc > 100.82.c.ccc: ICMP echo request, id 3714, seq 6, length 64 6 packets captured 13 packets received by filter 0 packets dropped by kernel ``` ### terminal 2: ``` ping -I wt0 100.82.c.ccc --- 100.82.c.ccc ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 5112ms ``` ## Tests using machine A and C: ### terminal 1 (machine A): ``` sudo tcpdump -i any -nn host 100.82.c.ccc tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 17:41:09.234046 wt0 In IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 1, length 64 17:41:09.234158 wt0 Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 1, length 64 17:41:10.258846 wt0 In IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 2, length 64 17:41:10.258883 wt0 Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 2, length 64 17:41:11.282977 wt0 In IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 3, length 64 17:41:11.283021 wt0 Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 3, length 64 17:41:12.306984 wt0 In IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 4, length 64 17:41:12.307054 wt0 Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 4, length 64 17:41:13.331089 wt0 In IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 5, length 64 17:41:13.331155 wt0 Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 5, length 64 17:41:14.355046 wt0 In IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 6, length 64 17:41:14.355082 wt0 Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 6, length 64 17:41:15.378944 wt0 In IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 7, length 64 17:41:15.378977 wt0 Out IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 7, length 64 14 packets captured 15 packets received by filter 0 packets dropped by kernel ``` `netbird status -d`: ``` machinec.netbird.cloud: NetBird IP: 100.82.c.ccc Public key: ... Status: Connected -- detail -- Connection type: P2P ICE candidate (Local/Remote): host/prflx ICE candidate endpoints (Local/Remote): <IP>:51820/<IP>:51820 Relay server address: Last connection update: 6 hours, 31 minutes ago Last WireGuard handshake: 23 seconds ago Transfer status (received/sent) 103.1 KiB/40.8 KiB Quantum resistance: true Routes: - Latency: 15.294023ms OS: linux/arm64 Daemon version: 0.29.4 CLI version: 0.29.4 Management: Connected to https://api.netbird.io:443 Signal: Connected to https://signal.netbird.io:443 Relays: [stun:stun.netbird.io:5555] is Available [turns:turn.netbird.io:443?transport=tcp] is Available Nameservers: [1.1.1.1:53, 1.0.0.1:53] for [.] is Available FQDN: aaa.netbird.cloud NetBird IP: 100.82.a.aaa/16 Interface type: Kernel Quantum resistance: true Routes: - Peers count: 1/4 Connected ``` ### terminal 1 (machine C): ``` sudo tcpdump -i any -nn host 100.82.a.aaa tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 17:41:09.224558 wt0 Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 1, length 64 17:41:09.239350 wt0 In IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 1, length 64 17:41:10.249497 wt0 Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 2, length 64 17:41:10.263987 wt0 In IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 2, length 64 17:41:11.273462 wt0 Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 3, length 64 17:41:11.288227 wt0 In IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 3, length 64 17:41:12.297440 wt0 Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 4, length 64 17:41:12.312155 wt0 In IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 4, length 64 17:41:13.321538 wt0 Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 5, length 64 17:41:13.336378 wt0 In IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 5, length 64 17:41:14.345542 wt0 Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 6, length 64 17:41:14.360319 wt0 In IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 6, length 64 17:41:15.369540 wt0 Out IP 100.82.c.ccc > 100.82.a.aaa: ICMP echo request, id 3730, seq 7, length 64 17:41:15.384098 wt0 In IP 100.82.a.aaa > 100.82.c.ccc: ICMP echo reply, id 3730, seq 7, length 64 14 packets captured 15 packets received by filter 0 packets dropped by kernel ``` ### terminal 2 (machine C): ``` ping -I wt0 100.82.a.aaa --- 100.82.a.aaa ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 6145ms ``` `netbird status -d`: ``` machinea.netbird.cloud: NetBird IP: 100.82.a.aaa Public key: ... Status: Connected -- detail -- Connection type: P2P ICE candidate (Local/Remote): srflx/host ICE candidate endpoints (Local/Remote): <IP>:51820/<IP>:51820 Relay server address: Last connection update: 6 hours, 27 minutes ago Last WireGuard handshake: 29 seconds ago Transfer status (received/sent) 19.7 KiB/63.5 KiB Quantum resistance: true Routes: - Latency: 15.325518ms OS: linux/amd64 Daemon version: 0.29.4 CLI version: 0.29.4 Management: Connected to https://api.netbird.io:443 Signal: Connected to https://signal.netbird.io:443 Relays: [stun:stun.netbird.io:5555] is Available [turns:turn.netbird.io:443?transport=tcp] is Available Nameservers: [1.1.1.1:53, 1.0.0.1:53] for [.] is Available FQDN: ccc.netbird.cloud NetBird IP: 100.82.c.ccc/16 Interface type: Kernel Quantum resistance: true Routes: - Peers count: 1/4 Connected ``` Note: Also, no way to SSH into machine C over netbird.
Author
Owner

@yakaviuk commented on GitHub (Dec 4, 2024):

Same issue for me,
I have few macbooks and mac mini which are connected to Netbird (self-hosted) network.
According to Netbird policy, ALL (TCP, UDP, ICMP) are allowed.
But ping and VNC (port 5900) connection doesn't work between macbooks and mac mini.

(but if they are in one local network without Netbird - ping, SSH and VNC work fine)

<!-- gh-comment-id:2517303730 --> @yakaviuk commented on GitHub (Dec 4, 2024): Same issue for me, I have few macbooks and mac mini which are connected to Netbird (self-hosted) network. According to Netbird policy, ALL (TCP, UDP, ICMP) are allowed. But ping and VNC (port 5900) connection doesn't work between macbooks and mac mini. (but if they are in one local network without Netbird - ping, SSH and VNC work fine)
Author
Owner

@nazarewk commented on GitHub (Apr 28, 2025):

Hello @pilinux,

We're currently reviewing our open issues and would like to verify if this problem still exists in the latest NetBird version.

Could you please confirm if the issue is still there?

We may close this issue temporarily if we don't hear back from you within 2 weeks, but feel free to reopen it with updated information.

Thanks for your contribution to improving the project!

<!-- gh-comment-id:2835670382 --> @nazarewk commented on GitHub (Apr 28, 2025): Hello @pilinux, We're currently reviewing our open issues and would like to verify if this problem still exists in the [latest NetBird version](https://github.com/netbirdio/netbird/releases). Could you please confirm if the issue is still there? We may close this issue temporarily if we don't hear back from you within **2 weeks**, but feel free to reopen it with updated information. Thanks for your contribution to improving the project!
Author
Owner

@pilinux commented on GitHub (May 1, 2025):

Image

the problem is still there! u can test them easily. install on your mac. then install on an ubuntu (I used 22.04.5 LTS). they don't talk to each other even though both are connected to netbird platform.

Note: I switched to tailscale long time ago. Everything works as they should. I installed netbird again just to check whether this issue is fixed in the latest release or not. Maybe it is not related to client software, but on netbird cloud side?

<!-- gh-comment-id:2846226783 --> @pilinux commented on GitHub (May 1, 2025): <img width="452" alt="Image" src="https://github.com/user-attachments/assets/041a71ad-beee-4f8a-af69-d206fdd1a8d5" /> the problem is still there! u can test them easily. install on your mac. then install on an ubuntu (I used 22.04.5 LTS). they don't talk to each other even though both are connected to netbird platform. Note: I switched to tailscale long time ago. Everything works as they should. I installed netbird again just to check whether this issue is fixed in the latest release or not. Maybe it is not related to client software, but on netbird cloud side?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#5571