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.

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 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 and negotiate the peer-to-peer connections.

• 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.

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

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:

UFW (Linux)

UFW (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:

sudo ufw status verbose

Allow traffic on the NetBird interface:

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:

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:

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:

sudo firewall-cmd --get-zone-of-interface=wt0

Add wt0 to trusted zone:

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:

Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" } | Format-List DisplayName, Enabled, Direction, Action

Check the address filter applied to the rule:

Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" } | Get-NetFirewallAddressFilter

Manually create the rule if missing:

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:

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:

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

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:

# 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:

netbird debug bundle --system-info

The --system-info flag captures network routes, interface configuration, and firewall rules where accessible.

Additional diagnostics for Linux:

# 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):

# All firewall rules for wt0
Get-NetFirewallRule | Where-Object { $_.DisplayName -like "*NetBird*" -or $_.DisplayName -like "*wt0*" }

# Firewall profile status
Get-NetFirewallProfile

Quick reference