[GH-ISSUE #3629] [Need help] communication with a group of nodes via a private network #7276

Closed
opened 2026-08-05 01:12:18 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @galiev on GitHub (Apr 7, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/3629

We have a self-hosted Netbird installation with nodes deployed in two regions (A and B). Clients within each region connect to the nodes in their respective region. Each region provides access to a unique set of networks. When a client from region A needs to access resources provided by nodes in region B, the nodes in region A currently forward traffic to the nodes in region B via Netbird connections over the public internet.

Our provider also offers a private, high-speed (10 Gbps), unmetered network between data centers hosting the nodes in region A and region B, the internet connection for each node is 1 Gbps, and even though the IP addresses belong to the same provider, the internet traffic between the regions is still metered and incurs costs.

We are looking for a way to force Netbird to use the private network for communication between the nodes in region A and region B, instead of routing traffic over the public internet, while still being accessible to clients on the Internet

Is there a mechanism or configuration option within Netbird that allows us to prioritize or enforce the use of this private network for inter-region node communication?

Originally created by @galiev on GitHub (Apr 7, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/3629 We have a self-hosted Netbird installation with nodes deployed in two regions (A and B). Clients within each region connect to the nodes in their respective region. Each region provides access to a unique set of networks. When a client from region A needs to access resources provided by nodes in region B, the nodes in region A currently forward traffic to the nodes in region B via Netbird connections over the public internet. Our provider also offers a private, high-speed (10 Gbps), unmetered network between data centers hosting the nodes in region A and region B, the internet connection for each node is 1 Gbps, and even though the IP addresses belong to the same provider, the internet traffic between the regions is still metered and incurs costs. We are looking for a way to force Netbird to use the private network for communication between the nodes in region A and region B, instead of routing traffic over the public internet, while still being accessible to clients on the Internet Is there a mechanism or configuration option within Netbird that allows us to prioritize or enforce the use of this private network for inter-region node communication?
Author
Owner

@galiev commented on GitHub (Apr 7, 2025):

It seems I've found the answer: If I simply block traffic via the public network using the firewall, Netbird should then switch to the private network on its own:

Netbird uses the ICE to find the best path for connections. This involves:

  • Gathering Candidates: Each Netbird agent identifies all its local IP addresses and potential public IP addresses (discovered via STUN servers). These become potential "candidates" for connection endpoints.

  • Signaling: Agents exchange these candidates lists via the Signal service.

  • Connectivity Checks: Agents try to establish direct UDP connections between pairs of candidate addresses (local-to-remote). This includes trying public IP to public IP, private IP to private IP, public IP to private IP, etc.

  • Path Selection: ICE prioritizes paths that work. Generally, direct connections are preferred over relayed (TURN) connections. Among direct paths, lower latency paths are often favored.

<!-- gh-comment-id:2783313893 --> @galiev commented on GitHub (Apr 7, 2025): It seems I've found the answer: If I simply block traffic via the public network using the firewall, Netbird should then switch to the private network on its own: Netbird uses the ICE to find the best path for connections. This involves: - **Gathering Candidates**: Each Netbird agent identifies all its local IP addresses and potential public IP addresses (discovered via STUN servers). These become potential "candidates" for connection endpoints. - **Signaling**: Agents exchange these candidates lists via the Signal service. - **Connectivity Checks**: Agents try to establish direct UDP connections between pairs of candidate addresses (local-to-remote). This includes trying public IP to public IP, private IP to private IP, public IP to private IP, etc. - **Path Selection**: ICE prioritizes paths that work. Generally, direct connections are preferred over relayed (TURN) connections. Among direct paths, lower latency paths are often favored.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#7276