NetBird Platform

netbird-platform — Round 1 Research Report

Session: 20260321-0115 Domain: NetBird Platform Features & Architecture Date: 2026-03-21 Tools Used: mcp__claude_ai_Tavily__tavily_search (7 queries), mcp__claude_ai_Tavily__tavily_research (1 query), WebSearch (2 queries), mcp__exa_websearch__web_search_exa (2 queries), WebFetch (8 pages), mcp__context7__resolve-library-id (1 query), mcp__context7__query-docs (1 query)

Executive Summary

NetBird is a mature, actively-developed open-source WireGuard-based mesh VPN platform with 23,700+ GitHub stars, 131+ contributors, and 306+ releases as of March 2026. The latest version is v0.66.4 (March 11, 2026) with releases averaging 2-3 per week. The project is backed by a German company that received funding from the German Federal Ministry of Education and Research through the StartUpSecure program (November 2022), in partnership with CISPA Helmholtz Center for Information Security.

NetBird is a strong candidate for replacing Palo Alto GlobalProtect for GSISG’s 100+ user deployment. Its self-hosted architecture can run on modest hardware (1 vCPU / 2GB RAM minimum), it supports pfSense integration (though via manual install, not yet in the official pfSense package manager), and it provides split DNS, network routing, and a new built-in reverse proxy feature. However, there are notable caveats: high-availability for the management server requires an enterprise license, the pfSense package is still early-stage (v0.1.0, bundled with NetBird client v0.55.1), and some reliability concerns exist around automatic reconnection after outages.

Overall Assessment: NetBird is technically capable for the GSISG use case but requires careful planning around HA, relay infrastructure sizing, and pfSense integration maturity. For a 100+ user deployment across two offices, the self-hosted option is viable on an Azure B2s (2 vCPU / 4GB RAM) VM with separated relay servers, but an enterprise license should be evaluated for HA guarantees.

Findings

1. Project Maturity & Release Status

Metric	Value	Confidence	Source
GitHub Stars	~23,700	HIGH	GitHub repo
Contributors	131+	HIGH	GitHub repo
Total Releases	306+	HIGH	GitHub releases page
Latest Version	v0.66.4 (March 11, 2026)	HIGH	GitHub releases
Release Cadence	2-3 per week (avg every 2-4 days)	HIGH	Release dates analysis
Language	Go (96.5%)	HIGH	GitHub repo
License	BSD-3-Clause (client) + AGPLv3 (management/signal/relay, since v0.53.0)	HIGH	GitHub repo
Backing	German Federal Ministry of Education and Research / CISPA (StartUpSecure program, Nov 2022)	HIGH	GitHub README
Founded	Germany-based company	MEDIUM	Multiple sources

Release History (last 10):

v0.66.4 — March 11, 2026
v0.66.3 — March 9, 2026
v0.66.2 — March 4, 2026
v0.66.1 — March 3, 2026
v0.66.0 — February 24, 2026
v0.65.3 — February 19, 2026
v0.65.2 — February 17, 2026
v0.65.1 — February 14, 2026
v0.65.0 — February 13, 2026
v0.64.6 — February 12, 2026

The project is very actively maintained with a rapid release cadence. Major features ship roughly monthly (v0.60 in Nov 2025, v0.62 in Jan 2026, v0.65 in Feb 2026, v0.66 in late Feb 2026).

2. Self-Hosted Deployment Components

Component	Description	Required?	Resource Notes
Management Server	Core control plane — peer registration, auth, network map, policy enforcement, API	Yes	Lightweight Go binary; main CPU consumer during peer sync
Signal Server	WebRTC-style signaling for peer connection negotiation; encrypted candidate exchange	Yes	Low resource; can stay embedded in combined server
Relay Server	QUIC/WebSocket relay for peers that cannot establish direct P2P (replaces legacy Coturn TURN)	Yes	Most resource-intensive under load; CPU scales with relayed traffic
STUN Server	Embedded in relay server; used for NAT type discovery and public IP detection	Yes (embedded)	Minimal overhead
Dashboard	Web UI for administration (embedded nginx)	Yes	Static files; minimal resources
Traefik	Reverse proxy for TLS termination (ports 80/443)	Yes (for self-hosted)	Standard Traefik resource profile
Identity Provider (IdP)	SSO authentication; can be embedded (v0.62+) or external	Optional	Embedded: minimal additional overhead; External (Authentik/Keycloak): 2 vCPU + 2GB RAM additional
Database	SQLite (default) or PostgreSQL (recommended for 100+ peers)	Yes	SQLite for small; PostgreSQL for production scale

