Proxmox Cluster Networking on Hetzner: Using Private Networks + vSwitch Properly

Running Proxmox on Hetzner professionally? WZ-IT handles setup, network design, operations and support for your Proxmox infrastructure. View Service Page →

When a Proxmox cluster acts up, it's surprisingly often not Proxmox itself - it's the network: Corosync running over public IPs, storage or VM traffic interfering with cluster communication, MTU mismatches causing packet loss, or hybrid setups (Cloud + Dedicated) cobbled together with makeshift solutions.

The good news: Hetzner Cloud Networks (Private Networks) and vSwitch give you the building blocks to properly segment Proxmox on Hetzner - private, stable, and scalable.

Before provider configuration, use provider-neutral Proxmox cluster network design for Corosync, storage, redundancy and acceptance.

Table of Contents

• Which Networks Does a Proxmox Setup Really Need?
• Hetzner Cloud Networks (Private Networks) in Plain Terms
• vSwitch: Connecting Dedicated Servers Privately
• Reference Architectures
• Step-by-Step Approach
• Common Mistakes and How to Avoid Them
• Our Approach at WZ-IT
• Related Guides

Which Networks Does a Proxmox Setup Really Need?

Separate management, Corosync and storage traffic so that storage load does not interfere with cluster communication.

1.1 Management Network (GUI/SSH/API)

This is the access point for admins and automation:

• Proxmox Web UI
• SSH
• API / Automation
• Monitoring (e.g., metrics)

Best Practice: Don't expose management publicly to the internet. Instead: VPN/Bastion + firewall rules.

1.2 Cluster/Corosync Network (separate!)

Corosync is latency-sensitive. Best practice is a separate network for Corosync because other traffic can interfere with it (Proxmox VE Admin Guide).

Remember: Corosync is the "cluster heartbeat". If the heartbeat stutters, the cluster loses quorum - and then things get uncomfortable.

All nodes require reliable latencies below 5 milliseconds. A dedicated 1 Gbit interface is usually sufficient (Proxmox VE Admin Guide).

1.3 Storage Network (optional, but almost mandatory with Ceph)

If you're using Ceph (or generally storage-intensive traffic), you need a dedicated network.

The most important sentence from the Proxmox documentation:

Keep heavy storage and live-migration traffic off the cluster network. (Proxmox VE Admin Guide)

Storage recovery/backfill can generate massive traffic - and that's exactly what can throw Corosync off.

Hetzner Cloud Networks (Private Networks) in Plain Terms

Hetzner Cloud Networks are a private environment that allows servers to communicate directly with each other. Each server gets a private IP that is not on the Internet - connections run over dedicated interfaces as private Layer-3 links (Hetzner Docs).

What this means in practice:

• Cloud servers communicate via private IPs (without internet)
• "Management" and "backend" traffic can be placed in private networks
• Public internet remains accessible via the public IP (if desired)

2.1 Automatic Configuration (hc-utils / DHCP)

On Hetzner Cloud images, hc-utils is installed by default. Private network interfaces are automatically configured via DHCP (systemd service [email protected], DHCP client dhcpcd) (Hetzner Docs).

Important to know when you later manually adjust network tools or use special distros.

2.2 MTU Trap (don't ignore)

MTU on private and public interfaces can differ (Hetzner Docs).

For Proxmox this means: keep MTU consistent, especially on Corosync and storage networks. Half-enabled jumbo frames are a classic for "sometimes it works, sometimes it doesn't".

vSwitch: Connecting Dedicated Servers Privately

vSwitch is the lever when Proxmox runs on Dedicated Root Servers and you need private network communication - between Dedicated Servers with each other and/or with Hetzner Cloud Servers.

For Dedicated Root Servers, a vSwitch is created and the Dedicated Servers attached to it. This alone is enough to connect Dedicated Servers privately with each other (Layer-2). Optionally, the vSwitch can additionally be linked with a Hetzner Cloud Network - for this, a subnet with vSwitch connection is created in the Cloud Network (Hetzner Docs).

When Do You Need vSwitch?

Typical use cases:

• Proxmox Cluster on Dedicated - private Corosync/storage communication between nodes
• Hybrid setup - Dedicated Proxmox Nodes + Cloud Bastion/Monitoring/Automation
• Private communication between Cloud and Dedicated (admin access, backup, monitoring)
• Backend traffic private, instead of over public IPs

In short: vSwitch is the foundation for private networks on Dedicated - standalone or as a bridge to the Cloud.

Reference Architectures

Compare hosting providers before choosing hardware and networking.

Three patterns that work in projects - depending on budget and availability goals. Network planning and setup by WZ-IT: Proxmox on Hetzner.

Pattern A: Single Node on Dedicated (minimal, but clean)

For whom: Small to medium setups, cost focus, "just get started".

Networks:

• Management (secure it!)
• Optional: Backup/Storage backend (private)

Why this is okay: Proxmox can do single node. Stability then comes through operations: backups, restore tests, monitoring, update process.

Important: Single node ≠ HA. You need a plan for how to recover in case of hardware failure (RTO).

Pattern B: 3-Node Cluster (the "standard" for serious HA)

Build an HA cluster, two nodes with QDevice and storage selection.

For whom: Real failover, maintenance without downtime, resilience.

Networks:

• Management network (secure)
• Corosync/Cluster network (separate!)
• Storage network (if Ceph / storage-intensive), not shared with Corosync

Optional: A second Corosync link through Kronosnet (--link1) should use a physically separate network. Up to eight links are supported (Admin Guide).

Pattern C: Hybrid (Cloud Bastion/Tools + Dedicated Proxmox Cluster via vSwitch)

For whom: Teams that want cloud comfort (Bastion, Monitoring, CI, VPN) but run workloads on bare metal.

Networks:

• Cloud Network(s) for Bastion/Monitoring
• vSwitch connects Cloud Network ↔ Dedicated
• Dedicated nodes use private links, public IPs only where necessary

Advantage: Proxmox GUI/SSH accessible entirely via private IPs (via Bastion/VPN) instead of publicly exposed.

Set up Hetzner vSwitch and Cloud Network for Proxmox: step by step

Step 1: Define Target Architecture and Requirements

Answer before the first click:

• Single node or cluster?
• HA goal (RPO/RTO, failover expected?)
• Storage: local (ZFS) or distributed (Ceph)?
• How many networks possible (NICs/ports)?
• Who accesses how (VPN/Bastion/Office IPs)?

Step 2: IP Plan and Naming Schema (really do this beforehand!)

Define the following before setup:

• Subnets per purpose (Mgmt/Corosync/Storage)
• IP range per subnet (not too small)
• Hostnames and node IDs
• Which services on public internet (if any)

Step 3: Create Hetzner Cloud Networks

• Create at least one Cloud Network (Management/Backend)
• For larger setups: multiple subnets/networks (Mgmt separate from backend)
• Mind MTU issues with mixed interfaces

Step 4: Set Up vSwitch (Dedicated ↔ Cloud)

1. Create vSwitch
2. Attach Dedicated servers to vSwitch
3. Create Cloud Network subnet with vSwitch connection
4. Configure Dedicated OS-side

OS-side, the vSwitch is configured as a VLAN interface with MTU 1400 (Hetzner Docs):

auto enp7s0.4000
iface enp7s0.4000 inet static
        address 10.10.20.11/24
        vlan-raw-device enp7s0
        mtu 1400

Step 5: Properly Assign Proxmox Interfaces

• Management: Bridge/interface for admin access
• Corosync: dedicated interface/link
• Storage: dedicated interface/link

Bind Corosync explicitly to its dedicated link when creating the cluster; a second link provides redundancy (Proxmox docs):

# Node 1:
pvecm create CLUSTERNAME --link0 10.10.20.11 --link1 10.10.30.11
# Node 2 (Join):
pvecm add 10.10.20.11 --link0 10.10.20.12 --link1 10.10.30.12

With "just default" clustering, Corosync often ends up in the same network as GUI and VM traffic - exactly what to avoid.

Step 6: Validation

After setup (before production):

• Is Corosync running stable (no packet loss/spikes)?
• Is storage traffic really separated?
• Does live migration work without disturbing Corosync?
• Failover tests: HA/restart behavior

Check quorum and cluster membership with:

pvecm status

Common Proxmox mistakes on Hetzner: Corosync, MTU, public IPs

Mistake 1: Corosync and Storage in the Same Network

Corosync and storage should not share a network; the only exception is a low-priority fallback link in a redundant configuration (Proxmox Admin Guide).

Fix: Separate storage network. Corosync gets a "quiet" line.

Mistake 2: Cluster Over Public IP

Public IP is:

• unnecessarily exposed
• more prone to issues
• often harder to control (firewalling/NAT/routing)

Fix: Use Private Networks + vSwitch.

Mistake 3: MTU/Jumbo Frames Half-Enabled

Private and public interfaces can have different MTUs.

Fix: keep the MTU consistent along the whole path. Hetzner specifies MTU 1400 for the vSwitch VLAN interface; use jumbo frames only if every hop supports them. Check the remaining paths against Hetzner requirements.

Mistake 4: Hybrid Without vSwitch

WireGuard between Cloud and Dedicated, NAT here, routing there - works until it gets "weird".

Fix: Use vSwitch for clean Cloud ↔ Dedicated connection.

Mistake 5: Management UI Publicly Accessible

Unnecessary risk.

Fix: Bastion/VPN + restrictive firewall, management only from private networks.

Our Approach at WZ-IT

For Proxmox on Hetzner, we proceed as follows:

1. Requirements Analysis: Single node vs. cluster, HA goals, storage requirements
2. Network Design: IP plan, subnet structure, vSwitch topology
3. Setup: Cloud Networks, vSwitch, Proxmox installation with clean interface assignment
4. Hardening: Secure management, firewall, Bastion/VPN
5. Validation: Corosync stability, failover tests, monitoring
6. Documentation: Network plan, runbooks, escalation paths

We handle the complete setup or audit existing infrastructures.

View Service Page: Proxmox on Hetzner →

Related Guides

For public connectivity and private guests: Proxmox on Hetzner with one IP and a firewall VM.

• Encrypted Proxmox Backups with Hetzner Storage Box
• Proxmox Overview
• Proxmox Maintenance & Support

Sources

As of October 2026.

• Hetzner Networks

• Hetzner server configuration

• Hetzner vSwitch

• Hetzner architecture / MTU

• Proxmox Cluster Manager

• Build an HA cluster

• Install a single node on Hetzner

• Two nodes with QDevice

• Choose storage

• Cluster networking on OVH

• Cluster networking on IONOS