SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-07-02 04:02:09 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

No direct connection even if peers are in the same network #740

New Issue
Closed
opened 2025-11-20 05:16:44 -05:00 by saavagebueno · 7 comments
saavagebueno commented 2025-11-20 05:16:44 -05:00
Owner
Copy Link

Originally created by @jvanbruegge on GitHub (Mar 27, 2024).

Describe the problem

I have deployed netbird on server in the public internet. Two peers are at home behind NAT (from the view of the server), but in the same LAN.

Is this expected to result in a relayed connection? I was hoping this would give a direct connection between the two peers.

Are you using NetBird Cloud?

Self-hosted

NetBird version

0.26.3

NetBird status -d output:

Peer two from the view of peer one.

caladan.net.cerberus-systems.de:
  NetBird IP: 100.107.70.54
  Public key: OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE=
  Status: Connected
  -- detail --
  Connection type: Relayed
  Direct: false
  ICE candidate (Local/Remote): relay/srflx
  ICE candidate endpoints (Local/Remote): <IP>:51882/217.44.187.166:51882
  Last connection update: 2024-03-27 13:30:42
  Last WireGuard handshake: 2024-03-27 14:49:05
  Transfer status (received/sent) 3.8 KiB/12.7 KiB
  Quantum resistance: false
  Routes: -
Originally created by @jvanbruegge on GitHub (Mar 27, 2024). **Describe the problem** I have deployed netbird on server in the public internet. Two peers are at home behind NAT (from the view of the server), but in the same LAN. Is this expected to result in a relayed connection? I was hoping this would give a direct connection between the two peers. **Are you using NetBird Cloud?** Self-hosted **NetBird version** 0.26.3 **NetBird status -d output:** Peer two from the view of peer one. ``` caladan.net.cerberus-systems.de: NetBird IP: 100.107.70.54 Public key: OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= Status: Connected -- detail -- Connection type: Relayed Direct: false ICE candidate (Local/Remote): relay/srflx ICE candidate endpoints (Local/Remote): <IP>:51882/217.44.187.166:51882 Last connection update: 2024-03-27 13:30:42 Last WireGuard handshake: 2024-03-27 14:49:05 Transfer status (received/sent) 3.8 KiB/12.7 KiB Quantum resistance: false Routes: - ```
saavagebueno commented 2025-11-20 05:16:45 -05:00
Author
Owner
Copy Link

@pascal-fischer commented on GitHub (Mar 27, 2024):

Hi @jvanbruegge, can you share some debug logs from one (or both) of the peers? to see why ICE is choosing a relayed connection over the P2P one.

@pascal-fischer commented on GitHub (Mar 27, 2024): Hi @jvanbruegge, can you share some [debug logs](https://docs.netbird.io/how-to/troubleshooting-client) from one (or both) of the peers? to see why ICE is choosing a relayed connection over the P2P one.
saavagebueno commented 2025-11-20 05:16:45 -05:00
Author
Owner
Copy Link

@jvanbruegge commented on GitHub (Mar 27, 2024):

I found these lines in the debug logs of peer one (192.168.1.145 is the LAN IP of peer two):

2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:255: trying to connect to peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE=
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:286: connection offer sent to peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE=, waiting for the confirmation
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:705: OnRemoteAnswer from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= on status Disconnected
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:307: received connection confirmation from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= running version 0.26.2 and with remote WireGuard listen port 51820
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:603: peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= ICE ConnectionState has changed to Checking
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:562: discovered local candidate udp4 host 192.168.1.75:51820
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:562: discovered local candidate udp4 host 192.168.56.1:51820
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:562: discovered local candidate udp4 host 192.168.1.77:51820
+ 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:719: OnRemoteCandidate from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= -> udp4 host 192.168.1.145:51820
+ 2024-03-27T18:11:36Z DEBG iface/bind/udp_mux.go:346: ICE: registered 192.168.1.145:51820 for QBbcWttbcskPPDOS
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:255: trying to connect to peer aqlPE89LUf4SF+bsXRiX7RaT4ef5teboEoJsWZYk0mQ=
2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:719: OnRemoteCandidate from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= -> udp4 srflx 217.44.187.166:51820 related 0.0.0.0:51820
2024-03-27T18:11:36Z DEBG iface/bind/udp_mux.go:346: ICE: registered 217.44.187.166:51820 for QBbcWttbcskPPDOS

Here is the full log of peer one: netbird.log

@jvanbruegge commented on GitHub (Mar 27, 2024): I found these lines in the debug logs of peer one (`192.168.1.145` is the LAN IP of peer two): ```diff 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:255: trying to connect to peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:286: connection offer sent to peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE=, waiting for the confirmation 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:705: OnRemoteAnswer from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= on status Disconnected 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:307: received connection confirmation from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= running version 0.26.2 and with remote WireGuard listen port 51820 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:603: peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= ICE ConnectionState has changed to Checking 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:562: discovered local candidate udp4 host 192.168.1.75:51820 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:562: discovered local candidate udp4 host 192.168.56.1:51820 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:562: discovered local candidate udp4 host 192.168.1.77:51820 + 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:719: OnRemoteCandidate from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= -> udp4 host 192.168.1.145:51820 + 2024-03-27T18:11:36Z DEBG iface/bind/udp_mux.go:346: ICE: registered 192.168.1.145:51820 for QBbcWttbcskPPDOS 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:255: trying to connect to peer aqlPE89LUf4SF+bsXRiX7RaT4ef5teboEoJsWZYk0mQ= 2024-03-27T18:11:36Z DEBG client/internal/peer/conn.go:719: OnRemoteCandidate from peer OyaccKy8y/+itamr2Y9EGJ/iU4PCBuQtgDxdSVGHXHE= -> udp4 srflx 217.44.187.166:51820 related 0.0.0.0:51820 2024-03-27T18:11:36Z DEBG iface/bind/udp_mux.go:346: ICE: registered 217.44.187.166:51820 for QBbcWttbcskPPDOS ``` Here is the full log of peer one: [netbird.log](https://github.com/netbirdio/netbird/files/14779575/netbird.log)
saavagebueno commented 2025-11-20 05:16:45 -05:00
Author
Owner
Copy Link

@pascal-fischer commented on GitHub (Mar 28, 2024):

So it discovers the proper candidate. I am unable to see the full logs, I only see a login request from up command could you check again please?

@pascal-fischer commented on GitHub (Mar 28, 2024): So it discovers the proper candidate. I am unable to see the full logs, I only see a login request from up command could you check again please?
saavagebueno commented 2025-11-20 05:16:45 -05:00
Author
Owner
Copy Link

@jvanbruegge commented on GitHub (Mar 28, 2024):

Oops sorry, here is the correct file:
netbird.log

@jvanbruegge commented on GitHub (Mar 28, 2024): Oops sorry, here is the correct file: [netbird.log](https://github.com/netbirdio/netbird/files/14789481/netbird.log)
saavagebueno commented 2025-11-20 05:16:45 -05:00
Author
Owner
Copy Link

@pascal-fischer commented on GitHub (Mar 28, 2024):

Thanks! So it is discovering the proper candidates but still deciding for relay. From the timestamps I see that the decision is made quite quick. We are currently evaluating if we should increase the timeouts. It is a longshot but are you up for testing a different client? https://github.com/netbirdio/netbird/tree/eval/higher-timeouts If you are on Slack I can build you a binary and send it to you, or if you comfortable with it you can build it from the branch yourself. I can send you the instructions on how to build and run.

@pascal-fischer commented on GitHub (Mar 28, 2024): Thanks! So it is discovering the proper candidates but still deciding for relay. From the timestamps I see that the decision is made quite quick. We are currently evaluating if we should increase the timeouts. It is a longshot but are you up for testing a different client? [https://github.com/netbirdio/netbird/tree/eval/higher-timeouts](https://github.com/netbirdio/netbird/tree/eval/higher-timeouts) If you are on Slack I can build you a binary and send it to you, or if you comfortable with it you can build it from the branch yourself. I can send you the instructions on how to build and run.
saavagebueno commented 2025-11-20 05:16:46 -05:00
Author
Owner
Copy Link

@jvanbruegge commented on GitHub (Mar 28, 2024):

I actually have a hard time reproducing this. I've had to restart netbird and now the connection is indeed P2P. I will try to put some load on the system to see if this triggers the relay again.

@jvanbruegge commented on GitHub (Mar 28, 2024): I actually have a hard time reproducing this. I've had to restart netbird and now the connection is indeed P2P. I will try to put some load on the system to see if this triggers the relay again.
saavagebueno commented 2025-11-20 05:16:46 -05:00
Author
Owner
Copy Link

@jvanbruegge commented on GitHub (Mar 28, 2024):

Yeah, even with 100% CPU and 90% memory load I now get direct P2P connections even for stuff that I actually would not expect (another server that sits behind another NAT).

So it being a race conditions sounds reasonable? But apparently I have no way to test this.

@jvanbruegge commented on GitHub (Mar 28, 2024): Yeah, even with 100% CPU and 90% memory load I now get direct P2P connections even for stuff that I actually would not expect (another server that sits behind another NAT). So it being a race conditions sounds reasonable? But apparently I have no way to test this.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#740
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?