What firewall ports should I open to use NetBird (Network Firewalls)?

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?

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

Below is the list of NetBird hosted endpoints and ports they listen to:

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

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

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

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:

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:

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.

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 for details.

Troubleshooting

If you suspect host-based firewall issues, capture a debug bundle:

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 for detailed troubleshooting steps.

Why and what are the anonymous usage metrics?

Why did we add metrics collection?

As an open-source project and business, making data-driven decisions is essential. By collecting anonymous metrics, we can understand our adoption rate, feature usage, and the types of client operating systems in use. We kindly ask our community users to keep metrics enabled, as this helps us assess the impact of bugs and measure the quality of our software over time.

If the metric collection infringes any internal regulation or policy, it can be disabled by setting the flag --disable-anonymous-metrics=true to the management service startup command. the default interval is 12 hours, but it can be adjusted with the environment variable NETBIRD_METRICS_INTERVAL_IN_SECONDS.

What are the metrics being collected?

We are collecting the following metrics:

• Number of accounts
• Number of users
• Number of peers
• Number of active peers in the last 24 hours
• Number of peers per operating system
• Number of setup keys usage
• Number of peers activated by users
• Number of groups
• Feature usage, like number of routes, access control policies and nameservers
• Service uptime
• Service version
• Metrics generation time

Metrics UUID

We are using an installation ID for each management service which is generated once and stored in your management store database. It doesn't have any trace of any other private information, and it helps distinguish each deployment.

Metrics pusher IP

We are not storing the pusher IP address; it gets discarded once the request is complete.