Hetzner Private Networking The Simple Way

Your servers probably talk to each other. Your web server needs to talk to your database. Your cache needs to talk to your application. The default way to do this is over the public internet. This is a bad idea.

It’s slow. It’s insecure. It can even cost you money in traffic fees. Every packet you send over the public internet has to travel through countless routers and switches outside your control. Any one of them could be a bottleneck or a security risk. You are sending your database credentials over a network you do not trust.

There is a simple fix for this on Hetzner. It is called a vSwitch. And it is free.

What is a vSwitch

A vSwitch is a virtual layer 2 switch. Think of it as a private network just for your servers. Any Hetzner server you own in the same location whether it is a cloud instance or a dedicated machine can be connected to it.

Once connected your servers can talk to each other using private IP addresses like 10.0.0.1. This traffic never touches the public internet. It is fast secure and free. Setting it up takes about ten minutes.

Step 1: Create the vSwitch

First you need to create the vSwitch itself. If you use dedicated servers you do this in the Hetzner Robot panel. Find your server go to the vSwitch tab and create a new one. If you use cloud servers you can also attach them to a vSwitch created in Robot. You just need to specify the vSwitch ID when you attach a private network to your cloud server in the Cloud Console.

Give it a name. That’s it. You now have a private network.

Step 2: Attach Your Servers

Now you connect your servers to this new vSwitch.

For a dedicated server you go back to the Robot panel and simply attach it. For a cloud server you navigate to your project go to Networks and add a subnet to your vSwitch. Then you can attach your cloud servers to this network. The key is that both server types can live on the same private network. This is powerful if you run your database on a powerful dedicated server and your web servers on flexible cloud instances. A common pattern we discussed in a previous post.

Hetzner will tell you which VLAN tag your vSwitch uses. It’s usually a number like 4000. You will need this for the next step.

Step 3: Configure the Network Interface

This is the only part that requires touching the command line. Your server is physically connected to the vSwitch but the operating system doesn’t know about it yet. You have to tell it how to use this new network connection.

Most modern Linux distributions like Ubuntu use netplan. The configuration files are in /etc/netplan/. You will likely see a file like 01-netcfg.yaml.

You need to add a new entry for the vSwitch interface. On most Hetzner dedicated servers the second ethernet port enp1s0 is used for private networking. Your public connection is on enp0s31f6. We need to create a VLAN interface on top of the private port.

Here is what the configuration might look like.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: true
    enp1s0:
      dhcp4: no
  vlans:
    vlan4000:
      id: 4000
      link: enp1s0
      addresses: [10.0.0.1/24]

Let’s break this down. We are defining a new virtual interface called vlan4000. The id: 4000 must match the VLAN tag Hetzner gave you. The link: enp1s0 tells the system this VLAN runs on top of the physical interface enp1s0.

The most important line is addresses: [10.0.0.1/24]. This assigns a static private IP address to this server. The /24 part defines the subnet size allowing for about 254 addresses. Your second server could be 10.0.0.2/24 your third 10.0.0.3/24 and so on. They must all be in the same subnet to talk to each other.

After you save this file you apply the changes.

sudo netplan apply

Your server now has two IP addresses. A public one for the outside world and a private one for your other servers. You can check this with ip addr. You should see your 10.0.0.1 address on the vlan4000 interface.

For your second server say a cloud instance you would repeat the process. The netplan configuration would be almost identical but you would give it a different address.

# On your second server
network:
  version: 2
  renderer: networkd
  # ... other config ...
  vlans:
    vlan4000:
      id: 4000
      link: enp1s0 # Or whatever the private interface is called
      addresses: [10.0.0.2/24]

Step 4: Test and Use It

Now from your first server (10.0.0.1) you should be able to ping your second server (10.0.0.2).

ping 10.0.0.2

If you get a reply it works. The traffic is flowing over your private network not the public internet.

The final step is to change your application configurations. Instead of connecting to your database over its public IP you now use its private IP.

Your database connection string might change from postgres://user:pass@public_ip:5432/db to postgres://user:pass@10.0.0.2:5432/db. This is not only faster and more reliable but also much more secure. You can even configure your database firewall to only accept connections from the private 10.0.0.0/24 range completely shielding it from the public internet. We talked about basic firewall rules in a post on debugging connections.

Hetzner Cloud Networks

If you only use cloud servers and not dedicated servers Hetzner offers something called Cloud Networks. They are similar to a vSwitch but operate at layer 3. They are easier to manage from the cloud console and don’t require manual IP address configuration.

The trade off is they only work for cloud servers in the same project. If you have a mix of dedicated and cloud machines or servers across different projects a vSwitch is the way to go. For many hybrid setups the vSwitch is the more powerful and flexible tool.

Using private networking is not an advanced trick. It is a fundamental part of building robust infrastructure. The fact that Hetzner provides this for free is a huge advantage. It’s one of those simple changes that makes your whole system better.

— Rishi Banerjee
September 2025