Ports & Firewalls

Updated August 25, 2026

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.

Inbound ports

The NetBird client doesn't require any inbound port to be open; it negotiates the connection with the support of the signal and relay services.

Outbound ports

NetBird usually won't need open ports, but sometimes you or your IT team needs to secure and verify all outbound 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 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 service (TCP/QUIC):

  • Endpoints: *.relay.netbird.io and relay.netbird.io
  • Ports: TCP/443 (WebSocket) and UDP/443 (QUIC)
  • Clients v0.36.0 and later try both transports and use whichever connects first. If UDP/443 is blocked, the client falls back to WebSocket over TCP/443, so QUIC is an optimization, not a requirement.
  • IPv4: The list is dynamic and geo-distributed. The netbird status -d output shows which relay you are connecting to.
  • It is advised to wildcard *.relay.netbird.io when possible, to avoid interrupts.

• Relay service (legacy):

  • Endpoint: turn.netbird.io
    • Legacy fallback only: needed for clients older than v0.29.0. Newer clients relay through the NetBird relay service above and fall back to this TURN relay only if that relay is unreachable.
    • 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 the relay
      • Example nftables outbound firewall rule: ip daddr turn.netbird.io tcp dport 443-65535 accept

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

Static peer ports for site-to-site firewall rules

Some organizations run strict egress policies at every branch office: outbound traffic is allowed only to named destinations and ports. To guarantee direct peer-to-peer connections from every branch to the peers at a main location (a data center or headquarters), the branch firewalls need a rule like "allow UDP to the main location on these ports", and that rule only stays valid if those ports never change.

By default they can change. Running netbird status -d on a branch peer shows something like:

ICE candidate endpoints (Local/Remote): 172.17.192.1:51820 / 203.0.113.10:51823

The local port is the peer's WireGuard listening port (default 51820; NetBird's ICE negotiation shares the same socket). The remote port, 51823 here, is whatever public port the main location's NAT happened to assign to that peer's session. The mistake to avoid is writing a branch firewall rule against that observed port: it is a dynamic NAT mapping, and it can be reassigned whenever the session state expires or the NAT device restarts. To make it stable, pin it at both layers at the main location, the peer and the NAT in front of it:

1. Give each peer at the main location a distinct WireGuard port. Allocate a range up front, sized for growth (for example 51820-51839 for up to 20 peers), and assign one port per peer:

   netbird up --wireguard-port 51821
   

   CopyCopied!

   The port persists in the peer's configuration across restarts. Track the assignments; two peers behind the same public IP must not share a port.

   The pinned port is a preference, not a guarantee: if another process already holds it when NetBird starts, the client falls back to a random free port and only notes it in the client log (using <port> as wireguard port: <configured port> is in use). Reserve the port for NetBird on each peer, and re-verify after anything that could have raced it at startup.

2. Make the main location's NAT preserve that port. Prefer the outbound-only approach: set the firewall's source NAT mode to preserve the source port for these peers (Static Port outbound NAT on pfSense and OPNsense, Persistent Dynamic IP And Port on Palo Alto; see the Corporate firewalls table for other vendors), and raise the UDP session timeout (around 240 seconds or more) so mappings are not torn down between WireGuard keepalives. With the port preserved, the public port equals the pinned WireGuard port, hole punching opens the path as usual, and nothing is exposed inbound.

   If the firewall has no port-preserving NAT mode, or the mapping must hold with no dependence on NAT session state at all, add a static destination NAT (port forwarding) rule per peer instead: UDP on the peer's assigned port, from the public IP to the peer's LAN address, same port. A static bidirectional DNAT is sufficient on its own and cannot expire or be reassigned, but it is an inbound opening; treat it as the last resort, not the default.

3. Allow outbound UDP from each branch to the main location's public IPs on the allocated range. This is the only rule the branches need, and it never changes: adding a peer at the main site later means assigning it a free port from the range and covering that port in the main site's NAT setup, with no change at any branch.

To verify, check a branch peer after reconnecting (netbird down && netbird up): the connection type should read P2P, and the remote ICE candidate endpoint should show the exact port assigned to the main-location peer. A different port there means the main-location peer fell back because its pinned port was occupied at startup; free the port on that peer and restart NetBird.

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 inbound WireGuard P2P traffic because:

1. There is no NAT state tracking the "connection"
2. Windows Firewall sees the inbound 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