Architecture Evolution (Important):

Pre-v0.62: Required separate containers for management, signal, relay, coturn, dashboard, plus an external IdP (e.g., Zitadel). Total: 7+ containers, 2-4GB RAM minimum.
v0.62+: Unified netbird-server container combines management, signal, relay, and embedded STUN. Built-in local user management eliminates mandatory external IdP. Total: 3-4 containers (server, dashboard, traefik, optional DB), ~1GB RAM minimum.
v0.65+: Further consolidation with unified server binary. Reverse proxy capability added.

Minimum Infrastructure Requirements (from official docs):

1 Linux VM with at least 1 vCPU and 2GB RAM
TCP ports 80, 443 publicly accessible
UDP port 3478 publicly accessible
A public domain name pointing to the VM’s IP
Docker Compose installed

Confidence: HIGH — sourced from official documentation at docs.netbird.io

3. Azure B1ms Viability for 100+ Peers

Short answer: An Azure B1ms (1 vCPU, 2GB RAM) will likely work for the management plane but is risky under relay load. An Azure B2s (2 vCPU, 4GB RAM) is the safer minimum.

Factor	Assessment
Management server on 1 vCPU / 2GB RAM	Officially supported as minimum; will handle peer registration and policy sync
100+ peers simultaneously	The historical 100-peer limit (GitHub issue #1824) was a buffer size bug, not an architectural limit. It was fixed (closed Feb 2025). NetBird states “you can have hundreds of thousands of nodes”
Relay traffic at scale	CPU-intensive; one user reported 50% CPU with only 25 peers when many connections are relayed. This is the main concern for B1ms
SQLite vs PostgreSQL	SQLite is default; for 100+ peers, PostgreSQL on a separate instance is recommended
With external IdP (Authentik/Keycloak)	Requires 2+ vCPU and 4+ GB RAM total — B1ms is insufficient

Recommended Azure Architecture for 100+ Users:

Component	Azure SKU	Est. Cost
Main server (management + signal + dashboard)	B2s (2 vCPU, 4GB)	~$30/mo
Relay server(s) — 1-2 depending on geography	B1ms or B2s	~$15-30/mo each
PostgreSQL	Azure Database for PostgreSQL (Basic) or co-located	~$25/mo

Scaling path (from NetBird docs):

Start with single-server deployment
Extract relay servers to separate VMs (most common first step)
Move PostgreSQL to dedicated instance
Signal server extraction (rarely needed)
Management + Signal HA requires enterprise commercial license

Confidence: MEDIUM-HIGH — official docs confirm 1vCPU/2GB minimum; scaling recommendations from docs + community reports. Azure-specific sizing is extrapolated.

4. pfSense Package Status

The NetBird pfSense package is NOT in the official pfSense package manager. It requires manual installation.

Detail	Status
Official pfSense repo	NOT available — PR submitted ~1 year ago (Aug 2025), still pending review as of March 2026
Installation method	Manual `pkg add` from GitHub releases
pfSense package version	v0.1.0
Bundled NetBird client version	v0.55.1 (significantly behind latest v0.66.4)
pfSense versions supported	Not explicitly documented; works on FreeBSD-based pfSense CE and Plus
OPNsense support	Also available (announced Sep 2025 newsletter)
FreeBSD ports	NetBird was accepted into FreeBSD ports repository (Jun 2025)
Update mechanism	Manual download and reinstall of `.pkg` files

Known Limitations on pfSense:

Version lag: pfSense package bundles NetBird v0.55.1 while the mainline is at v0.66.4 — an 11-version gap
NAT traversal conflict: pfSense’s automatic outbound NAT randomizes source ports, which breaks NetBird’s NAT traversal. Requires manual static port NAT rule configuration
Site-to-site routing issues: GitHub issue reports problems with LAN resource routing through pfSense (#5 in pfsense-netbird repo)
Crash on update: NetBird 0.61.0 and pfSense package v0.2.1 reported segfault when trying to update
No automatic updates: Must manually download and install new versions
LAN scanning disruption: Reported that network scanning tools cause disruption when NetBird is running on pfSense
WireGuard package conflicts: Installing NetBird can cause issues with existing WireGuard packages on pfSense

Confidence: HIGH — sourced from official NetBird pfSense docs, GitHub issues, and pfSense package list

5. Always-On Mode & Management Server Resilience

Always-On Mode

NetBird supports always-on operation through two mechanisms:

Setup Key Peers (servers, routing peers, headless devices):

No login expiration — tunnels stay up indefinitely
No SSO interaction required
Automatically reconnects after reboots (daemon auto-starts)
Setup keys can be one-off or reusable, with optional expiration dates
Revoking a key does NOT immediately disconnect already-connected peers

SSO Peers (user workstations):

Default session expiration: 24 hours (configurable from 1 hour to 180 days)
Session expiration can be disabled globally or per-peer
When session expires, tunnel is torn down and user must re-authenticate via browser
After re-authentication, tunnel automatically re-establishes

Management Server Down — What Happens?

Scenario	Behavior
Existing P2P tunnels	Survive — WireGuard tunnels are end-to-end encrypted between peers; management server is not in the data path
Existing relayed connections	Continue working as long as relay server is reachable (relay is a separate component)
New peer connections	Cannot be established — peers need management server for initial configuration and peer discovery
Policy changes	Cannot be applied until management server returns
Peer reconnection after brief network glitch	Generally works automatically
Peer reconnection after prolonged outage	Known issue — clients sometimes stay offline indefinitely and require manual `netbird up` command
DNS resolution	Continues working if DNS servers are reachable; cached entries persist

Critical architectural insight: The management server maintains “a control channel open to each peer sending network updates.” This is used for configuration sync, not for data plane traffic. The data plane (WireGuard tunnels) operates independently once established.

Known reliability concerns (from GitHub issues and Tavily research):

Automatic reconnection after network outages is not always reliable (issues #1361, #1853)
UI may show “connected” status while the underlying WireGuard handshake has timed out (issue #2109)
After a management server restart, in-memory sessions are lost; clients must reconnect
NetBird auto-starts after reboot even if user previously ran netbird down (may be unexpected)

Confidence: HIGH for architecture details; MEDIUM for reliability concerns (sourced from multiple GitHub issues and community reports, but may be version-specific)

6. NAT Traversal Capabilities

NetBird uses ICE (Interactive Connectivity Establishment) — the same protocol underlying WebRTC — for NAT traversal.

Connection Establishment Process

Candidate gathering: Discovers host candidates (local IPs), server reflexive candidates (via STUN), and relay candidates
Candidate exchange: Peers share candidates via the Signal server (encrypted with peer keys)
Connectivity checks: Tests candidate pairs, prioritizing direct connections
NAT hole punching: Simultaneous UDP packets from both peers to “punch holes” through NAT

NAT Type Handling

NAT Type	P2P Likelihood	NetBird Behavior
Easy/Full Cone NAT (home routers)	High	Direct P2P via STUN discovery
Port-Restricted Cone NAT	Medium-High	P2P usually succeeds with hole punching
Symmetric NAT (corporate firewalls)	Low	Falls back to relay; public IP:port mapping changes per destination
CGNAT (mobile/ISP)	Low-Medium	Double NAT, shared IPs, short timeouts; often relayed
1:1 NAT (cloud VMs)	High	Behaves like easy NAT if security groups permit UDP
No NAT (data center)	Very High	Direct connection trivial

Relay System

Primary transport: QUIC (UDP-based, high performance)
Fallback transport: WebSocket over TCP port 443 (for networks that block UDP)
Both protocols are raced simultaneously — whichever succeeds first is used
Relay traffic remains end-to-end encrypted via WireGuard — relay cannot decrypt
NetBird Cloud provides globally distributed relay servers
Self-hosted deployments must provision their own relay infrastructure

Direct vs. Relayed Percentages

No official percentage is published. From the NetBird forum: “there isn’t a direct percentage to give” as it depends entirely on the NAT environments involved. Based on Tailscale’s published data (which uses similar ICE/STUN/TURN techniques), typical deployments achieve >90% direct connections in favorable network conditions. Corporate environments with symmetric NAT will see higher relay usage.

Confidence: HIGH for architecture; MEDIUM for percentage estimates (extrapolated from Tailscale data and NAT traversal theory)

7. Networks vs. Network Routes

Networks is the newer feature; Network Routes is the legacy feature. Both are actively maintained.

Networks (newer, recommended)

Configuration container mapping on-prem/cloud infrastructure into logical resources
Resources can be IP ranges, domains, or subnets
Routing peers forward traffic between NetBird mesh and internal networks
Supports domain-based resources with automatic DNS resolution
Access control is enforced through policies (not bypassed by default)
Better integration with the newer Access Control system
Supports lazy DNS-based routing (routing rules set up only when DNS resolves)

Network Routes (legacy, still maintained)

IP-range-based routing (CIDR notation)
Routing peer forwards packets between NetBird mesh and private networks
Bypasses Access Control rules by default — traffic flows freely unless explicitly restricted
Supports overlapping route handling and route selection
Supports exit nodes (route all internet traffic through a peer)
More flexible for raw IP-based routing scenarios

Comparison

Feature	Networks	Network Routes
Access control	Enforced by default	Bypassed by default
Resource types	IPs, domains, subnets	CIDR ranges only
Domain-based routing	Yes	No
Exit nodes	No	Yes
Overlapping routes	Limited	Full support
Recommended for new setups	Yes	Only for unsupported scenarios

For GSISG Site-to-Site (Honolulu + Boulder)

Networks is the recommended approach for new deployments. Each office would have:

A routing peer (pfSense or dedicated Linux box) running the NetBird agent
A Network defined for each office’s LAN subnet
Resources representing the internal services at each location
Policies controlling which users/groups can access which resources

Confidence: HIGH — sourced from official Networks docs and Network Routes docs

8. Split DNS Support

Yes, NetBird supports split DNS (split-horizon DNS). This is a mature feature with multiple configuration options.

How It Works

Primary Nameserver: Handles all DNS queries not matched by specific domains. Configured with a public DNS provider (e.g., Cloudflare 1.1.1.1). Leave “Match Domains” empty.
Match Domain Nameservers: Handle queries for specific internal domains. Point to your internal DNS servers. Configure with match domains (e.g., company.internal).
Custom DNS Zones (v0.63+): Define private DNS records directly in NetBird, distributed to peers without needing an external DNS server. Takes precedence over nameservers.

Configuration Example (Split-Horizon)

Primary: Cloudflare (1.1.1.1, 1.0.0.1) for All Peers, no match domains
Match: Internal DNS (10.0.0.1, 10.0.0.2) for All Peers, match domain company.internal
Result: google.com goes to Cloudflare; app.company.internal goes to internal DNS

Features

Search domain expansion (server expands to server.company.internal)
Distribution group-based application (different DNS configs for different peer groups)
DNS failover across multiple nameservers
Custom Zones for infrastructure-less internal DNS
Automatic peer FQDN resolution (hostname.netbird.cloud)

Limitations

No query caching (except on routing peers during failures)
Match domain support requires macOS, Windows 10+, or Linux with systemd-resolved
Android requires Private DNS to be disabled
Known issues with DNS resolution conflicts when roaming between networks

Confidence: HIGH — sourced from official DNS docs and custom zones docs

9. Built-in Reverse Proxy (v0.65+)

What It Is

A built-in reverse proxy in the management server that exposes internal services to the public internet with optional authentication, automatic TLS, and WireGuard tunnel routing. Currently in beta.

How It Works

Configure a “Service” in the NetBird dashboard mapping a public domain to an internal target
NetBird provisions TLS certificates automatically (Let’s Encrypt)
Incoming HTTPS requests are terminated at the NetBird proxy cluster
Traffic is forwarded through an encrypted WireGuard tunnel to the target peer/resource
No inbound ports or public IP needed on the internal service

Authentication Options

SSO (Single Sign-On via OIDC)
Password (shared password)
PIN Code (numeric PIN)
None (public access)

Targets Can Be

Peers (machines running NetBird agent)
Hosts (IP addresses)
Domains (domain-identified resources)
Subnets (CIDR ranges)

Domain Options

Cloud: Auto-generated {subdomain}.{nonce}.{cluster}.proxy.netbird.io
Self-hosted: Cluster domains {subdomain}.{proxy-domain}
Custom domains via CNAME records

Availability

Self-hosted: Available now (beta)
Cloud: Available now (beta)

Limitations

Does not support pre-shared keys or Rosenpass
Self-hosted deployments must use Traefik (not Nginx/Caddy/HAProxy) due to TLS passthrough requirement
UDP traffic not supported through the reverse proxy
Some deployment issues reported (GitHub issue #5492 — embedded client auth failures)
No IP-based auth bypass yet (feature request #5556)

Could It Replace Existing Infrastructure?

For GSISG, this could potentially replace:

Cloudflare Tunnels for exposing internal services
Standalone reverse proxy configurations for authenticated service access

However, it is beta software and should not be relied upon for production without thorough testing.

Confidence: HIGH for features; MEDIUM for production readiness (beta status, known bugs)

10. Known Limitations vs. Tailscale and Traditional VPNs

vs. Tailscale

Area	NetBird Limitation	Tailscale Advantage
Auto-reconnection	Clients sometimes stay offline after network outages; manual intervention needed	Continuously retries and usually restores automatically
System service mode	Cannot run as Windows SYSTEM account (feature request open)	Runs as system service natively on Windows/Linux
Status reporting	UI may show “connected” while WireGuard handshake has timed out	UI reliably reflects connection state
Client maturity	Younger client with more rough edges	More mature, polished client experience
Ecosystem size	Smaller ecosystem, fewer integrations	Larger ecosystem, Mullvad VPN integration, Taildrop file sharing
HA for control plane	Enterprise license required for management HA	Built-in HA in SaaS offering
Mobile experience	Functional but less polished	More refined mobile apps
Post-manual-stop behavior	Auto-starts on reboot even after `netbird down`	Respects manual stop across reboots

NetBird Advantages over Tailscale

Area	NetBird Advantage
Self-hosting	Full control plane self-hosting (official, not reverse-engineered)
Data sovereignty	Complete control over all data and metadata
Reverse proxy	Built-in with custom domains, SSO, PIN auth
Access control UI	GUI-based policy management vs. JSON ACL files
License	BSD-3/AGPLv3 (fully open server) vs. proprietary control plane
Custom domains	Supported in reverse proxy vs. only `*.ts.net` in Tailscale Funnel
MSP multi-tenant	Native MSP portal for managing multiple client networks

vs. Traditional VPNs (Palo Alto GlobalProtect)

Area	NetBird Consideration
Central management	Less mature admin console than GlobalProtect Panorama
Compliance certifications	No FIPS 140-2 or Common Criteria; not SOC2 certified (GlobalProtect is)
Enterprise support	Community + ticketing support; no 24/7 TAC equivalent
Traffic inspection	No inline DLP/threat prevention (GlobalProtect has)
IPv6	Single flat IPv4 network only (100.64.0.0/10); no IPv6 overlay support
Static IP per user	Not supported (Defguard comparison confirms this)
Active-Active HA	Not available in open-source; requires enterprise license
Audit/compliance logging	Traffic event logging is cloud-only or enterprise
SCIM provisioning	Requires commercial license for self-hosted

General Known Limitations

Single flat IPv4 network — all peers share the 100.64.0.0/10 address space; no multiple network segments
No IPv6 overlay support — IPv4 only for the mesh network
Persistent keepalive fixed at 25 seconds — not configurable; wastes battery on mobile
Self-hosted HA requires enterprise license — management and signal HA not available in open-source
Some enterprise features cloud-only — traffic event logging, EDR integration, SCIM provisioning
pfSense integration immature — manual install, version lag, known bugs
DNS roaming issues — switching networks can break DNS resolution (community workaround: disable DNS management)

Confidence: HIGH — cross-referenced across multiple comparison articles, GitHub issues, and official documentation

Answers to Mission Questions

Q1: Current stable version, release cadence, and project maturity?

Latest stable: v0.66.4 (March 11, 2026). Release cadence: 2-3 releases per week, major features monthly. Maturity: 23,700+ GitHub stars, 131+ contributors, 306+ releases, 2,703+ commits. Backed by German Federal Ministry of Education and Research through StartUpSecure program (since Nov 2022). Dual-licensed BSD-3-Clause (client) + AGPLv3 (server). Written in Go (96.5%). Very active development and growing community.

Q2: Exact components of a self-hosted deployment?

Since v0.62+, a minimal self-hosted deployment requires: (1) netbird-server container (combines management, signal, relay, STUN), (2) dashboard container (web UI with embedded nginx), (3) Traefik container (reverse proxy, TLS), and optionally (4) PostgreSQL for production scale. An external IdP is no longer mandatory — local user management is built-in. Minimum resources: 1 vCPU, 2GB RAM, public IP, domain name.

Q3: Can it run on Azure B1ms for 100+ peers?

Technically yes for the management plane, but risky. The management server itself is lightweight, and the 100-peer limit bug was fixed. However, relay traffic is CPU-intensive (50% CPU reported with 25 peers on relay). Recommendation: Use Azure B2s (2 vCPU, 4GB RAM) for the main server, with separate relay server(s) on B1ms/B2s instances. Use PostgreSQL instead of SQLite for 100+ peers. If using an external IdP, double the resources.

Q4: pfSense package status?

NOT in the official pfSense package manager. A PR was submitted ~1 year ago (Aug 2025) and is still pending review as of March 2026. Installation is manual via pkg add from GitHub releases. The pfSense package is v0.1.0 with NetBird client v0.55.1 (11 versions behind current). Known issues include NAT traversal conflicts with pfSense’s automatic outbound NAT, segfaults on update, and WireGuard package conflicts. pfSense version compatibility is not explicitly documented. NetBird is available in the FreeBSD ports repository (since June 2025).

Q5: How does always-on mode work?

Setup key peers: No session expiration; tunnels stay up indefinitely; auto-reconnect after reboot. Best for servers and routing peers. SSO peers: Default 24-hour session expiration (configurable 1h to 180 days, or disabled). When expired, tunnel is torn down until re-authentication. Management server down: Existing P2P tunnels survive (WireGuard data plane is independent). Existing relayed connections survive if relay is up. New connections cannot be established. Known issue: Clients sometimes fail to automatically reconnect after prolonged outages.

Q6: NAT traversal capability?

Uses ICE protocol (same as WebRTC) with STUN for NAT discovery and custom relay (QUIC primary, WebSocket fallback) for unreachable peers. Handles easy NAT well (direct P2P). Symmetric NAT and CGNAT typically fall back to relay. Corporate firewalls with UDP blocking use WebSocket relay over TCP 443. No official direct-vs-relayed percentage is published; estimated >90% direct in favorable conditions based on similar technology benchmarks. All relay traffic remains end-to-end encrypted via WireGuard.

Q7: Networks vs. Network Routes?

Networks (newer) is the recommended feature for site-to-site routing. It supports domain-based resources, enforces access control by default, and integrates with the modern policy system. Network Routes (legacy) supports CIDR-based routing, exit nodes, and overlapping routes but bypasses ACL by default. For GSISG’s Honolulu-Boulder site-to-site, use Networks with routing peers at each office and policies controlling inter-site access.

Q8: Split DNS support?

Yes, fully supported. Configure primary nameservers for internet DNS and match domain nameservers for internal domains. Custom DNS Zones (v0.63+) allow defining records directly in NetBird without external DNS infrastructure. Search domain expansion is supported. Distribution groups allow different DNS configurations for different peer groups. Limitations: no query caching, requires systemd-resolved on Linux, Android requires Private DNS disabled.

Q9: Built-in reverse proxy (v0.65+)?

Introduced in v0.65.0 (February 2026). Exposes internal services to the public internet with automatic TLS, optional SSO/password/PIN authentication, and WireGuard tunnel routing. Available for both self-hosted (beta) and cloud. Self-hosted requires Traefik. Could replace Cloudflare Tunnels for authenticated service exposure. netbird expose CLI command (v0.66) enables one-command ephemeral service exposure. Still in beta with known deployment issues.

Q10: Known limitations vs. Tailscale and traditional VPNs?

Key limitations: (1) auto-reconnection reliability issues, (2) no Windows SYSTEM service support, (3) single flat IPv4 network only, (4) no IPv6 overlay, (5) fixed 25s keepalive, (6) self-hosted HA requires enterprise license, (7) some enterprise features cloud-only, (8) pfSense integration immature, (9) smaller ecosystem than Tailscale, (10) no FIPS/SOC2 compliance certifications (important vs. GlobalProtect). Key advantages: full self-hosting, data sovereignty, built-in reverse proxy with custom domains, GUI policy management, open-source server components.

Gaps & Uncertainties

Exact resource consumption at 100+ peers — No official benchmarks or sizing guides for specific peer counts. Community reports are anecdotal.
Direct vs. relayed connection percentages — NetBird does not publish statistics. Real-world ratios depend heavily on the specific network environments.
pfSense version compatibility — Not documented which pfSense CE/Plus versions are explicitly supported.
Enterprise license pricing — Custom pricing only; not publicly available. Required for self-hosted HA, SCIM, and some advanced features.
Management server HA architecture — Details of the enterprise HA implementation are not publicly documented.
Long-term reliability at scale — Limited public data on deployments with 100+ sustained peers. One user switched back to Nebula after reliability issues (GitHub #3121).
pfSense package update timeline — The PR to the official pfSense repo has been pending for ~1 year with no timeline for review.
Reverse proxy production readiness — Beta status with known authentication bugs (#5492). Production viability for GSISG needs validation.
Mobile client maturity — Limited data on iOS/Android stability for always-on enterprise use.
Compliance certifications — No information found about SOC2, FedRAMP, HIPAA, or other compliance frameworks. This may be a concern for a company replacing enterprise-grade GlobalProtect.

Sources & Tool Usage Log

Tools Used (12 distinct tool invocations)

Tool	Queries	Purpose
mcp__claude_ai_Tavily__tavily_search	7	Primary web search for current info across all topics
mcp__claude_ai_Tavily__tavily_research	1	Deep research on always-on mode and tunnel persistence
WebSearch	2	Cross-reference GitHub stats and Azure scaling info
mcp__exa_websearch__web_search_exa	2	Deep search for Tailscale comparisons and pfSense details
WebFetch	8	Direct documentation page fetching
mcp__context7__resolve-library-id	1	Library ID resolution for NetBird docs
mcp__context7__query-docs	1	Structured documentation query

Key Sources

Official Documentation:

GitHub:

netbirdio/netbird — Main repository
Releases
Issue #1824 — 100 peer limit (fixed)
Issue #1661 — Always-on VPN under system account
Issue #3121 — Peer link drops
Issue #5492 — Reverse proxy auth failure
Issue #5556 — Reverse proxy IP bypass
pfsense-netbird Issue #5 — Official pfSense repo status

Comparison Articles:

Community:

Product Pages: