Listen to this Post

Introduction:
The zero-trust networking paradigm has shifted from corporate buzzword to operational necessity, yet organizations remain torn between SaaS-managed convenience and absolute data sovereignty. NetBird emerges as a compelling third path—a fully self-hosted, BSD-3 licensed WireGuard mesh VPN that delivers a complete, independent stack including control plane, web interface, signaling, and relay servers, all without relying on any third-party service. Unlike Headscale, which merely replaces Tailscale’s control plane while remaining tethered to its client ecosystem, NetBird provides 100% independent agents and infrastructure, making it the most sovereign option for DevSecOps practitioners who demand complete control over their networking fabric.
Learning Objectives:
- Deploy a production-ready NetBird server with automated Let’s Encrypt TLS termination using Docker Compose and Traefik
- Enroll Linux machines through signed package repositories (GPG-verified) rather than insecure piped scripts
- Secure SSH access via the WireGuard mesh while maintaining out-of-band recovery paths
- Customize the IP addressing plan beyond the default CGNAT range—a capability unique to NetBird
- Implement API-driven infrastructure-as-code for network range and DNS domain configuration
You Should Know:
1. NetBird Architecture: Understanding the Full Stack
NetBird is not merely a WireGuard wrapper; it is a complete mesh networking solution comprising five interdependent components that work in concert. The Management service functions as the control plane, maintaining peer inventory, access control lists (ACLs), and configuration distribution. The Signal service facilitates NAT traversal by exchanging connection information between peers, enabling direct peer-to-peer communication through hole punching. The Relay (with integrated Coturn) provides encrypted fallback relaying when direct connections fail, while the embedded Identity Provider (IdP) handles user authentication and account management. Finally, the Dashboard delivers a graphical web interface for administrative tasks. All these components can be deployed in a “combined setup” using a single unified container (netbird-server), orchestrated alongside Traefik for automatic TLS management. The mesh operates by assigning each peer a stable private IP address, allowing encrypted WireGuard communication between machines without requiring any inbound open ports on individual hosts.
Infrastructure Requirements:
Before deployment, ensure your environment meets these prerequisites:
- A public VM with at least 1 vCPU and 2 GB RAM (sufficient according to official documentation)
- A domain name resolving to the VM’s public IP (e.g.,
netbird.example.fr) - Open ports: TCP 80 and 443 (dashboard, API, gRPC, signal, relay, and Let’s Encrypt), plus UDP 3478 (Coturn STUN/TURN—this cannot traverse an HTTP reverse proxy)
- Docker with Compose v2, plus `jq` and `curl` utilities
Deployment Step-by-Step:
Step 1: DNS Configuration
Create an A record mapping your chosen domain (e.g., netbird.example.fr) to the VM’s public IP address. Verify propagation using:
dig netbird.example.fr
Step 2: Retrieve and Inspect the Official Script
Never pipe curl directly to bash without inspection. Download and review the getting-started script:
curl -LO https://raw.githubusercontent.com/netbirdio/netbird/main/scripts/getting-started.sh less getting-started.sh Inspect contents thoroughly
Step 3: Execute Deployment
Run the script with your domain:
bash getting-started.sh netbird.example.fr
The script will prompt for two choices: select the reverse proxy (choose `0` for Traefik, which handles Let’s Encrypt TLS automatically) and provide an email address for certificate notifications.
Step 4: Verify Running Containers
Three containers should be operational:
docker compose ps
Confirm the dashboard responds over HTTPS with a valid certificate:
curl -I https://netbird.example.fr
Step 5: Initial Admin Account Creation
Open `https://netbird.example.fr` in a browser. The embedded IdP will guide you through creating the administrator account on first access.
2. Proper Machine Enrollment: Package Repositories Over Piped Scripts
A common anti-pattern in the NetBird ecosystem is installing the client via `curl | sh` scripts or downloading standalone binaries. This approach fails to install the necessary systemd service, causing `netbird up` to error with “config error: –config is required”. The correct method uses the signed package repository with GPG verification, which properly installs both the binary and the systemd service unit.
For Debian/Ubuntu systems:
Add the GPG key curl -sSL https://pkgs.netbird.io/debian/public.key | sudo gpg --dearmor --output /usr/share/keyrings/netbird-archive-keyring.gpg Add the repository echo 'deb [signed-by=/usr/share/keyrings/netbird-archive-keyring.gpg] https://pkgs.netbird.io/debian stable main' | sudo tee /etc/apt/sources.list.d/netbird.list Update and install sudo apt-get update && sudo apt-get install netbird
For RHEL/Fedora derivatives:
sudo curl -sSL https://pkgs.netbird.io/yum/netbird.repo -o /etc/yum.repos.d/netbird.repo sudo yum install netbird
Connecting the Machine to Your Management Plane:
Create a setup key in the dashboard: navigate to Settings → Setup Keys → Create Setup Key, select the Reusable type. Then enroll the machine:
sudo netbird up --management-url https://netbird.example.fr --setup-key YOUR_SETUP_KEY
Verifying Connection Status:
netbird status
This output displays the machine’s NetBird IP (within the `100.x` range by default), `Management: Connected` status, and the list of peers with their connection states. A `Peers count: 1/1 Connected` line confirms an established tunnel.
- Securing SSH Through the Mesh Without Losing Access
The killer use case for NetBird is accessing servers via SSH without exposing port 22 to the public internet. Once a server is enrolled as a peer, its SSH daemon listens on the WireGuard interface (wt0) as well. From any other machine on the mesh:
ssh [email protected] Using the target's NetBird IP
Traffic traverses the encrypted tunnel, and the server sees the connection originating from the client’s NetBird IP. You can then close port 22 on the public interface—but only if you maintain an out-of-band recovery path.
Critical Warning: The Out-of-Band Access Mandate
Never make the mesh your sole entry point, especially in cloud environments. If NetBird fails (service crash, misconfigured ACLs that lock you out, revoked keys, or a failed upgrade), you will be completely locked out. Maintain at least one independent recovery channel:
– SSH with IP allowlisting: Keep port 22 open but restrict it exclusively to your administration IP address or a bastion host—never to the entire internet.
– Cloud provider console access: The ultimate safety net if both SSH and NetBird fail.
The anti-pattern of “zero-trust absolutism”—closing port 22 entirely and relying solely on NetBird—transforms a mesh incident into a total outage. The pragmatic compromise: port 22 closed to the world but open to your IP as a backup, with NetBird handling routine access.
4. Customizing the Addressing Plan: NetBird’s Killer Feature
By default, NetBird assigns each network a `/16` subnet from 100.64.0.0/10, the CGNAT block defined in RFC 6598, yielding addresses like 100.98.x.x. However, unlike Tailscale and Headscale—which hardcode the CGNAT range into their clients—NetBird allows full customization of the IP addressing plan.
To change the network range via the dashboard:
Navigate to Settings → Networks → Network Range and enter your preferred CIDR (e.g., 10.9.1.0/24). Peer IPs are automatically reallocated upon change. You can also define a custom internal DNS domain in the same settings panel.
| Solution | Addressing Plan | Customizable? |
|-|-||
| Tailscale | 100.64.0.0/10 (CGNAT) | No, client-hardcoded |
| Headscale | Subset of CGNAT | No, reuses Tailscale client |
| NetBird | CGNAT by default, any CIDR | Yes (Settings → Networks) |
Infrastructure-as-Code Integration:
This setting is also available via the NetBird API, enabling programmatic management:
curl -X PUT "https://netbird.example.fr/api/accounts/${ACCOUNT_ID}" \
-H "Authorization: Token ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"network_range": "10.9.1.0/24"}'
. Refer to the official API reference for full details.
If your infrastructure already uses `100.64.x` addresses, or if you need to align the mesh with an existing addressing scheme, NetBird is the only solution among the three that permits this flexibility—a decisive advantage for sovereignty-conscious deployments.
5. Advanced Operations: API Management and Automation
Beyond the dashboard, NetBird exposes a comprehensive REST API for automating account management, peer enrollment, and network configuration. This is essential for integrating NetBird into Infrastructure-as-Code (IaC) pipelines using tools like Terraform, Ansible, or custom scripts.
Retrieving Account Information:
curl -X GET "https://netbird.example.fr/api/accounts" \
-H "Authorization: Token ${API_TOKEN}"
Creating Setup Keys Programmatically:
curl -X POST "https://netbird.example.fr/api/setup-keys" \
-H "Authorization: Token ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"name": "production-key", "type": "reusable", "expires_in": 86400}'
Listing Connected Peers:
curl -X GET "https://netbird.example.fr/api/peers" \
-H "Authorization: Token ${API_TOKEN}" | jq '.'
Managing ACLs via API:
NetBird supports policy-based access control. Define rules to restrict which peers can communicate:
curl -X PUT "https://netbird.example.fr/api/accounts/${ACCOUNT_ID}/policies" \
-H "Authorization: Token ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"rules": [
{"source": ["group:engineering"], "destination": ["group:databases"], "ports": ["22"]}
]
}'
For production environments, store API tokens as secrets in your CI/CD system (GitHub Actions secrets, GitLab CI variables, or HashiCorp Vault) and never hardcode them in scripts.
6. Ports, Firewalls, and NAT Traversal Deep Dive
NetBird’s connectivity relies on precise port configuration. The UDP 3478 port for Coturn STUN/TURN is particularly critical—it cannot be proxied through an HTTP reverse proxy like Traefik or Nginx. Without this port open, only peers within the same local network can communicate; cross-1etwork and cloud-to-cloud connections will fail.
Port Requirements Summary:
| Port | Protocol | Purpose |
||-||
| 80 | TCP | Let’s Encrypt HTTP-01 challenge + HTTP-to-HTTPS redirection |
| 443 | TCP | Dashboard UI, API/gRPC endpoints, Signal service, Relay service |
| 3478 | UDP | Coturn STUN/TURN for NAT traversal and hole punching |
Firewall Configuration Examples:
Using `ufw` on Ubuntu/Debian:
sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow 3478/udp sudo ufw enable
Using `firewalld` on RHEL/CentOS:
sudo firewall-cmd --permanent --add-port=80/tcp sudo firewall-cmd --permanent --add-port=443/tcp sudo firewall-cmd --permanent --add-port=3478/udp sudo firewall-cmd --reload
AWS Security Group (via CLI):
aws ec2 authorize-security-group-ingress --group-id sg-xxxxx --protocol tcp --port 80 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-id sg-xxxxx --protocol tcp --port 443 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-id sg-xxxxx --protocol udp --port 3478 --cidr 0.0.0.0/0
Important Note: Older NetBird documentation may reference the UDP port range 49152-65535. This is no longer required in current versions. Do not open this wide range unless you are running a legacy deployment.
- Comparing NetBird, Tailscale, and Headscale: Making the Right Choice
The choice between these three WireGuard-based mesh solutions hinges on your sovereignty requirements, operational complexity tolerance, and feature needs.
| Feature | Tailscale | Headscale | NetBird |
||–|–||
| Control Plane | SaaS (proprietary) | Self-hosted (BSD-3) | Self-hosted (BSD-3) |
| Clients | Tailscale proprietary | Tailscale clients | NetBird own agents (open source) |
| Web Interface | Yes (SaaS) | No (CLI only) | Yes, integrated |
| Relay Infrastructure | DERP (Tailscale-operated) | DERP (Tailscale-operated) | Self-hosted relay + Coturn |
| Addressing Customization | Fixed CGNAT | Fixed CGNAT | Fully customizable CIDR |
| SSO Integration | Yes (SaaS IdPs) | Via OIDC proxy | Embedded IdP + external OIDC |
| License | Proprietary | BSD-3 | BSD-3 |
Key Differentiators:
- Tailscale prioritizes simplicity and a managed experience—ideal for teams that want zero operational overhead and are comfortable with a SaaS control plane.
- Headscale offers a self-hosted control plane while retaining Tailscale’s client ecosystem and DERP relay dependency—a middle ground that reduces SaaS reliance but remains tethered to Tailscale’s infrastructure for certain functions.
- NetBird delivers complete sovereignty: self-hosted agents, control plane, relays, and web UI. No external dependencies, full addressing flexibility, and a permissive BSD-3 license that permits commercial use.
For organizations subject to data residency requirements, compliance frameworks (GDPR, HIPAA), or simply a preference for keeping all networking infrastructure in-house, NetBird presents the most compelling self-hosted option.
What Undercode Say:
- Sovereignty is non-1egotiable: NetBird’s complete independence from third-party control planes and relay infrastructure makes it the only true self-hosted alternative in the WireGuard mesh space. Organizations handling sensitive data can deploy with confidence, knowing no traffic metadata leaks to external SaaS providers.
-
The out-of-band access principle is absolute: The guide’s emphasis on maintaining a fallback SSH channel is not optional—it is a survival imperative. Too many zero-trust implementations become single points of failure. NetBird’s mesh should augment, not replace, traditional recovery paths.
-
Addressing flexibility is a game-changer: The ability to customize the CIDR range addresses a long-standing pain point for enterprises with existing private IP schemes. This single feature may justify choosing NetBird over Tailscale or Headscale in environments with stringent network segmentation requirements.
Analysis:
Stephane Robert’s guide demonstrates a mature, production-oriented approach to NetBird deployment. The insistence on signed package repositories over piped scripts reflects a security-first mindset that should be standard across all infrastructure provisioning. The practical validation of SSH access via the mesh, combined with the explicit warning about recovery paths, shows real-world operational experience rather than theoretical idealization. The comparison table and addressing plan discussion provide actionable decision-making criteria. For DevSecOps teams, the API-driven configuration examples open the door to full Infrastructure-as-Code integration, positioning NetBird not as a toy for homelabs but as an enterprise-grade solution. The guide’s coverage of port requirements and NAT traversal nuances—particularly the UDP 3478 caveat—saves administrators from hours of debugging failed peer connections.
Prediction:
- +1 NetBird’s adoption will accelerate throughout 2026–2027 as enterprises accelerate cloud repatriation and seek to reduce dependency on US-based SaaS providers for critical networking infrastructure, particularly in EU-regulated industries.
-
+1 The addressing plan customization feature will become a standard expectation in the mesh VPN market, forcing competitors like Tailscale to either relax their hardcoded CGNAT limitations or risk losing enterprise customers with complex existing IP schemes.
-
-1 The operational complexity of self-hosting the full NetBird stack (Management, Signal, Relay, Coturn, Dashboard) will deter smaller teams, creating a bifurcated market where NetBird dominates among security-conscious enterprises while Tailscale retains SMB and startup mindshare.
-
+1 NetBird’s BSD-3 license positions it favorably for integration into commercial products and managed service offerings, potentially spawning a new ecosystem of third-party NetBird-based solutions and consultancies.
-
-1 Without a mature commercial support ecosystem comparable to Tailscale’s, organizations may hesitate to bet their production networking on NetBird, slowing enterprise adoption until third-party SLAs and professional services emerge.
▶️ Related Video (80% Match):
https://www.youtube.com/watch?v=2_DF17IJCnE
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Stephanerobert1 Devops – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅


