NetBird - publishing services without a public IP or port forwarding

If you enjoyed this article, you can support the author by becoming a sponsor on Boosty.

If you think NetBird is just another VPN app that can join your devices into a mesh network, then… partially, yes, you’re right. But in practice, it’s a much more flexible tool that covers several tasks at once: private networking, resource access, and now also publishing services externally.

Preface

#

In a homelab, everything usually starts the same way:

First you set up services locally - everything works perfectly. Then the desire arises to access them from outside. And that’s where it begins: port forwarding, NAT, firewall, dynamic DNS, domains, HTTPS, and constant paranoia about “did I close everything off?” Next comes more: a VPN appears (I’m not talking about bypassing censorship, comrade major, but about security). But a VPN isn’t always ideal either: you need to set up a server, configure clients, figure out routing, and fix access from mobile networks. And at some point you realize you’re not managing services anymore, you’re managing a network. This is where Netbird comes onto the stage.

What is NetBird

#

NetBird is a system that creates a private mesh network between all your devices. In simpler terms:

All your servers, laptops, phones, and containers become part of a single virtual network.

And all of this:

• without port forwarding
• without manually configuring WireGuard
• without complex network logic

How it differs from Pangolin

#

In short:

• Pangolin - publishes services externally (with varying degrees of access, of course)
• NetBird - connects devices to each other

But now the line has blurred. NetBird now knows how to: create a private network (its core function); grant access to resources; publish services externally through a built-in proxy. That last one is a new feature that completely changes how you perceive this application. In other words, it’s turning into a universal access tool.

The core idea: a mesh network

#

Instead of a classic VPN (client → server), NetBird uses a mesh network:

• devices connect directly to each other
• if that doesn’t work, a relay is used
• routes are built automatically

Under the hood it uses WireGuard, but you barely interact with it directly.

Why it’s convenient

#

1. No open ports

#

Your server initiates the connection outward itself. This means: no need to touch the router; no need to open ports; fewer risks associated with potential service compromise.

2. Everything is encrypted

#

Traffic goes through WireGuard. In practice, this means modern cryptography, high performance, and minimal latency.

3. Zero Trust approach

#

NetBird doesn’t trust the network - only the user and the device. You control: who exactly connects; which resources the user connects to and under which rules (or rather, roles, since RBAC is implemented, though still in an early stage).

4. Simplicity

#

You don’t have to write configs by hand, generate keys, or debug iptables. You just install the agent, log in, and get a network.

This is of course not all the app’s capabilities, but I hope readers will forgive me if I don’t just translate the NetBird documentation site.

NetBird’s new feature: publishing services

#

Previously, NetBird was purely about setting up a private network and getting access to it. Now it can work as a reverse proxy. This means:

• you can publish services externally;
• without directly opening ports on your home server;
• with access control.

Effectively: an internal service → becomes accessible via a domain; traffic passes through NetBird; access is finely controlled by policies. This makes it similar to:

• Pangolin
• Cloudflare Tunnel

But with an important difference from Cloudflare Tunnel:

everything stays under your control

How it works

#

General scheme

#

1. You have a management server (in our case, a self-hosted server on a VPS)
2. Devices connect to it
3. A mesh network is built between them
4. A relay is spun up if needed, or a direct connection is used

Components

#

Management Server

#

The central point of control:

• users
• devices
• access policies

Agents

#

Clients installed on:

• servers
• PCs
• laptops
• containers

Relay (if needed)

#

Used when a direct connection is not possible (NAT, CGNAT, etc.)

Built-in proxy

#

Responsible for:

• publishing services
• routing traffic
• external access

Key use cases

#

1. Accessing your homelab from anywhere

#

You just connect - and:

• open Proxmox
• connect to the NAS
• connect via SSH

As if you were at home.

2. Connecting multiple locations

#

For example, home, VPS, office. They all become one network.

3. Publishing services

#

Now you can expose access to a web application via a domain name, grant access to specific users, without exposing your IP.

4. Secure access for a team

#

You can grant access to developers, friends, and colleagues. But only if you actually have any. You can also do the reverse and restrict everything to only the needed services and only the needed ports.

Deployment requirements

#

Minimal set

#

1. A server (VPS or local)
2. A domain
3. Internet access for clients

In this respect, Pangolin and NetBird have similar requirements.

Deployment options

#

Cloud (the simplest)

#

Use the hosted version of NetBird.

Pros:

• fast
• no preliminary setup needed.

Cons:

• less control
• access from Russia is difficult as of the publication date of this article

Self-hosted (recommended for homelab) in 2026

#

You spin up:

• a management server using the installation script that you get from the developer’s website; you answer a couple of questions, and installation runs automatically.

And you fully control the infrastructure.

Server preparation

#

Basic steps:

• create a user (not root)
• configure SSH
• enable the firewall
• open the required ports

(all as usual for any VPS)

Below is an approximate list of actions that can be carried out on the VPS before deploying NetBird.

VPS preparation process

#

Basic VPS security setup

#

After getting a VPS, the first step is basic security hardening to minimize the risk of unauthorized access. First and foremost, you should stop working as the root user and create a separate user with sudo privileges.

Working as root is unsafe, so first let’s create a new user and add them to the sudo group:

adduser youruser  
usermod -aG sudo youruser

Let’s check that everything works:

su - youruser  
sudo whoami

SSH configuration (changing the port and disabling root)

#

Open the SSH configuration file:

sudo nano /etc/ssh/sshd_config

Find and change the following parameters:

