sendnrw/netbird-docs
2
0
Fork 0
mirror of https://github.com/netbirdio/docs.git synced 2026-08-25 01:01:27 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: split Ports & Firewalls out of FAQ (#755)

Browse Source
This commit is contained in:
Jack Carter
2026-05-13 17:48:07 +02:00
committed by GitHub
parent 9802af7bdc
commit 8b1fe13cac
6 changed files with 301 additions and 353 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/components/NavigationDocs.jsx
View File

@@ -32,6 +32,10 @@ export const docsNavigation = [
title: 'Understanding NAT and Connectivity',
href: '/about-netbird/understanding-nat-and-connectivity',
},
{
title: 'Ports & Firewalls',
href: '/about-netbird/ports-and-firewalls',
},
{
title: 'Why WireGuard with NetBird',
href: '/about-netbird/why-wireguard-with-netbird',

150
src/pages/about-netbird/faq.mdx
View File

@@ -2,157 +2,13 @@ import {Note} from "@/components/mdx";
# FAQ
## What firewall ports should I open to use NetBird (Network Firewalls)?
## What firewall ports should I open to use NetBird?
This section covers **network/perimeter firewall** requirements (e.g., Fortigate, pfSense, cloud security groups).
For host-based firewalls (Windows Firewall, UFW, iptables), see
[How does NetBird interact with host-based firewalls?](#how-does-net-bird-interact-with-host-based-firewalls)
### Incoming ports
NetBird's agent doesn't require any incoming port to be open; It negotiates the connection with the support of the signal and relay services.
### Outgoing ports
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 layer](/about-netbird/how-netbird-works)
and negotiate the peer-to-peer connections.
<Note>
Allowing the outbound **P2P (STUN)** service below is **recommended** in more restricted networks for reliable peer connections. This will also improve the reliability of your [High Availability Routes](https://docs.netbird.io/manage/network-routes#high-availability).
</Note>
<Note>
Allowing the outbound **Relay (TURN)** service below is **recommended** in more restricted networks for reliable peer connections. This will also improve the reliability of your [High Availability Routes](https://docs.netbird.io/manage/network-routes#high-availability).
</Note>
<Note>
If using `fail2ban` or similar, you should whitelist each netbird.io endpoint below.
</Note>
Below is the list of **NetBird Cloud** endpoints and ports they listen to. If you are self-hosting NetBird, your clients connect to your own server endpoints instead — see the [self-hosted guide port requirements](/selfhosted/selfhosted-guide#port-requirements).
* Management service:
* **Endpoint**: api.netbird.io
* **Port**: TCP/443
* **IPv4**: 35.186.199.111, 85.9.201.14, 85.9.206.109, 213.163.201.31, 213.163.206.27, 85.9.196.80, 209.151.150.249
* **IPv6**: 2600:1901:0:adb3::, 2a04:3542:1000:910:2465:1fff:fe8a:5597, 2a04:3542:1000:910:2465:1fff:fe8a:2f9a, 2a04:3543:1000:2310:2465:1fff:fe8a:5f8d, 2a04:3543:1000:2310:2465:1fff:fe8a:1308, 2605:7380:8000:1000:2465:1fff:fe8a:3b62, 2605:7380:8000:1000:2465:1fff:fe8a:4dcd
* Signal service:
* **Endpoint**: signal.netbird.io
* **Port**: TCP/443
* **IPv4**: 35.186.199.111, 85.9.201.14, 85.9.206.109, 213.163.201.31, 213.163.206.27, 85.9.196.80, 209.151.150.249
* **IPv6**: 2600:1901:0:adb3::, 2a04:3542:1000:910:2465:1fff:fe8a:5597, 2a04:3542:1000:910:2465:1fff:fe8a:2f9a, 2a04:3543:1000:2310:2465:1fff:fe8a:5f8d, 2a04:3543:1000:2310:2465:1fff:fe8a:1308, 2605:7380:8000:1000:2465:1fff:fe8a:3b62, 2605:7380:8000:1000:2465:1fff:fe8a:4dcd
* P2P (STUN) service:
* **Endpoint**: stun.netbird.io
* **Port range**: UDP/80,443,3478,5555
* **IPv4**: The list is dynamic and geo-distributed; we advise you to check the nearest cluster with the following command:
* `nslookup stun.netbird.io`
* 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 tcp dport 443-443 accept`
* Relay (TURN) service:
* **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
* Example `nftables` outbound firewall rule: `ip daddr turn.netbird.io tcp dport 443-65535 accept`
* Relay service:
* **Endpoint**: *.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>
</Note>
The NetBird client doesn't require any incoming port to be open. For the full list of outbound endpoints, ports, and example firewall rules for NetBird Cloud, see [Ports & Firewalls](/about-netbird/ports-and-firewalls#network-firewall-ports). If you self-host, see the [self-hosted port requirements](/selfhosted/selfhosted-guide#port-requirements).
## How does NetBird interact with 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.
### Platform behavior
| Platform | Firewall Manager | Automatic Rule |
|----------|------------------|----------------|
| Windows | Windows Firewall | Allows all traffic on NetBird interface |
| Linux | iptables/nftables | Adds rules for NetBird traffic |
### Network firewall vs. host-based firewall
It is important to understand the distinction:
- **Network/perimeter firewall** (Fortigate, pfSense, cloud security groups): Controls traffic entering
and leaving your network. NetBird requires **no inbound ports** on these devices. All connections are
initiated outbound using ICE/STUN for NAT traversal.
- **Host-based firewall** (Windows Firewall, UFW, iptables): Controls traffic on the individual machine.
NetBird automatically adds rules to allow traffic on the `wt0` interface.
### UFW conflicts on Linux
[UFW](https://wiki.ubuntu.com/UncomplicatedFirewall) (Uncomplicated Firewall) is a popular frontend for
iptables on Ubuntu and other Linux distributions. When you enable UFW, its default policy is:
- **Incoming**: Deny all
- **Outgoing**: Allow all
This can conflict with NetBird because both UFW and NetBird manage iptables rules. The conflict is about
**chain evaluation order**, not about opening ports to the internet:
1. WireGuard UDP packets arrive via hole punching (no inbound port needed on your router)
2. NetBird decrypts them and presents traffic on the `wt0` interface
3. UFW may evaluate its deny rules before NetBird's allow rules
4. Result: Traffic blocked at the host level despite successful hole punching
**Solution**: Allow traffic on the NetBird interface:
```bash
sudo ufw allow in on wt0
```
This does **not** open any ports to the internet. It allows traffic on the virtual `wt0` interface, which
only carries already-authenticated, already-encrypted NetBird traffic.
**Verify the rule**:
```bash
sudo ufw status | grep wt0
```
### Windows Firewall
NetBird creates a Windows Firewall rule automatically during installation/connection. This rule allows
traffic on the NetBird IP address (the `wt0` interface after decryption).
If traffic is blocked despite NetBird showing peers as connected, check for:
- Group Policy overriding the NetBird rule
- Third-party security software (antivirus, endpoint protection) with its own firewall
- The rule failing to apply due to permissions
**Check if the NetBird rule exists**:
```powershell
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" }
```
#### Environments without NAT
In flat office networks or routed VLANs without NAT, an additional firewall rule may be needed for P2P
to work. This is because Windows Firewall sees incoming WireGuard UDP packets as unsolicited traffic
when there is no NAT state tracking the connection.
```powershell
New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 49152-65535 -Program "C:\Program Files\Netbird\netbird.exe"
```
See [Environments without NAT](/help/troubleshooting-client#environments-without-nat-flat-networks-routed-vlans)
for details.
### Troubleshooting
If you suspect host-based firewall issues, capture a debug bundle:
```bash
netbird debug bundle --system-info
```
The `--system-info` flag includes network routes and interface configuration, which helps identify
firewall-related issues. See [Host-based firewall issues](/help/troubleshooting-client#host-based-firewall-issues)
for detailed troubleshooting steps.
NetBird automatically adds rules to allow traffic on the `wt0` interface on Windows and Linux. For platform behavior, common conflicts (UFW, firewalld, Windows Firewall, third-party security software), and remediation steps, see [Ports & Firewalls](/about-netbird/ports-and-firewalls#host-based-firewalls).
## Why and what are the anonymous usage metrics?

290
src/pages/about-netbird/ports-and-firewalls.mdx Normal file
View File

@@ -0,0 +1,290 @@
import {Note} from "@/components/mdx";
export const description = 'Ports, endpoints, and firewall configuration for NetBird, including host-based firewall behavior on Windows and Linux.';
# Ports & Firewalls
The NetBird client does not require any inbound ports on your network firewall — peers initiate all connections outbound and use ICE/STUN for NAT traversal. On the host, NetBird automatically manages rules to allow traffic on its `wt0` interface. This page covers both layers: which outbound endpoints to allow on perimeter firewalls, and how NetBird interacts with host-based firewalls (UFW, firewalld, Windows Firewall) when things go wrong.
<Note>
The endpoints and IPs listed on this page are for **NetBird Cloud**. If you are self-hosting NetBird, your clients connect to your own server endpoints instead — see the [self-hosted guide port requirements](/selfhosted/selfhosted-guide#port-requirements).
</Note>
## Network firewall ports
This section covers **network/perimeter firewall** requirements (e.g., Fortigate, pfSense, cloud security groups). For host-based firewalls (Windows Firewall, UFW, iptables), see [Host-based firewalls](#host-based-firewalls) below.
### Incoming ports
The NetBird client doesn't require any incoming port to be open; it negotiates the connection with the support of the signal and relay services.
### Outgoing ports
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).
</Note>
<Note>
If using `fail2ban` or similar, you should whitelist each netbird.io endpoint below.
</Note>
* Management service:
* **Endpoint**: api.netbird.io
* **Port**: TCP/443
* **IPv4**: 35.186.199.111, 85.9.201.14, 85.9.206.109, 213.163.201.31, 213.163.206.27, 85.9.196.80, 209.151.150.249
* **IPv6**: 2600:1901:0:adb3::, 2a04:3542:1000:910:2465:1fff:fe8a:5597, 2a04:3542:1000:910:2465:1fff:fe8a:2f9a, 2a04:3543:1000:2310:2465:1fff:fe8a:5f8d, 2a04:3543:1000:2310:2465:1fff:fe8a:1308, 2605:7380:8000:1000:2465:1fff:fe8a:3b62, 2605:7380:8000:1000:2465:1fff:fe8a:4dcd
* Signal service:
* **Endpoint**: signal.netbird.io
* **Port**: TCP/443
* **IPv4**: 35.186.199.111, 85.9.201.14, 85.9.206.109, 213.163.201.31, 213.163.206.27, 85.9.196.80, 209.151.150.249
* **IPv6**: 2600:1901:0:adb3::, 2a04:3542:1000:910:2465:1fff:fe8a:5597, 2a04:3542:1000:910:2465:1fff:fe8a:2f9a, 2a04:3543:1000:2310:2465:1fff:fe8a:5f8d, 2a04:3543:1000:2310:2465:1fff:fe8a:1308, 2605:7380:8000:1000:2465:1fff:fe8a:3b62, 2605:7380:8000:1000:2465:1fff:fe8a:4dcd
* P2P (STUN) service:
* **Endpoint**: stun.netbird.io
* **Port range**: UDP/80,443,3478,5555
* **IPv4**: The list is dynamic and geo-distributed; we advise you to check the nearest cluster with the following command:
* `nslookup stun.netbird.io`
* 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 tcp dport 443-443 accept`
* Relay (TURN) service:
* **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
* Example `nftables` outbound firewall rule: `ip daddr turn.netbird.io tcp dport 443-65535 accept`
* Relay service:
* **Endpoint**: *.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>
</Note>
## 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.
### Platform behavior
| Platform | Firewall Manager | Automatic Rule |
|----------|------------------|----------------|
| Windows | Windows Firewall | Allows all traffic on NetBird interface |
| Linux | iptables/nftables | Adds rules for NetBird traffic |
### Network firewall vs. host-based firewall
It is important to understand the distinction:
- **Network/perimeter firewall** (Fortigate, pfSense, cloud security groups): Controls traffic entering and leaving your network. NetBird requires **no inbound ports** on these devices. All connections are initiated outbound using ICE/STUN for NAT traversal.
- **Host-based firewall** (Windows Firewall, UFW, iptables): Controls traffic on the individual machine. NetBird automatically adds rules to allow traffic on the `wt0` interface.
### Symptoms of host-based firewall issues
- Peers show as "Connected" in `netbird status` but cannot ping or reach each other
- Connection works on some machines but not others with the same network configuration
- Connection works after disabling the host firewall but fails when re-enabled
- P2P connections work but routed traffic does not
When another tool also manages firewall rules, conflicts can occur:
| Tool | Conflict Type |
|------|---------------|
| UFW (Linux) | Chain ordering — UFW may evaluate its deny rules before NetBird's allow rules |
| firewalld (Linux) | Zone conflicts — NetBird interface may be in wrong zone |
| Windows Group Policy | Policy may override or remove NetBird's firewall rule |
| Third-party security software | May block traffic independently of OS firewall |
### UFW (Linux)
[UFW](https://wiki.ubuntu.com/UncomplicatedFirewall) (Uncomplicated Firewall) is a popular frontend for iptables on Ubuntu and other Linux distributions. When you enable UFW, its default policy is:
- **Incoming**: Deny all
- **Outgoing**: Allow all
This can conflict with NetBird because both UFW and NetBird manage iptables rules. The conflict is about **chain evaluation order**, not about opening ports to the internet:
1. WireGuard UDP packets arrive via hole punching (no inbound port needed on your router)
2. NetBird decrypts them and presents traffic on the `wt0` interface
3. UFW may evaluate its deny rules before NetBird's allow rules
4. Result: Traffic blocked at the host level despite successful hole punching
**Check UFW status**:
```bash
sudo ufw status verbose
```
**Allow traffic on the NetBird interface**:
```bash
sudo ufw allow in on wt0
```
This does **not** open any ports to the internet. It allows traffic on the virtual `wt0` interface, which only carries already-authenticated, already-encrypted NetBird traffic.
**Verify the rule was added**:
```bash
sudo ufw status | grep wt0
```
Expected output:
```
Anywhere on wt0 ALLOW Anywhere
Anywhere (v6) on wt0 ALLOW Anywhere (v6)
```
**Alternative — allow only the NetBird subnet**:
If you prefer a more restrictive rule:
```bash
sudo ufw allow in on wt0 from 100.64.0.0/10
```
### firewalld (Linux)
On distributions using firewalld (RHEL, CentOS, Fedora), ensure the `wt0` interface is in a trusted zone:
**Check current zone for wt0**:
```bash
sudo firewall-cmd --get-zone-of-interface=wt0
```
**Add wt0 to trusted zone**:
```bash
sudo firewall-cmd --permanent --zone=trusted --add-interface=wt0
sudo firewall-cmd --reload
```
### Windows Firewall
NetBird creates a Windows Firewall rule automatically during installation/connection. This rule allows traffic on the NetBird IP address (the `wt0` interface after decryption).
If traffic is blocked despite NetBird showing peers as connected, check for:
- Group Policy overriding the NetBird rule
- Third-party security software (antivirus, endpoint protection) with its own firewall
- The rule failing to apply due to permissions
**Check if the NetBird rule exists**:
```powershell
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" } | Format-List DisplayName, Enabled, Direction, Action
```
**Check the address filter applied to the rule**:
```powershell
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" } | Get-NetFirewallAddressFilter
```
**Manually create the rule if missing**:
```powershell
New-NetFirewallRule -DisplayName "NetBird" -Direction Inbound -InterfaceAlias "wt0" -Action Allow
```
**Check for Group Policy overrides**:
If the rule exists but traffic is still blocked, Group Policy may be overriding local firewall rules. Check with your IT administrator or review:
```powershell
Get-NetFirewallProfile | Format-List Name, Enabled, DefaultInboundAction
```
### Environments without NAT (flat networks, routed VLANs)
In most environments, NAT provides stateful connection tracking. When Peer A sends UDP to Peer B, the return traffic is allowed because the NAT device tracks it as part of an established connection.
However, in environments **without NAT between peers** (e.g., flat office networks, routed VLANs without masquerading), Windows Firewall may block incoming WireGuard P2P traffic because:
1. There is no NAT state tracking the "connection"
2. Windows Firewall sees the incoming UDP packets as unsolicited inbound traffic
3. The default NetBird rule only covers traffic on the `wt0` interface (after decryption), not the raw WireGuard packets arriving on the physical interface
**Symptoms**:
- P2P works when one peer is behind NAT but fails when both peers are on the same flat network
- `netbird status -d` shows connection type as "Relayed" instead of "P2P" for local peers
- P2P works after disabling Windows Firewall
**Solution**: Add a firewall rule to allow inbound UDP for WireGuard P2P traffic, scoped to the NetBird process:
```powershell
New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 49152-65535 -Program "C:\Program Files\Netbird\netbird.exe"
```
This rule:
- Allows inbound UDP on the ephemeral port range (used for WireGuard)
- Is scoped to only the NetBird process for security
- Does not expose any other services
<Note>
This is only needed in environments without NAT between peers. If your peers connect through NAT (typical for remote access scenarios), the default rules are sufficient.
</Note>
**Linux in non-NAT environments**: The same principle applies. If UFW or firewalld is blocking inbound UDP on the physical interface, you may need to allow it. Linux cannot scope firewall rules to a specific process like Windows can, so a broader rule is required:
```bash
# UFW — allows inbound UDP on ephemeral ports (less restrictive than the Windows equivalent)
sudo ufw allow in proto udp to any port 49152:65535
```
Consider whether this is acceptable for your security posture, or use NetBird's relay fallback instead.
### Third-party security software
Antivirus and endpoint protection software often includes its own firewall that operates independently of the OS firewall. Common culprits include:
- Symantec Endpoint Protection
- McAfee
- Kaspersky
- ESET
- CrowdStrike Falcon
If you suspect third-party software is blocking NetBird:
1. Temporarily disable the third-party firewall component (not the entire product)
2. Test NetBird connectivity
3. If it works, add an exception for the NetBird process or the `wt0` interface
The NetBird process locations:
- **Windows**: `C:\Program Files\NetBird\netbird.exe`
- **Linux**: `/usr/bin/netbird`
- **macOS**: `/usr/local/bin/netbird`
### Collecting firewall diagnostics
When reporting firewall-related issues, capture a debug bundle with system information:
```bash
netbird debug bundle --system-info
```
The `--system-info` flag captures network routes, interface configuration, and firewall rules where accessible.
**Additional diagnostics for Linux**:
```bash
# Current iptables rules
sudo iptables -L -n -v
# nftables rules (if applicable)
sudo nft list ruleset
# UFW status
sudo ufw status verbose
```
**Additional diagnostics for Windows** (run as Administrator):
```powershell
# All firewall rules for wt0
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" -or $_.DisplayName -like "*wt0*" }
# Firewall profile status
Get-NetFirewallProfile
```
### Quick reference
| Platform | Check Command | Fix Command |
|----------|---------------|-------------|
| UFW (Linux) | `sudo ufw status` | `sudo ufw allow in on wt0` |
| firewalld (Linux) | `sudo firewall-cmd --get-zone-of-interface=wt0` | `sudo firewall-cmd --permanent --zone=trusted --add-interface=wt0 && sudo firewall-cmd --reload` |
| Windows | `Get-NetFirewallRule \| Where-Object { $_.DisplayName -like "*NetBird*" }` | Check Group Policy or third-party software |
| Windows (no NAT) | P2P shows as Relayed for local peers | `New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 49152-65535 -Program "C:\Program Files\Netbird\netbird.exe"` |

2
src/pages/about-netbird/understanding-nat-and-connectivity.mdx
View File

@@ -346,7 +346,7 @@ Corporate environments are often more restrictive. Work with your IT team to:
1. **Allow UDP outbound**: NetBird works best when UDP traffic is permitted to the STUN/TURN servers.
2. **Whitelist NetBird endpoints**: See the [FAQ](/about-netbird/faq) for the list of endpoints and ports.
2. **Whitelist NetBird endpoints**: See [Ports & Firewalls](/about-netbird/ports-and-firewalls) for the list of endpoints and ports.
3. **Consider split tunneling**: If full P2P isn't possible, ensure the relay ports are accessible.

204
src/pages/help/troubleshooting-client.mdx
View File

@@ -406,209 +406,7 @@ sudo bash -c 'PIONS_LOG_DEBUG=all NB_LOG_LEVEL=debug netbird up -F' > /tmp/netbi
## Host-based firewall issues
NetBird automatically adds firewall rules on all platforms to allow traffic on the NetBird interface (`wt0`).
However, conflicts can occur with other firewall management tools or security software.
### Symptoms
- Peers show as "Connected" in `netbird status` but cannot ping or reach each other
- Connection works on some machines but not others with the same network configuration
- Connection works after disabling the host firewall but fails when re-enabled
- P2P connections work but routed traffic does not
### Understanding the issue
NetBird manages firewall rules directly via iptables/nftables (Linux/macOS) or Windows Firewall APIs.
When another tool also manages firewall rules, conflicts can occur:
| Tool | Conflict Type |
|------|---------------|
| UFW (Linux) | Chain ordering - UFW may evaluate its deny rules before NetBird's allow rules |
| firewalld (Linux) | Zone conflicts - NetBird interface may be in wrong zone |
| Windows Group Policy | Policy may override or remove NetBird's firewall rule |
| Third-party security software | May block traffic independently of OS firewall |
### UFW (Linux)
UFW is a frontend for iptables commonly used on Ubuntu. Its default policy denies all incoming traffic,
which can block NetBird traffic before it reaches NetBird's iptables rules.
**Check UFW status**:
```bash
sudo ufw status verbose
```
If UFW is active with a default deny incoming policy, add a rule for the NetBird interface:
**Allow NetBird interface**:
```bash
sudo ufw allow in on wt0
```
**Verify the rule was added**:
```bash
sudo ufw status | grep wt0
```
Expected output:
```
Anywhere on wt0 ALLOW Anywhere
Anywhere (v6) on wt0 ALLOW Anywhere (v6)
```
**Alternative - Allow specific NetBird subnet**:
If you prefer a more restrictive rule:
```bash
sudo ufw allow in on wt0 from 100.64.0.0/10
```
### firewalld (Linux)
On distributions using firewalld (RHEL, CentOS, Fedora), ensure the `wt0` interface is in a trusted zone:
**Check current zone for wt0**:
```bash
sudo firewall-cmd --get-zone-of-interface=wt0
```
**Add wt0 to trusted zone**:
```bash
sudo firewall-cmd --permanent --zone=trusted --add-interface=wt0
sudo firewall-cmd --reload
```
### Windows Firewall
NetBird creates a Windows Firewall rule automatically that allows traffic on the NetBird IP address
(the `wt0` interface). This covers traffic after WireGuard decryption.
**Check if the NetBird rule exists**:
```powershell
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" } | Format-List DisplayName, Enabled, Direction, Action
```
**Check if the rule is being applied**:
```powershell
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" } | Get-NetFirewallAddressFilter
```
**Manually create the rule if missing**:
```powershell
New-NetFirewallRule -DisplayName "NetBird" -Direction Inbound -InterfaceAlias "wt0" -Action Allow
```
**Check for Group Policy overrides**:
If the rule exists but traffic is still blocked, Group Policy may be overriding local firewall rules.
Check with your IT administrator or review:
```powershell
Get-NetFirewallProfile | Format-List Name, Enabled, DefaultInboundAction
```
### Environments without NAT (flat networks, routed VLANs)
In most environments, NAT provides stateful connection tracking. When Peer A sends UDP to Peer B, the
return traffic is allowed because the NAT device tracks it as part of an established connection.
However, in environments **without NAT between peers** (e.g., flat office networks, routed VLANs without
masquerading), Windows Firewall may block incoming WireGuard P2P traffic because:
1. There is no NAT state tracking the "connection"
2. Windows Firewall sees the incoming UDP packets as unsolicited inbound traffic
3. The default NetBird rule only covers traffic on the `wt0` interface (after decryption), not the raw
WireGuard packets arriving on the physical interface
**Symptoms**:
- P2P works when one peer is behind NAT but fails when both peers are on the same flat network
- `netbird status -d` shows connection type as "Relayed" instead of "P2P" for local peers
- P2P works after disabling Windows Firewall
**Solution**: Add a firewall rule to allow inbound UDP for WireGuard P2P traffic, scoped to the NetBird process:
```powershell
New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 49152-65535 -Program "C:\Program Files\Netbird\netbird.exe"
```
This rule:
- Allows inbound UDP on the ephemeral port range (used for WireGuard)
- Is scoped to only the NetBird process for security
- Does not expose any other services
**Note**: This is only needed in environments without NAT between peers. If your peers connect through
NAT (typical for remote access scenarios), the default rules are sufficient.
**Linux in non-NAT environments**: The same principle applies. If UFW or firewalld is blocking inbound
UDP on the physical interface, you may need to allow it. However, Linux cannot scope firewall rules to
a specific process like Windows can. A broader rule would be required:
```bash
# UFW - allows inbound UDP on ephemeral ports (less restrictive than Windows equivalent)
sudo ufw allow in proto udp to any port 49152:65535
```
Consider whether this is acceptable for your security posture, or use NetBird's relay fallback instead.
### Third-party security software
Antivirus and endpoint protection software often includes its own firewall that operates independently
of the OS firewall. Common culprits include:
- Symantec Endpoint Protection
- McAfee
- Kaspersky
- ESET
- CrowdStrike Falcon
If you suspect third-party software is blocking NetBird:
1. Temporarily disable the third-party firewall component (not the entire product)
2. Test NetBird connectivity
3. If it works, add an exception for the NetBird process or the `wt0` interface
The NetBird process locations:
- **Windows**: `C:\Program Files\NetBird\netbird.exe`
- **Linux**: `/usr/bin/netbird`
- **macOS**: `/usr/local/bin/netbird`
### Collecting firewall diagnostics
When reporting firewall-related issues, include a debug bundle with system information:
```bash
netbird debug bundle --system-info
```
The `--system-info` flag captures:
- Network routes
- Interface configuration
- Firewall rules (where accessible)
**Additional diagnostics for Linux**:
```bash
# Current iptables rules
sudo iptables -L -n -v
# nftables rules (if applicable)
sudo nft list ruleset
# UFW status
sudo ufw status verbose
```
**Additional diagnostics for Windows** (run as Administrator):
```powershell
# All firewall rules for wt0
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" -or $_.DisplayName -like "*wt0*" }
# Firewall profile status
Get-NetFirewallProfile
```
### Quick reference
| Platform | Check Command | Fix Command |
|----------|---------------|-------------|
| UFW (Linux) | `sudo ufw status` | `sudo ufw allow in on wt0` |
| firewalld (Linux) | `sudo firewall-cmd --get-zone-of-interface=wt0` | `sudo firewall-cmd --permanent --zone=trusted --add-interface=wt0 && sudo firewall-cmd --reload` |
| Windows | `Get-NetFirewallRule \| Where-Object { $_.DisplayName -like "*NetBird*" }` | Check Group Policy or third-party software |
| Windows (no NAT) | P2P shows as Relayed for local peers | `New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Action Allow -Protocol UDP -LocalPort 49152-65535 -Program "C:\Program Files\Netbird\netbird.exe"` |
NetBird automatically manages host-based firewall rules, but conflicts can occur with other firewall tools or security software. See [Ports & Firewalls — Host-based firewalls](/about-netbird/ports-and-firewalls#host-based-firewalls) for symptoms, platform-specific remediation (UFW, firewalld, Windows Firewall), and diagnostic commands.
## Client login failures

4
src/pages/use-cases/security/implement-zero-trust.mdx
View File

@@ -40,7 +40,7 @@ If you self-host, ensure that Management (the central coordination and authentic
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.
<Note>
For a complete list of NetBird endpoints, IP addresses, and detailed firewall configuration examples, see the [FAQ: What firewall ports should I open to use NetBird?](/about-netbird/faq#what-firewall-ports-should-i-open-to-use-netbird-network-firewalls)
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)
</Note>
**Understanding the services:**
@@ -57,7 +57,7 @@ For a complete list of NetBird endpoints, IP addresses, and detailed firewall co
</p>
<Note>
- For a list of outbound ports required for NetBird Cloud, see the [FAQ: What firewall ports should I open to use NetBird?](/about-netbird/faq#what-firewall-ports-should-i-open-to-use-netbird-network-firewalls)
- For a list of outbound ports required for NetBird Cloud, see the [Ports & Firewalls](/about-netbird/ports-and-firewalls#network-firewall-ports)
- For a list of outbound ports required for self-hosted NetBird, see the [self-hosted guide](/selfhosted/selfhosted-guide#port-requirements)
</Note>
---