From 32d51b6392e97805acad362c2a30467662ebaf7d Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Fri, 7 Aug 2026 18:41:41 +0200 Subject: [PATCH 1/9] docs: add corporate firewalls table to Ports & Firewalls Add a "Corporate firewalls" section covering common enterprise firewall and SASE products (Palo Alto, Fortinet, Cisco, Check Point, Zscaler, Netskope, Cloudflare Gateway, Sophos, SonicWall, Barracuda). It explains how NetBird behaves through a corporate firewall, that it falls back to the TCP/443 relay when direct peer-to-peer is blocked so peers stay connected, and what to allow per product, including which TLS inspection feature to exclude the NetBird domains from. Co-Authored-By: Claude Opus 4.8 --- .../about-netbird/ports-and-firewalls.mdx | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index 8ab2f401b..1b5a97687 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -67,6 +67,35 @@ NetBird usually won't need open ports, but sometimes you or your IT team needs t Download the full list of NetBird Cloud STUN/TURN/Relay endpoints and port requirements in JSON format. +## Corporate firewalls + +NetBird is designed to work through corporate firewalls with no inbound rules. Peers always dial out, so the firewall sees ordinary outbound HTTPS and UDP sessions. When a firewall does get in the way, it is almost always one of two things: it blocks the outbound UDP that direct peer-to-peer connections rely on, or it inspects the encrypted traffic to NetBird's control plane (TLS/SSL interception or deep packet inspection). + +Neither usually causes an outage. If direct connections are blocked, NetBird falls back to its relay over TCP/443, so peers stay connected, just relayed instead of direct. Two settings cover most products: + +1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (for example `*.netbird.io` and `*.relay.netbird.io`). Allowing the outbound **P2P (STUN)** and **Relay (TURN)** endpoints is what keeps connections direct and low latency. +2. **Exclude those same domains from TLS/SSL inspection and deep packet inspection.** Intercepting NetBird's control-plane or relay traffic can break the session or push it onto the slower relay path. Scope the exclusion to the NetBird domains rather than disabling inspection broadly. + +The table below maps this to common enterprise firewall and SASE products. "Expected behavior" assumes only the outbound endpoints are allowed, with no other tuning. + +| Firewall / SASE product | Expected behavior | What to allow | +|---|---|---| +| Palo Alto Networks | Connects, relayed if the security policy blocks outbound UDP | Permit the STUN/TURN endpoints, and exclude `*.netbird.io` from the SSL Decryption policy | +| Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to STUN/TURN, and exempt the NetBird domains from the SSL/SSH Inspection profile | +| Cisco Secure Firewall | Connects, relayed if UDP is filtered | Permit the STUN/TURN endpoints, and skip the Decryption policy for `*.netbird.io` | +| Cisco Umbrella | Connects | Allow the NetBird domains in the DNS and web policy (no UDP change needed) | +| Check Point | Connects, relayed with HTTPS Inspection enabled | Allow the endpoints, and add `*.netbird.io` to the HTTPS Inspection bypass | +| Zscaler Internet Access | Connects, usually relayed | Allow the domains with an SSL Inspection exemption, and add a firewall bypass for the UDP endpoints to keep connections direct | +| Netskope | Connects | Add `*.netbird.io` and `*.relay.netbird.io` to the SSL decryption and steering bypass | +| Cloudflare Gateway | Connects | Allow the domains, and add a Do Not Inspect rule for `*.netbird.io` | +| Sophos Firewall | Connects | Allow the endpoints, and exclude the NetBird domains from SSL/TLS Inspection | +| SonicWall | Connects, relayed with DPI-SSL enabled | Allow outbound UDP to STUN/TURN, and exclude the NetBird domains from DPI-SSL | +| Barracuda CloudGen | Connects | Allow the endpoints, and relax UDP session limits to keep connections direct | + + + The endpoints to allow are exact (see [Network firewall ports](#network-firewall-ports)). Per-product behavior and menu names vary by firmware version and policy, so treat each row as a starting point and confirm against your firewall vendor's current documentation. + + ## Host-based firewalls NetBird automatically manages host-based firewall rules to allow traffic on the NetBird interface (`wt0`). This is separate from your network/perimeter firewall, which requires no inbound port configuration. Conflicts can occur with other firewall management tools or security software — this section covers how to detect and resolve them. From e48b6923913ba9cc2b0c2d06e5f2327c94823c2f Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Fri, 7 Aug 2026 18:57:38 +0200 Subject: [PATCH 2/9] docs: refine corporate firewalls section and cross-link from troubleshooting Address review feedback on the new Corporate firewalls section: - Distinguish the two firewall failure modes. Blocking outbound UDP falls back to the TCP/443 relay, but TLS/DPI inspection of the control plane can prevent connecting at all. - Correct the STUN vs TURN roles. STUN enables direct connections, while TURN and the relay service are the fallback, not a way to keep connections direct. - Make the relay domains explicit in the inspection-bypass guidance, since a *.netbird.io wildcard does not match the deeper *.relay.netbird.io hosts. Cross-link the section from the relayed-connections guide (Step 3) and the troubleshooting hub, since a corporate firewall blocking UDP is a common cause of relayed connections. Co-Authored-By: Claude Opus 4.8 --- src/pages/about-netbird/ports-and-firewalls.mdx | 16 ++++++++-------- .../help/troubleshooting-relayed-connections.mdx | 2 +- src/pages/help/troubleshooting.mdx | 1 + 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index 1b5a97687..ec3ca5d04 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -71,23 +71,23 @@ NetBird usually won't need open ports, but sometimes you or your IT team needs t NetBird is designed to work through corporate firewalls with no inbound rules. Peers always dial out, so the firewall sees ordinary outbound HTTPS and UDP sessions. When a firewall does get in the way, it is almost always one of two things: it blocks the outbound UDP that direct peer-to-peer connections rely on, or it inspects the encrypted traffic to NetBird's control plane (TLS/SSL interception or deep packet inspection). -Neither usually causes an outage. If direct connections are blocked, NetBird falls back to its relay over TCP/443, so peers stay connected, just relayed instead of direct. Two settings cover most products: +The two have different outcomes. Blocking outbound UDP is the milder case: NetBird falls back to its relay over TCP/443, so peers stay connected, just relayed instead of direct. Inspecting the control-plane traffic is the disruptive one: if a firewall intercepts the TLS to the management, signal, or relay endpoints, the client can fail to connect at all. Two settings cover most products: -1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (for example `*.netbird.io` and `*.relay.netbird.io`). Allowing the outbound **P2P (STUN)** and **Relay (TURN)** endpoints is what keeps connections direct and low latency. -2. **Exclude those same domains from TLS/SSL inspection and deep packet inspection.** Intercepting NetBird's control-plane or relay traffic can break the session or push it onto the slower relay path. Scope the exclusion to the NetBird domains rather than disabling inspection broadly. +1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (`*.netbird.io`, plus `relay.netbird.io` and `*.relay.netbird.io` for the relay servers). Allowing the outbound **P2P (STUN)** endpoints enables direct, low-latency connections. The **Relay (TURN)** and **Relay service** endpoints provide the fallback when a direct path is not possible. +2. **Exclude those same domains from TLS/SSL inspection and deep packet inspection.** Intercepting NetBird's control-plane or relay traffic can break the session or push it onto the slower relay path. Scope the exclusion to the NetBird domains rather than disabling inspection broadly. A `*.netbird.io` wildcard usually does not match the deeper `*.relay.netbird.io` relay hostnames, so exclude `relay.netbird.io` and `*.relay.netbird.io` explicitly. The table below maps this to common enterprise firewall and SASE products. "Expected behavior" assumes only the outbound endpoints are allowed, with no other tuning. | Firewall / SASE product | Expected behavior | What to allow | |---|---|---| -| Palo Alto Networks | Connects, relayed if the security policy blocks outbound UDP | Permit the STUN/TURN endpoints, and exclude `*.netbird.io` from the SSL Decryption policy | +| Palo Alto Networks | Connects, relayed if the security policy blocks outbound UDP | Permit the STUN/TURN endpoints, and exclude the NetBird domains from the SSL Decryption policy | | Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to STUN/TURN, and exempt the NetBird domains from the SSL/SSH Inspection profile | -| Cisco Secure Firewall | Connects, relayed if UDP is filtered | Permit the STUN/TURN endpoints, and skip the Decryption policy for `*.netbird.io` | +| Cisco Secure Firewall | Connects, relayed if UDP is filtered | Permit the STUN/TURN endpoints, and skip the Decryption policy for the NetBird domains | | Cisco Umbrella | Connects | Allow the NetBird domains in the DNS and web policy (no UDP change needed) | -| Check Point | Connects, relayed with HTTPS Inspection enabled | Allow the endpoints, and add `*.netbird.io` to the HTTPS Inspection bypass | +| Check Point | Connects, relayed with HTTPS Inspection enabled | Allow the endpoints, and add the NetBird domains to the HTTPS Inspection bypass | | Zscaler Internet Access | Connects, usually relayed | Allow the domains with an SSL Inspection exemption, and add a firewall bypass for the UDP endpoints to keep connections direct | -| Netskope | Connects | Add `*.netbird.io` and `*.relay.netbird.io` to the SSL decryption and steering bypass | -| Cloudflare Gateway | Connects | Allow the domains, and add a Do Not Inspect rule for `*.netbird.io` | +| Netskope | Connects | Add the NetBird domains to the SSL decryption and steering bypass | +| Cloudflare Gateway | Connects | Allow the domains, and add a Do Not Inspect rule for the NetBird domains | | Sophos Firewall | Connects | Allow the endpoints, and exclude the NetBird domains from SSL/TLS Inspection | | SonicWall | Connects, relayed with DPI-SSL enabled | Allow outbound UDP to STUN/TURN, and exclude the NetBird domains from DPI-SSL | | Barracuda CloudGen | Connects | Allow the endpoints, and relax UDP session limits to keep connections direct | diff --git a/src/pages/help/troubleshooting-relayed-connections.mdx b/src/pages/help/troubleshooting-relayed-connections.mdx index c9c3331a5..c2825a90a 100644 --- a/src/pages/help/troubleshooting-relayed-connections.mdx +++ b/src/pages/help/troubleshooting-relayed-connections.mdx @@ -148,7 +148,7 @@ Relays: [rels://us-nyc-2.relay.netbird.io:443] is Available ``` -Any `Unavailable` entry for a `stun:` or `turn:` endpoint means outbound UDP is being dropped on the path, typically by the site's egress firewall. Ask whoever runs it to allow outbound UDP on ports 80, 443, 3478, and 5555 to `stun.netbird.io` and `turn.netbird.io`; the exact list and example rules are in [Ports & Firewalls](/about-netbird/ports-and-firewalls#outgoing-ports). +Any `Unavailable` entry for a `stun:` or `turn:` endpoint means outbound UDP is being dropped on the path, typically by the site's egress firewall. Ask whoever runs it to allow outbound UDP on ports 80, 443, 3478, and 5555 to `stun.netbird.io` and `turn.netbird.io`; the exact list and example rules are in [Ports & Firewalls](/about-netbird/ports-and-firewalls#outgoing-ports). If the site runs a named enterprise firewall or SASE product (Palo Alto, Fortinet, Zscaler, and so on), [Corporate firewalls](/about-netbird/ports-and-firewalls#corporate-firewalls) lists what to allow per vendor. Every fix on this page is an **outbound** firewall rule or an allowance on the host's `wt0` interface. NetBird never needs an inbound port opened on your perimeter firewall. diff --git a/src/pages/help/troubleshooting.mdx b/src/pages/help/troubleshooting.mdx index 6392a5052..f3f2d0898 100644 --- a/src/pages/help/troubleshooting.mdx +++ b/src/pages/help/troubleshooting.mdx @@ -66,6 +66,7 @@ next to the feature they cover, so nothing here is a copy. { label: "Resource connectivity", href: "/help/troubleshooting-resource-connectivity" }, { label: "Reverse proxy", href: "/manage/reverse-proxy/troubleshooting" }, { label: "NAT & firewall ports", href: "/about-netbird/ports-and-firewalls" }, + { label: "Corporate firewalls", href: "/about-netbird/ports-and-firewalls#corporate-firewalls" }, { label: "DNS", href: "/manage/dns/troubleshooting" }, { label: "Network routes", href: "/manage/network-routes" }, ], From a1103327aa650596ef345d7c271a53d6059763d7 Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Mon, 10 Aug 2026 10:35:47 +0200 Subject: [PATCH 3/9] docs: add Palo Alto source-NAT guidance and surface firewalls at relay escalation Corporate firewalls: note that some enterprise firewalls apply per-destination (symmetric) source NAT, which defeats hole punching and forces the relay. Add the port-preserving fix, with Palo Alto's Persistent Dynamic IP And Port mode in its row and a general note covering the pattern and UDP session timeouts. Relayed connections: the symmetric-NAT cause is often a corporate firewall the operator controls, so reference the Corporate firewalls section at the final escalation step, and scope the earlier "no firewall tuning will change that" claim to mobile and cloud NAT where it actually holds. Co-Authored-By: Claude Opus 4.8 --- src/pages/about-netbird/ports-and-firewalls.mdx | 6 +++++- src/pages/help/troubleshooting-relayed-connections.mdx | 4 ++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index ec3ca5d04..2ca163abc 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -80,7 +80,7 @@ The table below maps this to common enterprise firewall and SASE products. "Expe | Firewall / SASE product | Expected behavior | What to allow | |---|---|---| -| Palo Alto Networks | Connects, relayed if the security policy blocks outbound UDP | Permit the STUN/TURN endpoints, and exclude the NetBird domains from the SSL Decryption policy | +| Palo Alto Networks | Connects, relayed if the policy blocks outbound UDP or applies per-destination NAT | Permit the STUN/TURN endpoints, exclude the NetBird domains from the SSL Decryption policy, and set source NAT to Persistent Dynamic IP And Port to keep connections direct | | Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to STUN/TURN, and exempt the NetBird domains from the SSL/SSH Inspection profile | | Cisco Secure Firewall | Connects, relayed if UDP is filtered | Permit the STUN/TURN endpoints, and skip the Decryption policy for the NetBird domains | | Cisco Umbrella | Connects | Allow the NetBird domains in the DNS and web policy (no UDP change needed) | @@ -92,6 +92,10 @@ The table below maps this to common enterprise firewall and SASE products. "Expe | SonicWall | Connects, relayed with DPI-SSL enabled | Allow outbound UDP to STUN/TURN, and exclude the NetBird domains from DPI-SSL | | Barracuda CloudGen | Connects | Allow the endpoints, and relax UDP session limits to keep connections direct | + + If peers connect but stay relayed, the firewall may be applying per-destination (symmetric) source NAT, which defeats hole punching. Where the device lets you choose, pick a source NAT mode that preserves the port, and raise the UDP session timeout for the NetBird flows so long-lived tunnels are not torn down. [Troubleshooting relayed connections](/help/troubleshooting-relayed-connections) walks through confirming this. + + The endpoints to allow are exact (see [Network firewall ports](#network-firewall-ports)). Per-product behavior and menu names vary by firmware version and policy, so treat each row as a starting point and confirm against your firewall vendor's current documentation. diff --git a/src/pages/help/troubleshooting-relayed-connections.mdx b/src/pages/help/troubleshooting-relayed-connections.mdx index c2825a90a..ad2508784 100644 --- a/src/pages/help/troubleshooting-relayed-connections.mdx +++ b/src/pages/help/troubleshooting-relayed-connections.mdx @@ -120,7 +120,7 @@ Some networks are known to defeat hole punching, no matter how clean the firewal - **Cloud NAT gateways** (AWS NAT Gateway, GCP Cloud NAT): symmetric by design for instances without a public IP. - **Enterprise firewalls in strict mode**: Cisco ASA, Palo Alto, Fortinet and similar devices often default to symmetric NAT, sometimes labeled "strict NAT" in their settings. -If **both** peers sit on networks like these, hole punching can't succeed and no amount of firewall tuning will change that. The relay is the expected outcome, and you can stop here (see [when relay is the right answer](#when-relay-is-the-right-answer)). If only one side does, or you're not sure, keep going: one predictable side is usually enough for P2P. +If **both** peers sit on networks like these, hole punching can't succeed, and for mobile or cloud NAT no firewall tuning will change that. The relay is the expected outcome, and you can stop here (see [when relay is the right answer](#when-relay-is-the-right-answer)). An enterprise firewall you control is the exception: its NAT mode is often tunable, see [Corporate firewalls](/about-netbird/ports-and-firewalls#corporate-firewalls). If only one side is affected, or you're not sure, keep going: one predictable side is usually enough for P2P. A CGNAT tell: the public address your network presents is in `100.64.0.0/10`, a range reserved for carrier-grade NAT. Don't confuse it with your own NetBird IP. NetBird intentionally uses the same range for its overlay network, so only the address your *ISP-facing* connection shows counts. @@ -170,7 +170,7 @@ Can't shell into the far peer? Administrators can trigger a debug bundle remotel ### Step 6: Conclude, or escalate -If every check passes on both peers and the connection is still relayed, you've proven by elimination that a symmetric NAT is in the path. Accept the relay. It's the [designed behavior for exactly this case](#when-relay-is-the-right-answer), and it costs latency, not security. +If every check passes on both peers and the connection is still relayed, you've proven by elimination that a symmetric NAT is in the path. Before you accept that, check whether the NAT is a corporate firewall you control: many enterprise firewalls randomize the source port per destination by default, and switching to a port-preserving mode restores direct connections. [Corporate firewalls](/about-netbird/ports-and-firewalls#corporate-firewalls) has the per-vendor settings. If the NAT is outside your control (mobile, cloud, or someone else's network), accept the relay. It's the [designed behavior for exactly this case](#when-relay-is-the-right-answer), and it costs latency, not security. If instead something looks wrong but you can't place it, collect evidence and escalate: From 0a23292f46e996566a68678e0dea51ebe1142a78 Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Mon, 10 Aug 2026 10:59:49 +0200 Subject: [PATCH 4/9] docs: address second review pass on corporate firewalls guidance - Broaden the firewall failure modes beyond UDP blocking and TLS inspection to include blocked or proxied outbound TCP/443 and strict destination egress, which break the control plane before any inspection. - Note that reaching the NetBird service endpoints does not by itself prove a direct peer path, since a firewall can allow STUN/TURN yet block UDP to peer addresses. Qualify the relayed-connections conclusion accordingly. - Match the STUN/TURN fix to the transport that netbird status reports: STUN is UDP 80/443/3478/5555, TURN is UDP 80/443 plus TCP 443-65535, rather than applying STUN's UDP ports to TURN. Co-Authored-By: Claude Opus 4.8 --- src/pages/about-netbird/ports-and-firewalls.mdx | 6 +++--- src/pages/help/troubleshooting-relayed-connections.mdx | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index 2ca163abc..a8f359889 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -69,11 +69,11 @@ NetBird usually won't need open ports, but sometimes you or your IT team needs t ## Corporate firewalls -NetBird is designed to work through corporate firewalls with no inbound rules. Peers always dial out, so the firewall sees ordinary outbound HTTPS and UDP sessions. When a firewall does get in the way, it is almost always one of two things: it blocks the outbound UDP that direct peer-to-peer connections rely on, or it inspects the encrypted traffic to NetBird's control plane (TLS/SSL interception or deep packet inspection). +NetBird is designed to work through corporate firewalls with no inbound rules. Peers always dial out, so the firewall sees ordinary outbound HTTPS and UDP sessions. When a firewall does get in the way, the usual causes are: it blocks the outbound UDP that direct peer-to-peer connections rely on, it restricts the outbound TCP/443 the control plane needs (a blocked port, a forced proxy, or strict destination egress), or it inspects that encrypted traffic (TLS/SSL interception or deep packet inspection). -The two have different outcomes. Blocking outbound UDP is the milder case: NetBird falls back to its relay over TCP/443, so peers stay connected, just relayed instead of direct. Inspecting the control-plane traffic is the disruptive one: if a firewall intercepts the TLS to the management, signal, or relay endpoints, the client can fail to connect at all. Two settings cover most products: +These have different outcomes. Blocking outbound UDP is the milder case: NetBird falls back to its relay over TCP/443, so peers stay connected, just relayed instead of direct. Losing the control plane is the disruptive case: if the client cannot reach the management, signal, or relay endpoints over TCP/443, or a firewall intercepts that TLS, it can fail to connect at all. Two settings cover most products: -1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (`*.netbird.io`, plus `relay.netbird.io` and `*.relay.netbird.io` for the relay servers). Allowing the outbound **P2P (STUN)** endpoints enables direct, low-latency connections. The **Relay (TURN)** and **Relay service** endpoints provide the fallback when a direct path is not possible. +1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (`*.netbird.io`, plus `relay.netbird.io` and `*.relay.netbird.io` for the relay servers). Allowing the outbound **P2P (STUN)** endpoints enables direct, low-latency connections. Direct connections also need outbound UDP to the peers' own discovered addresses, so a firewall that permits UDP only to the NetBird endpoints still falls back to the relay. The **Relay (TURN)** and **Relay service** endpoints provide that fallback. 2. **Exclude those same domains from TLS/SSL inspection and deep packet inspection.** Intercepting NetBird's control-plane or relay traffic can break the session or push it onto the slower relay path. Scope the exclusion to the NetBird domains rather than disabling inspection broadly. A `*.netbird.io` wildcard usually does not match the deeper `*.relay.netbird.io` relay hostnames, so exclude `relay.netbird.io` and `*.relay.netbird.io` explicitly. The table below maps this to common enterprise firewall and SASE products. "Expected behavior" assumes only the outbound endpoints are allowed, with no other tuning. diff --git a/src/pages/help/troubleshooting-relayed-connections.mdx b/src/pages/help/troubleshooting-relayed-connections.mdx index ad2508784..b98eb68f8 100644 --- a/src/pages/help/troubleshooting-relayed-connections.mdx +++ b/src/pages/help/troubleshooting-relayed-connections.mdx @@ -148,7 +148,7 @@ Relays: [rels://us-nyc-2.relay.netbird.io:443] is Available ``` -Any `Unavailable` entry for a `stun:` or `turn:` endpoint means outbound UDP is being dropped on the path, typically by the site's egress firewall. Ask whoever runs it to allow outbound UDP on ports 80, 443, 3478, and 5555 to `stun.netbird.io` and `turn.netbird.io`; the exact list and example rules are in [Ports & Firewalls](/about-netbird/ports-and-firewalls#outgoing-ports). If the site runs a named enterprise firewall or SASE product (Palo Alto, Fortinet, Zscaler, and so on), [Corporate firewalls](/about-netbird/ports-and-firewalls#corporate-firewalls) lists what to allow per vendor. +Any `Unavailable` entry means the reported transport to that endpoint is being dropped on the path, typically by the site's egress firewall. Ask whoever runs it to allow the matching outbound traffic: UDP ports 80, 443, 3478, and 5555 to `stun.netbird.io`, and UDP ports 80 and 443 plus TCP ports 443 to 65535 to `turn.netbird.io`. The exact list and example rules are in [Ports & Firewalls](/about-netbird/ports-and-firewalls#outgoing-ports). If the site runs a named enterprise firewall or SASE product (Palo Alto, Fortinet, Zscaler, and so on), [Corporate firewalls](/about-netbird/ports-and-firewalls#corporate-firewalls) lists what to allow per vendor. Every fix on this page is an **outbound** firewall rule or an allowance on the host's `wt0` interface. NetBird never needs an inbound port opened on your perimeter firewall. @@ -170,7 +170,7 @@ Can't shell into the far peer? Administrators can trigger a debug bundle remotel ### Step 6: Conclude, or escalate -If every check passes on both peers and the connection is still relayed, you've proven by elimination that a symmetric NAT is in the path. Before you accept that, check whether the NAT is a corporate firewall you control: many enterprise firewalls randomize the source port per destination by default, and switching to a port-preserving mode restores direct connections. [Corporate firewalls](/about-netbird/ports-and-firewalls#corporate-firewalls) has the per-vendor settings. If the NAT is outside your control (mobile, cloud, or someone else's network), accept the relay. It's the [designed behavior for exactly this case](#when-relay-is-the-right-answer), and it costs latency, not security. +If every check passes on both peers and the connection is still relayed, the most likely remaining cause is a symmetric NAT in the path. A firewall that permits outbound UDP only to the NetBird service endpoints, and not to the peers' own discovered addresses, produces the same result and is worth considering. Either way, check whether it is a corporate firewall you control: many enterprise firewalls randomize the source port per destination, or scope outbound UDP too tightly, and both are tunable. [Corporate firewalls](/about-netbird/ports-and-firewalls#corporate-firewalls) has the per-vendor settings. If the NAT is outside your control (mobile, cloud, or someone else's network), accept the relay. It's the [designed behavior for exactly this case](#when-relay-is-the-right-answer), and it costs latency, not security. If instead something looks wrong but you can't place it, collect evidence and escalate: From a6f0c0292f86ec95362aad08db22b7f8a1b2def3 Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Mon, 10 Aug 2026 12:04:25 +0200 Subject: [PATCH 5/9] docs: drop TURN wording from corporate firewalls guidance Refer to the outbound relay endpoints as "relay" rather than "STUN/TURN" and "Relay (TURN)" in the Corporate firewalls section, in line with NetBird's relay terminology. Endpoint hostnames are unchanged. Co-Authored-By: Claude Opus 4.8 --- src/pages/about-netbird/ports-and-firewalls.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index a8f359889..b980a7275 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -73,23 +73,23 @@ NetBird is designed to work through corporate firewalls with no inbound rules. P These have different outcomes. Blocking outbound UDP is the milder case: NetBird falls back to its relay over TCP/443, so peers stay connected, just relayed instead of direct. Losing the control plane is the disruptive case: if the client cannot reach the management, signal, or relay endpoints over TCP/443, or a firewall intercepts that TLS, it can fail to connect at all. Two settings cover most products: -1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (`*.netbird.io`, plus `relay.netbird.io` and `*.relay.netbird.io` for the relay servers). Allowing the outbound **P2P (STUN)** endpoints enables direct, low-latency connections. Direct connections also need outbound UDP to the peers' own discovered addresses, so a firewall that permits UDP only to the NetBird endpoints still falls back to the relay. The **Relay (TURN)** and **Relay service** endpoints provide that fallback. +1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (`*.netbird.io`, plus `relay.netbird.io` and `*.relay.netbird.io` for the relay servers). Allowing the outbound **P2P (STUN)** endpoints enables direct, low-latency connections. Direct connections also need outbound UDP to the peers' own discovered addresses, so a firewall that permits UDP only to the NetBird endpoints still falls back to the relay. The relay endpoints provide that fallback. 2. **Exclude those same domains from TLS/SSL inspection and deep packet inspection.** Intercepting NetBird's control-plane or relay traffic can break the session or push it onto the slower relay path. Scope the exclusion to the NetBird domains rather than disabling inspection broadly. A `*.netbird.io` wildcard usually does not match the deeper `*.relay.netbird.io` relay hostnames, so exclude `relay.netbird.io` and `*.relay.netbird.io` explicitly. The table below maps this to common enterprise firewall and SASE products. "Expected behavior" assumes only the outbound endpoints are allowed, with no other tuning. | Firewall / SASE product | Expected behavior | What to allow | |---|---|---| -| Palo Alto Networks | Connects, relayed if the policy blocks outbound UDP or applies per-destination NAT | Permit the STUN/TURN endpoints, exclude the NetBird domains from the SSL Decryption policy, and set source NAT to Persistent Dynamic IP And Port to keep connections direct | -| Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to STUN/TURN, and exempt the NetBird domains from the SSL/SSH Inspection profile | -| Cisco Secure Firewall | Connects, relayed if UDP is filtered | Permit the STUN/TURN endpoints, and skip the Decryption policy for the NetBird domains | +| Palo Alto Networks | Connects, relayed if the policy blocks outbound UDP or applies per-destination NAT | Permit the STUN and relay endpoints, exclude the NetBird domains from the SSL Decryption policy, and set source NAT to Persistent Dynamic IP And Port to keep connections direct | +| Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to the STUN and relay endpoints, and exempt the NetBird domains from the SSL/SSH Inspection profile | +| Cisco Secure Firewall | Connects, relayed if UDP is filtered | Permit the STUN and relay endpoints, and skip the Decryption policy for the NetBird domains | | Cisco Umbrella | Connects | Allow the NetBird domains in the DNS and web policy (no UDP change needed) | | Check Point | Connects, relayed with HTTPS Inspection enabled | Allow the endpoints, and add the NetBird domains to the HTTPS Inspection bypass | | Zscaler Internet Access | Connects, usually relayed | Allow the domains with an SSL Inspection exemption, and add a firewall bypass for the UDP endpoints to keep connections direct | | Netskope | Connects | Add the NetBird domains to the SSL decryption and steering bypass | | Cloudflare Gateway | Connects | Allow the domains, and add a Do Not Inspect rule for the NetBird domains | | Sophos Firewall | Connects | Allow the endpoints, and exclude the NetBird domains from SSL/TLS Inspection | -| SonicWall | Connects, relayed with DPI-SSL enabled | Allow outbound UDP to STUN/TURN, and exclude the NetBird domains from DPI-SSL | +| SonicWall | Connects, relayed with DPI-SSL enabled | Allow outbound UDP to the STUN and relay endpoints, and exclude the NetBird domains from DPI-SSL | | Barracuda CloudGen | Connects | Allow the endpoints, and relax UDP session limits to keep connections direct | From 1e087c700e0a5b6a782e52e93f56344aeb739f08 Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Mon, 10 Aug 2026 12:25:05 +0200 Subject: [PATCH 6/9] docs: replace TURN wording with relay in user-facing docs TURN is legacy in NetBird, so the user-facing docs now call it the relay service: - Ports & Firewalls: rename the "Relay (TURN) service" endpoint and split the two relay endpoints by transport (UDP/TCP and TCP) to keep them distinct, and drop TURN from the notes and the JSON-download line. - Relayed-connections and troubleshooting hub: drop TURN from the status and rollout wording and the connectivity chip label. - Zero Trust use case: describe STUN and relay instead of STUN/TURN. Endpoint hostnames (turn.netbird.io) and the netbird status output are unchanged. Self-hosted coturn documentation is intentionally left as-is, since there TURN refers to the actual legacy software. Co-Authored-By: Claude Opus 4.8 --- src/pages/about-netbird/ports-and-firewalls.mdx | 10 +++++----- src/pages/help/troubleshooting-relayed-connections.mdx | 4 ++-- src/pages/help/troubleshooting.mdx | 2 +- src/pages/use-cases/security/implement-zero-trust.mdx | 4 ++-- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index b980a7275..a7b3370c6 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -23,7 +23,7 @@ The NetBird client doesn't require any incoming port to be open; it negotiates t NetBird usually won't need open ports, but sometimes you or your IT team needs to secure and verify all outgoing traffic, and that may affect how NetBird clients connect to the [control plane](/about-netbird/how-netbird-works) and negotiate the peer-to-peer connections. - In more restricted networks, allowing the outbound **P2P (STUN)** and **Relay (TURN)** services below is **recommended** for reliable peer connections. This also improves the reliability of your [routing peers](/manage/networks/how-routing-peers-work). + In more restricted networks, allowing the outbound **P2P (STUN)** and **Relay** services below is **recommended** for reliable peer connections. This also improves the reliability of your [routing peers](/manage/networks/how-routing-peers-work). If using `fail2ban` or similar, you should whitelist each netbird.io endpoint below. @@ -50,21 +50,21 @@ NetBird usually won't need open ports, but sometimes you or your IT team needs t * In more restricted environments, `netbird status` will show `keepalive ping failed` errors without a firewall rule for STUN * Example `nftables` outbound firewall rule: `ip daddr stun.netbird.io udp dport { 80, 443, 3478, 5555 } accept` * Note that `nftables` resolves hostnames only when the ruleset is loaded, pinning the rule to the IPs resolved at that moment. Since the pool is dynamic and geo-distributed, reload the ruleset periodically or keep the allowlist updated by other means. -* Relay (TURN) service: +* Relay service (UDP/TCP): * **Endpoint**: turn.netbird.io * **Port range**: UDP/80,443 and TCP/443-65535 * **IPv4**: The list is dynamic and geo-distributed; we advise you to check the nearest cluster with the following command: * `nslookup turn.netbird.io` - * In more restricted environments, `netbird status` will show `keepalive ping failed` errors without a firewall rule for TURN + * In more restricted environments, `netbird status` will show `keepalive ping failed` errors without a firewall rule for the relay * Example `nftables` outbound firewall rule: `ip daddr turn.netbird.io tcp dport 443-65535 accept` -* Relay service: +* Relay service (TCP): * **Endpoints**: *.relay.netbird.io and relay.netbird.io * **Port**: TCP/443 * **IPv4**: The list is dynamic and geo-distributed; When looking at the `netbird status -d` output, you can see which relay you are connecting to. * It is advised to wildcard `*.relay.netbird.io` when possible, to avoid interrupts. - Download the full list of NetBird Cloud STUN/TURN/Relay endpoints and port requirements in JSON format. + Download the full list of NetBird Cloud STUN and Relay endpoints and port requirements in JSON format. ## Corporate firewalls diff --git a/src/pages/help/troubleshooting-relayed-connections.mdx b/src/pages/help/troubleshooting-relayed-connections.mdx index b98eb68f8..c603ef2da 100644 --- a/src/pages/help/troubleshooting-relayed-connections.mdx +++ b/src/pages/help/troubleshooting-relayed-connections.mdx @@ -139,7 +139,7 @@ Both must succeed. If they don't, fix outbound TCP/443 to these endpoints first, ### Step 3: Is STUN reachable? -Hole punching starts with STUN, and STUN runs over UDP. The best evidence is already in `netbird status -d`. The `Relays:` section near the bottom reports reachability of every STUN, TURN, and relay endpoint: +Hole punching starts with STUN, and STUN runs over UDP. The best evidence is already in `netbird status -d`. The `Relays:` section near the bottom reports reachability of every STUN and relay endpoint: ``` Relays: @@ -217,7 +217,7 @@ Guides elsewhere sometimes suggest forwarding a UDP port to a peer to force P2P To keep a whole fleet on direct connections rather than fixing peers one at a time: -- **Allow outbound UDP to STUN/TURN** (`stun.netbird.io`, `turn.netbird.io`, ports 80, 443, 3478, 5555) at every site's egress firewall. +- **Allow outbound UDP to the STUN and relay endpoints** (`stun.netbird.io`, `turn.netbird.io`, ports 80, 443, 3478, 5555) at every site's egress firewall. - **Wildcard `*.relay.netbird.io` on TCP/443** so the relay fallback survives rotation of the geo-distributed relay pool. - **Watch the `Relays:` section** of `netbird status -d` during rollout, fix `Unavailable` entries before users report slowness. - **Bake the `wt0` allowance into host-firewall baselines** (UFW/firewalld/Windows images), so host firewalls never silently block decrypted traffic. diff --git a/src/pages/help/troubleshooting.mdx b/src/pages/help/troubleshooting.mdx index f3f2d0898..912f457d6 100644 --- a/src/pages/help/troubleshooting.mdx +++ b/src/pages/help/troubleshooting.mdx @@ -37,7 +37,7 @@ next to the feature they cover, so nothing here is a copy. chips: [ { label: "Management service", href: "/selfhosted/troubleshooting/connectivity#management-service-unreachable" }, { label: "Signal service", href: "/about-netbird/how-netbird-works#signal-service" }, - { label: "Relay / TURN", href: "/selfhosted/troubleshooting/connectivity#debugging-turn-connections" }, + { label: "Relay", href: "/selfhosted/troubleshooting/connectivity#debugging-turn-connections" }, { label: "Dashboard", href: "/selfhosted/troubleshooting/dashboard" }, ], }, diff --git a/src/pages/use-cases/security/implement-zero-trust.mdx b/src/pages/use-cases/security/implement-zero-trust.mdx index c77846123..773da2e97 100644 --- a/src/pages/use-cases/security/implement-zero-trust.mdx +++ b/src/pages/use-cases/security/implement-zero-trust.mdx @@ -37,7 +37,7 @@ If you self-host, ensure that Management (the central coordination and authentic ### 0.2 Firewall rules for NetBird traffic -NetBird peers do not need inbound ports open. They initiate outbound connections to NetBird's Management, Signal, and Relay services (as well as other peers) over HTTPS (TCP port 443) and UDP/STUN/TURN protocols. If your network firewall restricts outbound traffic (egress filtering), you must allow these specific endpoints and ports. +NetBird peers do not need inbound ports open. They initiate outbound connections to NetBird's Management, Signal, and Relay services (as well as other peers) over HTTPS (TCP port 443) and UDP for STUN and relay. If your network firewall restricts outbound traffic (egress filtering), you must allow these specific endpoints and ports. For a complete list of NetBird endpoints, IP addresses, and detailed firewall configuration examples, see the [Ports & Firewalls](/about-netbird/ports-and-firewalls#network-firewall-ports) @@ -50,7 +50,7 @@ For a complete list of NetBird endpoints, IP addresses, and detailed firewall co **Understanding the protocols:** - **HTTPS (TCP/443)**: Secure web protocol used for control plane communication -- **STUN/TURN (UDP)**: Protocols used for NAT traversal, helping peers connect through firewalls and routers +- **STUN and relay (UDP)**: Used for NAT traversal, helping peers connect through firewalls and routers