Port 2222  (using this exact port is a big mistake)
PermitRootLogin no

This will:

• change the default SSH port (22 → any free non-standard port)
• completely disable root login

Disabling password login (highly recommended)

#

For extra protection, it’s recommended to allow SSH-key login only:

PasswordAuthentication no

Firewall configuration (UFW)

#

Let’s install and enable UFW:

sudo apt update  
sudo apt install -y ufw

Let’s allow only the ports needed for Pangolin to work:

sudo ufw allow yourSSHportIfYouHaventEnabledKeyOnlyAccess/tcp  
sudo ufw allow 80/tcp  
sudo ufw allow 443/tcp  
sudo ufw allow 51820/udp

Let’s enable the firewall:

sudo ufw enable  
sudo ufw status

Applying the SSH changes

#

After making the changes, restart the SSH service:

sudo systemctl restart ssh

Mandatory connection check

#

Before closing your current SSH session, open a new connection and make sure everything works:

ssh youruser@your_ip -p yourSSHportIfYouHaventEnabledKeyOnlyAccess

Only close the old session after a successful connection.

DNS setup

#

Basic DNS records

You’ll need to create A records (or AAAA for IPv6) pointing to your VPS’s IP address.

1. Creating a wildcard record

#

2. Waiting for DNS propagation

#

DNS changes can propagate anywhere from 5 minutes to 48 hours worldwide.

Reverse Proxy

#

The Reverse Proxy in NetBird lets you publish internal services running on peers or behind network resources to the public internet. NetBird performs TLS termination, applies authentication and access restrictions where needed, and proxies incoming traffic through the NetBird mesh network to the target service - without needing to open ports or configure a firewall on internal machines.

Availability: the Reverse Proxy feature is currently in beta.

Self-hosted requirement: in self-hosted deployments, Traefik must be used as the external reverse proxy. It is the only supported proxy that provides the TLS passthrough required for the Reverse Proxy feature to work correctly.

How it works

#

When creating a reverse proxy service, NetBird automatically allocates a public domain with a TLS certificate. Incoming traffic to that domain reaches NetBird’s proxy cluster, and is then forwarded through NetBird’s encrypted tunnel to the target peer or network resource where your application is running.

The target service only needs to be reachable within the NetBird network - it doesn’t need a public IP address or open ports.

NetBird supports two types of services:

• HTTP services (Layer 7) TLS is terminated at the proxy, and HTTP requests are then proxied to the backend. Supported:
  • path-based routing
  • Host header forwarding
  • redirect rewriting
  • browser-based authentication (SSO, password, PIN)
• L4 services (TCP, UDP, TLS) Operate at the transport layer (Layer 4). The proxy forwards connections or datagrams without inspecting content. In TLS mode, SNI-based routing is used without TLS termination.

You can enable authentication and restrict access by IP or country.

Concepts

#

Services

#

A service is the primary configuration unit of the reverse proxy.

A service includes:

• Service mode - HTTP (L7) or TCP/UDP/TLS (L4)
• Domain - the public URL
• Targets - backend targets
• Authentication - SSO / password / PIN / headers
• Access restrictions - IP, country, CrowdSec
• Settings
• Enable/disable

Service modes

#

L4 specifics:

• use a dedicated port
• no HTTP authentication
• only access restrictions can be used

Targets

#

A target defines where traffic is sent within the NetBird network.

Types:

• Peer - a node with the NetBird agent
• Host - an IP address
• Domain - a domain name
• Subnet - a subnet (CIDR)

For HTTP:

#

• Path (optional)
• Protocol: HTTP / HTTPS
• Port (default 80/443)

For L4:

#

• just type + port

Domains

#

Cloud

#

Format:

{subdomain}.{nonce}.{cluster}.proxy.netbird.io

Example:

myapp.abc123.eu.proxy.netbird.io

Self-hosted

#

{subdomain}.{proxy-domain}

Example:

myapp.proxy.mycompany.com

DNS (self-hosted)

#

You need:

• an A record → NetBird server
• CNAME:
  • proxy
  • *.proxy

Custom domains

#

You can use your own domains via CNAME.

All domains get automatic TLS certificates.

Authentication

#

If no protection is set, the service is public.

Service statuses

#

Prerequisites

#

Before creating a service:

• have a peer or network
• have a domain
• (self-hosted) have a proxy instance
• have the necessary access rights

Quick start

#

Step 1

#

Dashboard → Reverse Proxy → Services → Add Service

Step 2

#

Settings:

• mode (HTTP / L4)
• subdomain
• base domain
• port (for L4)
• target

Step 3 (HTTP)

#

Authentication:

• SSO
• password
• PIN
• header

Step 3b

#

Access control:

• IP
• country
• CrowdSec

Step 4

#

Additional settings:

HTTP:

#

• Pass Host Header
• Rewrite Redirects

L4:

#

• PROXY Protocol
• Session timeout (UDP)

⚠️ The backend must trust the proxy (trusted proxies)

Step 5

#

Create the service → wait for active status

Managing services

#

• editing
• enabling/disabling
• deletion
• managing targets

L4 ports

#

• one service = one port
• automatic or manual port selection possible
• ports cannot overlap

Specifics:

• HTTP and TLS can share a port via SNI
• TCP fallback when SNI is absent

⚠️ You cannot use the same hostname for both HTTP and TLS

Path-based routing

#

Example:

You can see how this app is installed in more detail in my video, and this is one of those cases where it’s better to watch once than read about it a hundred times.