docs: add corporate firewalls table to Ports & Firewalls

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.
 
 <Note>
-    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).
 </Note>
 <Note>
     If using `fail2ban` or similar, you should whitelist each netbird.io endpoint below.
@@ -50,21 +50,56 @@ 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.
 
 <Note>
-    Download the full list of NetBird Cloud STUN/TURN/Relay endpoints and port requirements in <a href="/docs-static/files/netbird-cloud-endpoints.json" download>JSON format.</a>
+    Download the full list of NetBird Cloud STUN and Relay endpoints and port requirements in <a href="/docs-static/files/netbird-cloud-endpoints.json" download>JSON format.</a>
+</Note>
+
+## 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, 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).
+
+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 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 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 |
+|---|---|---|
+| 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) |
+| 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 |
+
+<Note>
+    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.
+</Note>
+
+<Note>
+    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.
 </Note>
 
 ## Host-based firewalls

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.
 
 <Note>
 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.
@@ -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:
@@ -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 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.
 
 <Warning>
 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. 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:
 
@@ -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.

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" },
       ],