NetBird architecture showing Management, Signal, and Relay services From 2d1e387963f9e2cf8445c3f35f0728826722a120 Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Mon, 10 Aug 2026 13:45:55 +0200 Subject: [PATCH 7/9] docs: scope TURN wording changes to Ports & Firewalls and relayed connections Revert the TURN wording in the troubleshooting hub chip and the Zero Trust use case, keeping the TURN-to-relay rename limited to the Ports & Firewalls and relayed-connections docs for now. The corporate-firewalls cross-link chip in the hub stays. Co-Authored-By: Claude Opus 4.8 --- src/pages/help/troubleshooting.mdx | 2 +- src/pages/use-cases/security/implement-zero-trust.mdx | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/pages/help/troubleshooting.mdx b/src/pages/help/troubleshooting.mdx index 912f457d6..f3f2d0898 100644 --- a/src/pages/help/troubleshooting.mdx +++ b/src/pages/help/troubleshooting.mdx @@ -37,7 +37,7 @@ next to the feature they cover, so nothing here is a copy. chips: [ { label: "Management service", href: "/selfhosted/troubleshooting/connectivity#management-service-unreachable" }, { label: "Signal service", href: "/about-netbird/how-netbird-works#signal-service" }, - { label: "Relay", href: "/selfhosted/troubleshooting/connectivity#debugging-turn-connections" }, + { label: "Relay / TURN", href: "/selfhosted/troubleshooting/connectivity#debugging-turn-connections" }, { label: "Dashboard", href: "/selfhosted/troubleshooting/dashboard" }, ], }, diff --git a/src/pages/use-cases/security/implement-zero-trust.mdx b/src/pages/use-cases/security/implement-zero-trust.mdx index 773da2e97..c77846123 100644 --- a/src/pages/use-cases/security/implement-zero-trust.mdx +++ b/src/pages/use-cases/security/implement-zero-trust.mdx @@ -37,7 +37,7 @@ If you self-host, ensure that Management (the central coordination and authentic ### 0.2 Firewall rules for NetBird traffic -NetBird peers do not need inbound ports open. They initiate outbound connections to NetBird's Management, Signal, and Relay services (as well as other peers) over HTTPS (TCP port 443) and UDP for STUN and relay. If your network firewall restricts outbound traffic (egress filtering), you must allow these specific endpoints and ports. +NetBird peers do not need inbound ports open. They initiate outbound connections to NetBird's Management, Signal, and Relay services (as well as other peers) over HTTPS (TCP port 443) and UDP/STUN/TURN protocols. If your network firewall restricts outbound traffic (egress filtering), you must allow these specific endpoints and ports. For a complete list of NetBird endpoints, IP addresses, and detailed firewall configuration examples, see the [Ports & Firewalls](/about-netbird/ports-and-firewalls#network-firewall-ports) @@ -50,7 +50,7 @@ For a complete list of NetBird endpoints, IP addresses, and detailed firewall co **Understanding the protocols:** - **HTTPS (TCP/443)**: Secure web protocol used for control plane communication -- **STUN and relay (UDP)**: Used for NAT traversal, helping peers connect through firewalls and routers +- **STUN/TURN (UDP)**: Protocols used for NAT traversal, helping peers connect through firewalls and routers

NetBird architecture showing Management, Signal, and Relay services From e4919ae16ca9007475399bf8391dc9433bf62d76 Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Mon, 10 Aug 2026 17:18:51 +0200 Subject: [PATCH 8/9] docs: sort the corporate firewalls table alphabetically Order the firewall and SASE rows alphabetically by product (Barracuda through Zscaler) so readers can scan for their vendor. Co-Authored-By: Claude Opus 4.8 --- src/pages/about-netbird/ports-and-firewalls.mdx | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index a7b3370c6..08e1725c0 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -80,17 +80,17 @@ The table below maps this to common enterprise firewall and SASE products. "Expe | Firewall / SASE product | Expected behavior | What to allow | |---|---|---| -| Palo Alto Networks | Connects, relayed if the policy blocks outbound UDP or applies per-destination NAT | Permit the STUN and relay endpoints, exclude the NetBird domains from the SSL Decryption policy, and set source NAT to Persistent Dynamic IP And Port to keep connections direct | -| Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to the STUN and relay endpoints, and exempt the NetBird domains from the SSL/SSH Inspection profile | +| Barracuda CloudGen | Connects | Allow the endpoints, and relax UDP session limits to keep connections direct | +| Check Point | Connects, relayed with HTTPS Inspection enabled | Allow the endpoints, and add the NetBird domains to the HTTPS Inspection bypass | | Cisco Secure Firewall | Connects, relayed if UDP is filtered | Permit the STUN and relay endpoints, and skip the Decryption policy for the NetBird domains | | Cisco Umbrella | Connects | Allow the NetBird domains in the DNS and web policy (no UDP change needed) | -| Check Point | Connects, relayed with HTTPS Inspection enabled | Allow the endpoints, and add the NetBird domains to the HTTPS Inspection bypass | -| Zscaler Internet Access | Connects, usually relayed | Allow the domains with an SSL Inspection exemption, and add a firewall bypass for the UDP endpoints to keep connections direct | -| Netskope | Connects | Add the NetBird domains to the SSL decryption and steering bypass | | Cloudflare Gateway | Connects | Allow the domains, and add a Do Not Inspect rule for the NetBird domains | -| Sophos Firewall | Connects | Allow the endpoints, and exclude the NetBird domains from SSL/TLS Inspection | +| Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to the STUN and relay endpoints, and exempt the NetBird domains from the SSL/SSH Inspection profile | +| Netskope | Connects | Add the NetBird domains to the SSL decryption and steering bypass | +| Palo Alto Networks | Connects, relayed if the policy blocks outbound UDP or applies per-destination NAT | Permit the STUN and relay endpoints, exclude the NetBird domains from the SSL Decryption policy, and set source NAT to Persistent Dynamic IP And Port to keep connections direct | | SonicWall | Connects, relayed with DPI-SSL enabled | Allow outbound UDP to the STUN and relay endpoints, and exclude the NetBird domains from DPI-SSL | -| Barracuda CloudGen | Connects | Allow the endpoints, and relax UDP session limits to keep connections direct | +| Sophos Firewall | Connects | Allow the endpoints, and exclude the NetBird domains from SSL/TLS Inspection | +| Zscaler Internet Access | Connects, usually relayed | Allow the domains with an SSL Inspection exemption, and add a firewall bypass for the UDP endpoints to keep connections direct | If peers connect but stay relayed, the firewall may be applying per-destination (symmetric) source NAT, which defeats hole punching. Where the device lets you choose, pick a source NAT mode that preserves the port, and raise the UDP session timeout for the NetBird flows so long-lived tunnels are not torn down. [Troubleshooting relayed connections](/help/troubleshooting-relayed-connections) walks through confirming this. From 856e2bc661966ee64537cddc443a9bf711fa7314 Mon Sep 17 00:00:00 2001 From: emrcbrn Date: Mon, 10 Aug 2026 17:43:54 +0200 Subject: [PATCH 9/9] docs: add pfSense and OPNsense to the corporate firewalls table Add pfSense and OPNsense rows, each linking to its existing NetBird setup section for keeping connections direct (Static Port outbound NAT, or Endpoint-Independent NAT / EIM-NAT beta on pfSense). Broaden the table intro from "enterprise" firewalls since these are open-source firewalls. Co-Authored-By: Claude Opus 4.8 --- src/pages/about-netbird/ports-and-firewalls.mdx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/pages/about-netbird/ports-and-firewalls.mdx b/src/pages/about-netbird/ports-and-firewalls.mdx index 08e1725c0..6c69542aa 100644 --- a/src/pages/about-netbird/ports-and-firewalls.mdx +++ b/src/pages/about-netbird/ports-and-firewalls.mdx @@ -76,7 +76,7 @@ These have different outcomes. Blocking outbound UDP is the milder case: NetBird 1. **Allowlist the NetBird endpoints** from [Outgoing ports](#outgoing-ports) above, by domain where the firewall supports it (`*.netbird.io`, plus `relay.netbird.io` and `*.relay.netbird.io` for the relay servers). Allowing the outbound **P2P (STUN)** endpoints enables direct, low-latency connections. Direct connections also need outbound UDP to the peers' own discovered addresses, so a firewall that permits UDP only to the NetBird endpoints still falls back to the relay. The relay endpoints provide that fallback. 2. **Exclude those same domains from TLS/SSL inspection and deep packet inspection.** Intercepting NetBird's control-plane or relay traffic can break the session or push it onto the slower relay path. Scope the exclusion to the NetBird domains rather than disabling inspection broadly. A `*.netbird.io` wildcard usually does not match the deeper `*.relay.netbird.io` relay hostnames, so exclude `relay.netbird.io` and `*.relay.netbird.io` explicitly. -The table below maps this to common enterprise firewall and SASE products. "Expected behavior" assumes only the outbound endpoints are allowed, with no other tuning. +The table below maps this to common firewall and SASE products. "Expected behavior" assumes only the outbound endpoints are allowed, with no other tuning. | Firewall / SASE product | Expected behavior | What to allow | |---|---|---| @@ -87,7 +87,9 @@ The table below maps this to common enterprise firewall and SASE products. "Expe | Cloudflare Gateway | Connects | Allow the domains, and add a Do Not Inspect rule for the NetBird domains | | Fortinet FortiGate | Connects, relayed under UDP limits or SSL inspection | Allow outbound UDP to the STUN and relay endpoints, and exempt the NetBird domains from the SSL/SSH Inspection profile | | Netskope | Connects | Add the NetBird domains to the SSL decryption and steering bypass | +| OPNsense | Connects, relayed under the default port-randomizing outbound NAT | Allow outbound UDP to the STUN and relay endpoints, and add a Static Port outbound NAT rule for the NetBird host. See the [OPNsense setup steps](/get-started/install/opnsense#config-for-troubleshooting-relayed-connections). | | Palo Alto Networks | Connects, relayed if the policy blocks outbound UDP or applies per-destination NAT | Permit the STUN and relay endpoints, exclude the NetBird domains from the SSL Decryption policy, and set source NAT to Persistent Dynamic IP And Port to keep connections direct | +| pfSense | Connects, relayed under the default port-randomizing outbound NAT | Allow outbound UDP to the STUN and relay endpoints, and add a Static Port outbound NAT rule, or enable Endpoint-Independent NAT (EIM-NAT, beta). See the [pfSense setup steps](/get-started/install/pfsense#config-for-troubleshooting-relayed-connections). | | SonicWall | Connects, relayed with DPI-SSL enabled | Allow outbound UDP to the STUN and relay endpoints, and exclude the NetBird domains from DPI-SSL | | Sophos Firewall | Connects | Allow the endpoints, and exclude the NetBird domains from SSL/TLS Inspection | | Zscaler Internet Access | Connects, usually relayed | Allow the domains with an SSL Inspection exemption, and add a firewall bypass for the UDP endpoints to keep connections direct |