From OpenVPN to NetBird: How I Simplified My Entire Private Network in Three Hours

How I migrated my private infrastructure from OpenVPN, Nginx, and HAProxy to NetBird in just three hours, getting mesh VPN, routing, DNS, Reverse Proxy, TLS, and access management in one place.

From OpenVPN to NetBird: How I Simplified My Entire Private Network in Three Hours

Until yesterday, almost my entire private network was built around OpenVPN.

OpenVPN itself worked perfectly fine for me. It is mature, predictable, and gives you full control over your network. The real problem was not the VPN itself, but all the infrastructure that had gradually grown around it.

Accessing a service usually involved something along these lines:

OpenVPN -> routing -> HAProxy / Nginx -> the required VM or LXC -> application/service.

Some services required additional proxying, some needed custom routes, and others needed separate TLS certificates. Adding a new device meant generating an OpenVPN configuration and sending it over SMTP. Adding a new service meant figuring out which proxy layer it should go through, configuring the upstream, domain, certificate, and access rules.

The configuration files kept growing, and so did the number of places where I could forget to configure something.

Monitoring was equally sophisticated: SSH into the server and run something like:

watch -n 1 ...

Does it work? Yes. Is it pretty? Not really.

And Then I Tried NetBird

I had known about NetBird for a while, but never really saw a reason to try it.

Mesh VPNs are nothing new. There are Twingate, Netmaker, and plenty of other solutions, so my initial reaction was roughly:

Okay, another mesh VPN. Why would I replace infrastructure that already works?

I am also generally skeptical about tools that promise to hide complicated networking behind a nice web interface.

While everything works, that is obviously convenient. But once something breaks, you may suddenly discover that the good old several-hundred-line configuration file was not such a bad thing after all.

Still, I decided to give NetBird a chance and deployed it.

It did not take long to realize that this was not simply an OpenVPN replacement.

More Than Just a VPN

The biggest difference for me was that NetBird solves several problems for which I previously had separate infrastructure components.

First, adding new servers.

Instead of manually managing OpenVPN configuration files, I get a straightforward peer enrollment mechanism. Connect a machine, and it immediately appears in the network and becomes visible in the dashboard.

Second, access management.

There is no need to write obscure configuration rules just to restrict access for a particular user.

You can simply create a user with guest access and grant them access to a specific group of peers.

 

So far, these are exactly the kinds of things you would expect to see in a convenient web interface, and at this point my skepticism about hiding infrastructure behind a GUI was still there.

The features below are what eventually made most of that skepticism disappear.

Routing Into a LAN

One of the most useful features for my setup is network routing through peers.

You do not have to install NetBird on every virtual machine, container, or physical device.

Instead, you can install NetBird on one machine inside the network and use it as a gateway to the required subnet.

For example, if your home network is:

192.168.1.0/24

a single NetBird peer can route traffic from other members of the mesh network into that LAN.

This is particularly useful for my infrastructure because a large portion of my services run inside VMs and LXC containers on my home server.

Previously, accessing them meant manually configuring routes and proxies.

Now it becomes part of the overlay network configuration itself.

DNS Inside the Network

DNS zones fit naturally into the same setup.

Instead of having to remember addresses like:

192.168.x.x

or:

100.x.x.x

you can give internal services proper names and manage DNS centrally. 

For a tiny network, this might be optional.

Once the number of VMs, containers, servers, and internal services starts reaching dozens, it becomes a very different story.

Reverse Proxy

But the built-in Reverse Proxy was what really sold me.

Previously, publishing another service looked roughly like this:

Internet
   ↓
Nginx / HAProxy
   ↓
TLS termination
   ↓
VPN / routing
   ↓
VM / LXC
   ↓
Application

And every one of those setups meant another bit of infrastructure to configure.

  1. Create a domain.
  2. Configure DNS.
  3. Add an upstream.
  4. Verify routing.
  5. Obtain a TLS certificate.
  6. Configure certificate renewal.
  7. Make sure nothing breaks after renewal.

With NetBird, a significant part of this can be handled directly through its Reverse Proxy.

You specify an internal service available through the NetBird network, create an endpoint, and get proxying with TLS without having to build another Nginx/HAProxy/certificate setup around every individual project.

You can also put authentication in front of the service.

For example:

  • password;
  • PIN code;
  • SSO;
  • access restrictions.

And all of this can be configured for each published service individually.

For internal dashboards, development tools, administration panels, and similar services, this is extremely convenient.

Three Hours Instead of Three Hours Per Project

The most telling part of the migration was the amount of time it took.

In roughly three hours, I migrated almost all of my projects to NetBird.

And that includes the time I spent learning NetBird itself and understanding its networking model along the way. For comparison, I could previously spend roughly the same amount of time configuring a single project.

Especially when the application was not running directly on the machine connected to OpenVPN, but somewhere inside an LXC container or VM on my home server.

What I Liked the Most

If I had to summarize the experience, these would be the main points:

  1. Adding new devices.
    Much easier than manually managing OpenVPN configurations.
  2. Mesh networking.
    There is no need to design everything around a single central VPN server as the only point through which traffic can flow.
  3. Web Dashboard.
    I can finally open a page and immediately see the state of the network.
  4. Network Routes.
    An entire LAN can be exposed through a single NetBird peer.
  5. DNS Zones.
    Internal services can have proper names without building another custom solution.
  6. Reverse Proxy.
    It turned out that a significant portion of my Nginx and HAProxy configuration was no longer necessary.
  7. Automatic TLS.
    One less infrastructure problem to solve manually for every project.
  8. Authentication for Published Services.
    Passwords, PIN codes, SSO, and other access restrictions can be applied directly to individual services.

Beautifully Simple

There is probably no better way to describe my experience.

I expected another implementation of a mesh VPN. Instead, I got a tool that either replaced or significantly simplified several layers of my infrastructure at once.

I would not claim that NetBird is a universal replacement for all of these components in every possible infrastructure.

If you have a complicated production network, highly specific routing requirements, or an already mature and automated infrastructure built around WireGuard or OpenVPN, migrating may not make any sense at all.

But for a homelab, private infrastructure, small server networks, and accessing internal services, I like it a lot so far.

In a single evening, I removed a significant amount of configuration that I had gradually accumulated around OpenVPN over the years.

And after finishing the migration, I was left with one question:

Why was I configuring all of this manually before?...