This Underrated Tool Replaced 3 Homelab Services (and it's open source!)

Overview

Omer from DevOps Toolbox puts NetBird through a comprehensive hands-on test — an open-source, WireGuard-based secure access platform that aims to replace your reverse proxy, DNS server, and mesh VPN in a single tool. He deploys it on a K3s homelab cluster, walks through peer-to-peer setup, network routes, posture checks (a feature he's never seen in alternatives), and demonstrates why "security by obscurity" doesn't work — showing a live exploit against his own Caddy setup. The video culminates with a surprising discovery: NetBird includes a full DNS management system, potentially replacing AdGuard as well.

1 The Problem with Existing Solutions

▶ 0:00

Omer opens by surveying the current landscape of networking tools for self-hosters. He's previously covered FRP (a reverse proxy alternative to Cloudflare) and Headscale (the Tailscale open-source alternative), but all of these share a common pain point: you're working too hard.

• Long ad-hoc commands — CLI-heavy setup without intuitive management
• Lack of an official UI — most alternatives are terminal-only or require third-party dashboards
• Config file overload — too much YAML/TOML tweaking before anything works

The promise of NetBird is doing more than just a secure mesh network: it claims to handle reverse proxying and DNS management too, rewriting entries on the fly. It's production-ready, built on WireGuard, and works across every platform.

2 What Is NetBird?

▶ 1:24

NetBird describes itself as a "secure access platform" rather than just a tunnel facilitator. Key characteristics:

• Open source — fully available on GitHub, written in Go
• Visual interface from the start — a built-in dashboard for both setup and management
• Company-backed — similar to Tailscale, there's a company behind it offering a cloud option
• Community Edition — the self-hosted, on-premises option Omer chooses for this demo

3 Kubernetes Deployment

▶ 1:48

Omer deploys NetBird on his homelab K3s cluster. The deployment consists of two key components:

• NetBird Server pod — a single container running the main process with a mounted config file, exposing HTTP ports for communication. Includes /metrics and /health endpoints for monitoring
• Dashboard pod — runs the NetBird dashboard image, opening HTTP for browser-based management

There are also Kubernetes services to handle internal DNS request flow. Omer verifies the deployments via his log service (Dozzle) — both the server and dashboard pods come up healthy.

4 Peer-to-Peer vs Remote Network Access

▶ 3:00

During initial setup, NetBird presents two fundamental networking modes:

Peer-to-Peer Mesh Network (Recommended)

• Creates direct connections between devices via WireGuard
• No single server bottleneck — traffic flows on the shortest path
• Leverages the full power of WireGuard's peer architecture
• Both safe and efficient — no overloading a central relay

Remote Network Access (Traditional VPN)

• More like a traditional VPN fortress model — authenticate at one machine, gain access to the entire internal network
• Omer uses the analogy: "You have the main gate, and once you've passed that, you're in the kingdom"
• Useful for specific enterprise use cases but not the recommended architecture

Omer chooses peer-to-peer for his setup, which is the true strength of WireGuard-based networking.

5 Device Enrollment & Mobile Clients

▶ 3:48

Adding the first device (homelab box) is straightforward: NetBird generates a URL with a one-time user code, which you open in a browser to authenticate. The device login completes and the server confirms the new peer.

Adding a second device reveals a notable strength: native Android and iOS clients are available directly from NetBird — no hunting for third-party apps.

Since Omer is self-hosting (not using the cloud option), he configures his own server address in the mobile app. Authentication follows the same one-time code flow. A quick ping test from the iPhone to the homelab host confirms a solid round-trip time and a live connection.

6 Control Center & Automatic TLS

▶ 4:44

The NetBird Control Center provides a visual overview of the entire mesh network. Immediately visible is the topology of connected peers and their status.

A noteworthy popup appears: NetBird now offers automatic TLS and authentication — currently in beta. This is similar to what Caddy does with automatic certificate generation and management, but integrated directly into the networking layer.

• Potential to merge Caddy's role — handling both connections and HTTPS certificates in one tool
• One caveat: self-hosters must run Traefik (not Caddy) with the beta TLS feature
• Still in beta — Omer decides to wait for stability before migrating

7 Network Routes & Service Access

▶ 7:00

Being on the peer-to-peer mesh means your phone can see the homelab machine, but not the services running inside K3s. Network routes solve this by exposing internal networks without installing NetBird on every resource.

• CIDR block configuration — define which network ranges should be accessible through the route
• Policy-based access — choose which devices or groups the route applies to
• Routing peers — designate specific peers or groups to serve as gateways

Omer creates a route with a broad CIDR block for his homelab network, applies it to all devices, and enables the routing peers. His mobile client on cellular data (verifying it's going through a global connection, not local WiFi) can now access the Dozzle log service that's only resolvable from within the homelab.

A quick disconnect test proves the route works: disconnect NetBird, try Safari — nothing loads. Reconnect — instant access.

8 Posture Checks — A Unique Firewall Feature

▶ 8:06

NetBird includes posture checks — a feature Omer says he hasn't seen in any alternative. These go far beyond simple IP-based access rules:

• Client version — block connections from outdated or vulnerable client versions
• Country / Region — geo-restrict access at the network level
• Network range — limit which source networks can connect
• Operating system — enforce OS requirements (e.g., no Windows XP)
• Running process — verify a specific process is running on the client before granting access

NetBird essentially becomes a mini firewall with extremely granular policy controls — mesh networking + reverse proxy + firewall in one tool.

9 Security Demo — Why "Security by Obscurity" Fails

▶ 9:21

Omer demonstrates a live security test against his own setup to show why relying on DNS-level hiding is insufficient:

1. Without NetBird: Curling the log service from a remote network fails — it resolves to a private IP with no access. This looks secure, but...
2. The "hack": Simply make curl resolve the hostname to the public IP instead. The TLS handshake completes, and Dozzle is fully served. "It's not even an effort."
3. Fix with Caddy: Configure Caddy to bind the service to local IP only. Now the public IP resolution gets a 403 Forbidden

But there's a better architectural solution than patching Caddy rules per service...

10 Architecture Rethink — NetBird as the Gateway

▶ 10:24

Omer draws out the architecture problem. Current setup: all traffic goes to Caddy, which distributes to services including NetBird — but this is backwards. NetBird is a remote access gateway with a firewall — it should be in front:

• Current flow: Internet → Caddy → Services (including NetBird) — NetBird sits alongside services instead of guarding them
• Proposed flow: Internet → NetBird → Caddy → Services — NetBird becomes the entry point, only allowing traffic from its mesh, then Caddy handles routing
• Ultimate goal: If NetBird's reverse proxy feature matures, Caddy could be merged into NetBird entirely — one tool handling access, routing, TLS, and firewall

11 Built-in DNS Management — The Surprise Feature

▶ 11:17

The biggest surprise: NetBird includes a full DNS management system. This was unexpected and potentially replaces yet another service — AdGuard — that Omer currently runs on his homelab.

• Create custom name servers — add to Cloudflare or use independently
• Per-peer DNS configuration — choose which peers use which name servers
• Domain-specific resolution — set specific domains to resolve through your private DNS
• Local resolver — all configured peers get a local DNS resolver serving entries and answering queries internally
• Custom names — resolve arbitrary custom domain names within the mesh

🎯 Key Takeaways

🔗 Resources & Links

• NetBird on GitHub — open-source WireGuard-based secure access platform

⏱ Timestamp Index