SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-05-13 03:31:59 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Try using connection candidates with wg before starting a proxy #20

New Issue
Closed
opened 2025-11-20 05:04:58 -05:00 by saavagebueno · 3 comments
saavagebueno commented 2025-11-20 05:04:58 -05:00
Owner
Copy Link

Originally created by @stv0g on GitHub (Jun 15, 2021).

Currently, all Wireguard data is passed through the Wireguard proxy even though the connection candidates could be directly passed as peers to Wireguard. I think we only really need the proxy if a TCP TURN relay is used.

Originally created by @stv0g on GitHub (Jun 15, 2021). Currently, all Wireguard data is passed through the Wireguard proxy even though the connection candidates could be directly passed as peers to Wireguard. I think we only really need the proxy if a TCP TURN relay is used.
saavagebueno commented 2025-11-20 05:04:59 -05:00
Author
Owner
Copy Link

@braginini commented on GitHub (Jun 15, 2021):

Thanks, @stv0g for the suggestion.
It is generally a good idea to avoid using a local proxy for the Wg traffic, however, in our case it won't be a quick change.
Let me explain why.

  1. We allow each peer to have multiple connections simultaneously.
  2. We use plain pion/ice that has a hole punching logic embedded and handled by the framework. And it provides a new random UDP port after punching.

So, as I understood you correctly, we would always need to update the Wireguard listen port with a new port (from #2), this will interrupt other connections (#1) and the logic becomes quite complex.

We had an idea of taking control of a socket used by pion/ice and completely getting rid of a local proxy. We will be looking into that.
For now, what we have implemented so far was the quickest (implementation-wise) and quite a good solution.

We will be also posting some benchmarks Pure Wireguard vs Wiretrustee.

@braginini commented on GitHub (Jun 15, 2021): Thanks, @stv0g for the suggestion. It is generally a good idea to avoid using a local proxy for the Wg traffic, however, in our case it won't be a quick change. Let me explain why. 1. We allow each peer to have multiple connections simultaneously. 2. We use plain pion/ice that has a hole punching logic embedded and handled by the framework. And it provides a new random UDP port after punching. So, as I understood you correctly, we would always need to update the Wireguard listen port with a new port (from #2), this will interrupt other connections (#1) and the logic becomes quite complex. We had an idea of taking control of a socket used by pion/ice and completely getting rid of a local proxy. We will be looking into that. For now, what we have implemented so far was the quickest (implementation-wise) and quite a good solution. We will be also posting some benchmarks Pure Wireguard vs Wiretrustee.
saavagebueno commented 2025-11-20 05:04:59 -05:00
Author
Owner
Copy Link

@stv0g commented on GitHub (Jun 15, 2021):

Hi @braginini

thanks for the detailed explanation.

So, as I understood you correctly, we would always need to update the Wireguard listen port with a new port (from #2), this will interrupt other connections (#1) and the logic becomes quite complex.

I agree. Maybe AgentConfig.PortMin and AgentConfig.PortMax could be used to restrict pion/ice to a single port which is used as Wireguards ListenPort?
pion/ice will probably fail as the port is already bound by Wireguard.
So Wireguard would need to be stopped during the connectivity checks and hole punching.

Indeed not a trivial change.

I thought about using iptables/netfilter with a redirect rule pointing to the chosen candidate pair.
But that wouldnt be portable :/

We will be also posting some benchmarks Pure Wireguard vs Wiretrustee.

I would be very much interested in that!

@stv0g commented on GitHub (Jun 15, 2021): Hi @braginini thanks for the detailed explanation. > So, as I understood you correctly, we would always need to update the Wireguard listen port with a new port (from #2), this will interrupt other connections (#1) and the logic becomes quite complex. I agree. Maybe `AgentConfig.PortMin` and `AgentConfig.PortMax` could be used to restrict pion/ice to a single port which is used as Wireguards ListenPort? pion/ice will probably fail as the port is already bound by Wireguard. So Wireguard would need to be stopped during the connectivity checks and hole punching. Indeed not a trivial change. I thought about using iptables/netfilter with a redirect rule pointing to the chosen candidate pair. But that wouldnt be portable :/ > We will be also posting some benchmarks Pure Wireguard vs Wiretrustee. I would be very much interested in that!
saavagebueno commented 2025-11-20 05:04:59 -05:00
Author
Owner
Copy Link

@braginini commented on GitHub (Jul 2, 2021):

Hey @stv0g
We have released a new version and run some performance tests.
We have also removed proxy usage for some cases. I'm closing this issue.
See this for details:
https://www.reddit.com/r/selfhosted/comments/oc5rjs/wiretrustee_v008_vs_tailscale_and_zerotier/

@braginini commented on GitHub (Jul 2, 2021): Hey @stv0g We have released a new version and run some performance tests. We have also removed proxy usage for some cases. I'm closing this issue. See this for details: https://www.reddit.com/r/selfhosted/comments/oc5rjs/wiretrustee_v008_vs_tailscale_and_zerotier/
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#20
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?