[GH-ISSUE #2137] Add option to force P2P connection via WebRTC #4387

Open
opened 2026-08-05 00:57:27 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @ghost on GitHub (Jun 15, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2137

In https://docs.netbird.io/about-netbird/how-netbird-works, it shows P2P traffic tunneling directly through WireGuard. If I understand correctly, this is raw, unencapsulated WireGuard traffic.

In some networks, WireGuard traffic may be restricted, and since Netbird already supports WebRTC for relaying, it would be helpful to add an option to use it for P2P connections.

This can be accomplished in a number of ways:

  • Client-side environment variables
  • Setting server-side ACL for some peers
  • Global settings on the server

Related: #1096

Originally created by @ghost on GitHub (Jun 15, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2137 In https://docs.netbird.io/about-netbird/how-netbird-works, it shows P2P traffic tunneling directly through WireGuard. If I understand correctly, this is raw, unencapsulated WireGuard traffic. In some networks, WireGuard traffic may be restricted, and since Netbird already supports WebRTC for relaying, it would be helpful to add an option to use it for P2P connections. This can be accomplished in a number of ways: - Client-side environment variables - Setting server-side ACL for some peers - Global settings on the server Related: #1096
saavagebueno added the feature-request label 2026-08-05 00:57:27 -04:00
Author
Owner

@braginini commented on GitHub (Jun 19, 2024):

hey @thinadusk
Your understanding is correct - the traffic is raw WireGuard traffic.
The change that you are proposing is not as easy as it sounds and requires the whole transport logic refactor.
NetBird uses ICE from WebRTC to negotiate direct connections. However, it doesn't use data channels of WebRTC.
We had some thoughts around it but we lack a real strong use case that would benefit most of the users.

Bottom line, I don't think that we will persue this in the near future. However, we are working on relay improvements that might help with these issues.

What is your environment that blocks WireGuard?

<!-- gh-comment-id:2178007459 --> @braginini commented on GitHub (Jun 19, 2024): hey @thinadusk Your understanding is correct - the traffic is raw WireGuard traffic. The change that you are proposing is not as easy as it sounds and requires the whole transport logic refactor. NetBird uses ICE from WebRTC to negotiate direct connections. However, it doesn't use data channels of WebRTC. We had some thoughts around it but we lack a real strong use case that would benefit most of the users. Bottom line, I don't think that we will persue this in the near future. However, we are working on relay improvements that might help with these issues. What is your environment that blocks WireGuard?
Author
Owner

@CrazyPandar commented on GitHub (Nov 27, 2025):

If the wireguard packet can be transferred over webrtc data channel. When using the browser client, we can connect to the destination without websocket relay. This saves server bandwidth. On the other hand it also unifies the solution for both browser and none browser client.

<!-- gh-comment-id:3586723695 --> @CrazyPandar commented on GitHub (Nov 27, 2025): If the wireguard packet can be transferred over webrtc data channel. When using the browser client, we can connect to the destination without websocket relay. This saves server bandwidth. On the other hand it also unifies the solution for both browser and none browser client.
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#4387