netbird icon indicating copy to clipboard operation
netbird copied to clipboard

Peers in the same LAN are using public internet to connect.

Open Youwenqwq opened this issue 6 months ago • 6 comments
trafficstars

Update May, 4 2025: I found that while tailscale uses UPnP, PCP and NAT-PMP to try to open ports, NetBird doesn't. This means that in my network below, testserver isn't able to directly access the host laptop that is under the NAT of the router openwrt. I guess this is the main reason why it uses public IP to communicate.

Describe the problem

Recently I have switched my VPN software from tailscale to netbird. I am amazed by the Networks and powerful web panel Netbird is producing. However, I found that when using Netbird, two peers with different VLANs might build P2P connections through public Internet instead of connecting directly in LAN address, while this won't happen in tailscale.

Expected behavior

Two peers would create P2P connections using LAN IP.

Are you using NetBird Cloud?

No, I'm using self-hosted NetBird service.

NetBird version

0.43.1

Is any other VPN software installed?

Yes, Tailscale. But they aren't running when testing netbird.

Debug output

Peers detail:
 aws.anon-szr8O.domain:
  NetBird IP: 100.75.62.188
  Public key: R9k1i3+mhdiXvJBGWD0cMxh1U8NVAVCxUjxFH3+Ezm4=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): srflx/srflx
  ICE candidate endpoints (Local/Remote): 198.51.100.0:2503/198.51.100.1:51820
  Relay server address: rel://vpn.anon-wQzkR.domain:33080
  Last connection update: 1 minute, 28 seconds ago
  Last WireGuard handshake: 1 minute, 29 seconds ago
  Transfer status (received/sent) 92 B/276 B
  Quantum resistance: false
  Networks: -
  Latency: 34.3508ms

 openwrt.anon-szr8O.domain:
  NetBird IP: 100.75.71.12
  Public key: gzFExSImZUjbZiiQEeRTm8NfamuZTpAjokEeiLMit2k=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): host/srflx
  ICE candidate endpoints (Local/Remote): 127.0.0.1:51820/198.51.100.0:2586
  Relay server address: rel://vpn.anon-wQzkR.domain:33080
  Last connection update: 1 minute, 27 seconds ago
  Last WireGuard handshake: 1 minute, 29 seconds ago
  Transfer status (received/sent) 156 B/244 B
  Quantum resistance: false
  Networks: -
  Latency: 8.0082ms

 kirakira.anon-szr8O.domain:
  NetBird IP: 100.75.74.196
  Public key: +8UMb8RWhTYpv23jTOGgN+CsbN9OOTOgOk1h9OkGAi0=
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rel://vpn.anon-wQzkR.domain:33080
  Last connection update: 1 minute, 29 seconds ago
  Last WireGuard handshake: 1 minute, 29 seconds ago
  Transfer status (received/sent) 188 B/276 B
  Quantum resistance: false
  Networks: -
  Latency: 0s

 mobile.anon-szr8O.domain:
  NetBird IP: 100.75.93.92
  Public key: I2d+YhyLIDJ039d2m2K5nHt8pb+UE637A+CnzeqFQWo=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): host/host
  ICE candidate endpoints (Local/Remote): 169.254.226.220:51820/192.168.10.39:51820
  Relay server address: rel://vpn.anon-wQzkR.domain:33080
  Last connection update: 1 minute, 27 seconds ago
  Last WireGuard handshake: 1 minute, 28 seconds ago
  Transfer status (received/sent) 92 B/276 B
  Quantum resistance: false
  Networks: -
  Latency: 82.0498ms

 debiannet.anon-szr8O.domain:
  NetBird IP: 100.75.99.152
  Public key: U5ovfyRBXMf3LDwpneDUwIDyHWFSJFzOgL+aNgzl8hM=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): srflx/srflx
  ICE candidate endpoints (Local/Remote): 198.51.100.0:2503/198.51.100.2:36243
  Relay server address: rel://vpn.anon-wQzkR.domain:33080
  Last connection update: 1 minute, 27 seconds ago
  Last WireGuard handshake: 1 minute, 29 seconds ago
  Transfer status (received/sent) 252 B/372 B
  Quantum resistance: false
  Networks: 192.168.9.0/24
  Latency: 42.8368ms

 testserver.anon-szr8O.domain:
  NetBird IP: 100.75.140.14
  Public key: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): host/srflx
  ICE candidate endpoints (Local/Remote): 192.168.10.205:51820/198.51.100.3:11865
  Relay server address: rel://vpn.anon-wQzkR.domain:33080
  Last connection update: 1 minute, 27 seconds ago
  Last WireGuard handshake: 1 minute, 29 seconds ago
  Transfer status (received/sent) 92 B/276 B
  Quantum resistance: false
  Networks: 192.168.0.0/24, 198.51.100.4/16
  Latency: 26.5328ms

Events:
  [INFO] SYSTEM (57004cb9-069a-46b1-95ed-d2925c7ca30f)
    Message: Network map updated
    Time: 10 minutes, 22 seconds ago
  [INFO] SYSTEM (0d927b75-c71d-47e3-b4fb-3f5047e0cea3)
    Message: Network map updated
    Time: 9 minutes, 6 seconds ago
  [INFO] SYSTEM (5088c485-5026-4ffb-a68a-0abad87cb633)
    Message: Network map updated
    Time: 7 minutes, 54 seconds ago
  [INFO] SYSTEM (c966f37d-8a7d-45dc-b2d6-392614f8295e)
    Message: Network map updated
    Time: 6 minutes, 44 seconds ago
  [INFO] SYSTEM (e7dcdb20-9b00-4758-a96d-c5c450fe1e21)
    Message: Network map updated
    Time: 5 minutes, 30 seconds ago
  [INFO] SYSTEM (3adc1913-8678-4c22-a49d-6642c26a19ab)
    Message: Network map updated
    Time: 4 minutes, 14 seconds ago
  [INFO] SYSTEM (d79a23fb-0508-4db8-b091-4a696c14b7a1)
    Message: Network map updated
    Time: 2 minutes, 58 seconds ago
  [INFO] SYSTEM (3a2935ca-714e-4148-b677-d8834f67cc32)
    Message: Network map updated
    Time: 1 minute, 43 seconds ago
  [INFO] SYSTEM (96b6e4af-1f17-44f3-9ec0-86e2d13001ed)
    Message: Network map updated
    Time: 1 minute, 29 seconds ago
  [INFO] SYSTEM (f17ab421-466a-4383-bedf-cd2d7fc8b561)
    Message: Network map updated
    Time: 28 seconds ago
