some file

FAQ

What firewall ports should I open to use NetBird?

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. If you self-host, see the self-hosted port requirements.

How does NetBird interact with host-based firewalls?

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.

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, users, and service users
  • Number of personal access tokens
  • Number of peers (total, SSH-enabled, login expiration enabled, user-activated)
  • Number of active peers and active users in the last collection interval
  • Number of peers per operating system (total and active)
  • Number of UI clients and their operating systems
  • Number of setup keys usage (including ephemeral peer setup keys)
  • Number of groups
  • Number of routes (including routes with routing groups)
  • Number of networks, network resources, and network routers
  • Number of access control policy rules (by protocol and direction)
  • Number of posture checks and rules with source posture checks
  • Number of reverse proxy services (total, enabled, by status, by target type, by auth type)
  • Number of service targets (by type: peer, host, domain, subnet)
  • Number of custom domains (total and validated)
  • Rosenpass usage
  • IdP manager type and embedded IdP provider breakdown
  • Store engine type
  • Service uptime
  • Service version (including min/max active peer versions)
  • 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.