some file

What firewall ports should I open to use NetBird?

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.

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.

If using fail2ban or similar, you should whitelist each netbird.io endpoint below.

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
      • IPv6: 2600:1901:0:adb3::
  • Signal service:
    • Endpoint: signal.netbird.io
      • Port: TCP/443
      • IPv4: 35.186.199.111
      • IPv6: 2600:1901:0:adb3::
  • 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.

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.

The collection is strict to our management system.

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