OS: windows/amd64
Daemon version: 0.43.1
CLI version: 0.43.1
Management: Connected to https://vpn.anon-wQzkR.domain:443
Signal: Connected to https://vpn.anon-wQzkR.domain:443
Relays:
  [stun:turn.anon-wQzkR.domain:3478] is Available
  [turn:turn.anon-wQzkR.domain:3478?transport=udp] is Available
  [rel://vpn.anon-wQzkR.domain:33080] is Available
Nameservers:
  [192.168.9.4:53] for [anon-88hTz.domain] is Available
FQDN: laptop.anon-szr8O.domain
NetBird IP: 100.75.11.17/16
Interface type: Userspace
Quantum resistance: false
Networks: -
Forwarding rules: 0
Peers count: 6/6 Connected

As well as the file created by

netbird debug for 1m -AS

netbird.debug.1648260844.zip

Additional context

In the Debug output above,openwrt(LAN IP 192.168.10.1) is the router of a LAN, my device currently outputing these logs is also under this router, named laptop. The openwrt and the testserver have diffferent public IP address and ISP due to some network policy, but they can access each other directly using local IP. In this situation,host/srflx is causing unnecessary latency and bandwidth limit.

My local network might be a little complex, so I will provide a description generated by AI for you to better understand.

[ Local Network (192.168.10.0/24) ]
│
├── [phone]       IP: 192.168.10.39
├── [laptop]      IP: 192.168.10.205
└── [openwrt]      LAN IP: 192.168.10.1 (Gateway)
                              WAN IP: 10.136.141.0
│
[ Connected via intermediate network infrastructure in a same building ]
│
[ Remote Network (10.20.72.0/24) ]
│
└── [testserver]  IP: 10.20.72.25
                  Gateway: 10.20.72.1
Key Notes:
​​Local Network​​:
Devices phone and laptop connect to the router (192.168.10.1) via LAN.
The router's WAN interface is configured with 10.136.141.25 (gateway: 10.136.141.0).
​​Cross-Network Communication​​:
The router's WAN IP (10.136.141.25) and testserver (10.20.72.25) can directly communicate via intermediate infrastructure (e.g., routers, firewalls, or dedicated links) in the same building, they are in a larger LAN.
Mutual ping and service access confirm proper routing/NAT configuration.
​​IP Addressing​​:
Local network uses private IP range 192.168.10.0/24.
Remote network uses 10.20.72.0/24, distinct from the router's WAN subnet (10.136.141.0/24).

Have you tried these troubleshooting steps?

  • [√] 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

Youwenqwq avatar May 03 '25 19:05 Youwenqwq

Are you passing the LAN network as a 'network' to these clients?

I found that when I passed a network via netbird, it would put a route at a lower metric than the LAN gateway to hit that remote network, causing everything to go through a relay.

1nerdyguy avatar May 06 '25 15:05 1nerdyguy

What you are observing can happen when the remote IP connection attempt answers (for whatever reason) before the local connection.

After checking your laptop -> testserver connections logs

I see it discovered 2 local IP candidates 192.168.0.39 & 10.20.72.25, but somehow went with the last (public IP) candidate 198.51.100.4:11865:

22883:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp6 host [fd99:4256:e9a5:0:be24:11ff:fed9:9138]:51820
22884:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 host 192.168.0.39:51820
22886:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp6 host [fd77:944b:3bb4:0:be24:11ff:fed9:9138]:51820
22887:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 host 10.20.72.25:51820
22894:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 srflx 198.51.100.4:51820 related 0.0.0.0:51820
22895:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 srflx 198.51.100.4:11865 related 0.0.0.0:51820
...
23083:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:329: selected candidate pair [local <-> remote] -> [udp4 host 192.168.10.205:51820 <-> udp4 srflx 198.51.100.4:11865 related 0.0.0.0:51820], peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=

I have also noticed that different VLANs have different public IPs (the anonymized .3 vs .4 IPs).

  1. Are you sure the VLANs can talk to each other? Can you access either of 192.168.0.39 10.20.72.25 directly from your laptop?
  2. Can you try running testserver with netbird up --external-ip-map 192.168.0.39,10.20.72.25 to see if it helps? be sure to netbird down first and remember to clear it later on with netbird up --external-ip-map "".
  3. You can also try to debug the ICE negotiation with a separate debugging configuration to get more info. You can find the required configuration in the docs.

nazarewk avatar May 06 '25 16:05 nazarewk

What you are observing can happen when the remote IP connection attempt answers (for whatever reason) before the local connection.

After checking your laptop -> testserver connections logs

I see it discovered 2 local IP candidates 192.168.0.39 & 10.20.72.25, but somehow went with the last (public IP) candidate 198.51.100.4:11865:

22883:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp6 host [fd99:4256:e9a5:0:be24:11ff:fed9:9138]:51820
22884:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 host 192.168.0.39:51820
22886:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp6 host [fd77:944b:3bb4:0:be24:11ff:fed9:9138]:51820
22887:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 host 10.20.72.25:51820
22894:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 srflx 198.51.100.4:51820 related 0.0.0.0:51820
22895:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 srflx 198.51.100.4:11865 related 0.0.0.0:51820
...
23083:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:329: selected candidate pair [local <-> remote] -> [udp4 host 192.168.10.205:51820 <-> udp4 srflx 198.51.100.4:11865 related 0.0.0.0:51820], peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=

I have also noticed that different VLANs have different public IPs (the anonymized .3 vs .4 IPs).

  1. Are you sure the VLANs can talk to each other? Can you access either of 192.168.0.39 10.20.72.25 directly from your laptop?
  2. Can you try running testserver with netbird up --external-ip-map 192.168.0.39,10.20.72.25 to see if it helps? be sure to netbird down first and remember to clear it later on with netbird up --external-ip-map "".
  3. You can also try to debug the ICE negotiation with a separate debugging configuration to get more info. You can find the required configuration in the docs.

Hi there, thanks for your reply! I can confirm that my laptop can access the test server directly in this environment, as I’m able to connect to it via SSH and access an HTTP website on it without using any proxy.

My network setup might be a bit complex. The test server has two network interfaces: one at 192.168.0.39 for Internet access, and another at 10.20.72.25 for local network access. On my laptop, only 10.20.72.25 is directly reachable.

The reason there are two different public IP addresses is that I’m on a campus network where every device requires additional authentication to access the Internet. The campus gateway also offers multiple ISPs to choose from. The test server and my laptop use different accounts for authentication, which results in different public IPs. However, this doesn’t affect local network access.

Sorry for the delay — due to some personal matters, I’m currently unable to do further testing. I’ll try to provide more information once I am available, maybe in 1-2 days.☺️

Youwenqwq avatar May 06 '25 17:05 Youwenqwq

What you are observing can happen when the remote IP connection attempt answers (for whatever reason) before the local connection.

After checking your laptop -> testserver connections logs

I see it discovered 2 local IP candidates 192.168.0.39 & 10.20.72.25, but somehow went with the last (public IP) candidate 198.51.100.4:11865:

22883:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp6 host [fd99:4256:e9a5:0:be24:11ff:fed9:9138]:51820
22884:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 host 192.168.0.39:51820
22886:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp6 host [fd77:944b:3bb4:0:be24:11ff:fed9:9138]:51820
22887:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 host 10.20.72.25:51820
22894:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 srflx 198.51.100.4:51820 related 0.0.0.0:51820
22895:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM= -> udp4 srflx 198.51.100.4:11865 related 0.0.0.0:51820
...
23083:2025-05-04T02:37:49+08:00 DEBG [peer: LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=] client/internal/peer/worker_ice.go:329: selected candidate pair [local <-> remote] -> [udp4 host 192.168.10.205:51820 <-> udp4 srflx 198.51.100.4:11865 related 0.0.0.0:51820], peer LBonNnujgCfjIsCcDCwdVbnCubzPxZ49lThlkaXI5iM=

I have also noticed that different VLANs have different public IPs (the anonymized .3 vs .4 IPs).

  1. Are you sure the VLANs can talk to each other? Can you access either of 192.168.0.39 10.20.72.25 directly from your laptop?
  2. Can you try running testserver with netbird up --external-ip-map 192.168.0.39,10.20.72.25 to see if it helps? be sure to netbird down first and remember to clear it later on with netbird up --external-ip-map "".
  3. You can also try to debug the ICE negotiation with a separate debugging configuration to get more info. You can find the required configuration in the docs.

Hi!

Sorry for a mistake in the original issue: the correct router's WAN IP is 10.136.141.0, and its WAN Gateway is 10.136.140.0. Also, the router (openwrt) has netbird client installed.

Although I have edited the original issue, it might still be a bit disorganized. But the further informations below should be better😉:

For point 2: setting external-ip-map on testserver doesn't help.

For point 3:

router <-> testserver

I have checked the ICE Connection debug log and netbird client log on testserver, and I found that the router (peer name: openwrt) actually provided its udp4 host with its information below (peer ID and time are omitted for clearer text):

DEBG [peer: xxx] client/internal/peer/worker_ice.go:161: OnRemoteCandidate from peer xxx -> udp4 host 10.136.141.0:51820

However, testserver finally chosed srflx endpoint to establish connection, and ICE debug log shows no appearance of 10.136.141.0 and any WARNINGs that may relates to it. This may indicates that ICE connetcions couldn't be established directly between 10.136.141.0 and 10.20.72.25.

Other informations about connectivity:

  1. 10.136.141.0 can ping and access websites hosted on 10.20.72.25, and running traceroute 10.20.72.25 on 10.136.141.0 only shows one hop directly to 10.20.72.25.
  2. There should be no UDP blocking between 10.20.72.25 and 10.136.141.0, since Moonlight streaming works normally (with UDP ports 47990-48010). Also, changing testserver's and router's wireguard port to 47990 doesn't help.

laptop <-> testserver

Netbird client log on testserver shows no sign of 10.136.141.0 endpoint. They finally connected through srflx.

This might be the reason I mentioned in the beginning of the original issue:

I found that while tailscale uses UPnP, PCP and NAT-PMP to try to open ports, NetBird doesn't. This means that in my network below, testserver isn't able to directly access the host laptop that is under the NAT of the router openwrt.


Additional infos

After checking issues under netbird repository, I found that some subnet settings in Netbird Networks might affect P2P connectivity between peers, so I disabled all network routes to avoid unexcepted influence.

Other questions

  1. Why would two clients under the same LAN showing different ICE endpoints? For example:

Peer A (IP: 10.20.72.25)

  ICE candidate (Local/Remote): srflx/host
  ICE candidate endpoints (Local/Remote): 198.18.0.1:3826/10.20.72.26:51820

Peer B (IP: 10.20.72.26, Gateway: 10.20.72.25)

  ICE candidate (Local/Remote): host/host
  ICE candidate endpoints (Local/Remote): 10.20.72.26:51820/10.20.72.25:51820

Running iperf3 speedtests indicates that they actually connects each other in local network.

  1. Tailscale seems to build direct connections across different VLANs. In my situation, it builds direct connections between router and testserver, that is, 10.136.141.0 and 10.20.72.25. Both using port 41641 (tailscale default wireguard port). Running tailscale ping testserver on router displays this:
pong from testserver (100.103.46.47) via 10.20.72.25:41641 in 1ms

And tailscale web panel shows two endpoints: 10.136.141.0:41641 and 10.20.72.25:41641

Again thanks for help!

Youwenqwq avatar May 07 '25 09:05 Youwenqwq

@Youwenqwq could you upload a non-anonymized debug bundle after running NetBird with both trace log level and PIONS_LOG_DEBUG=all for a few minutes from both Peers involved?

PS: the resulting key is a non-sensitive value identifying a file in our internal storage system, so is safe to share here.

nazarewk avatar May 14 '25 07:05 nazarewk

@Youwenqwq could you upload a non-anonymized debug bundle after running NetBird with both trace log level and PIONS_LOG_DEBUG=all for a few minutes from both Peers involved?

PS: the resulting key is a non-sensitive value identifying a file in our internal storage system, so is safe to share here.

Hi! I'm currently unable to build a test setup, but I’ll update once I can.

Also, I came across a post in a Chinese forum where someone mentioned that NetBird may not broadcast all endpoint IPs to the remote peer during NAT traversal — unlike Tailscale. Not sure if that's related, but maybe it's helpful 🤔

Youwenqwq avatar May 22 '25 12:05 Youwenqwq