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.

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?

Proxmox works with "everything in one network". But it only gets good (and HA-capable) when you properly separate traffic.

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 Wiki).

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

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:

"Storage communication should never be on the same network as corosync!" (Proxmox Wiki)

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. More details on implementation on our Proxmox on Hetzner Service Page.

---

Reference Architectures

Three patterns that work in projects – depending on budget and availability goals. All three we regularly implement for clients (→ Service Page).

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). We help with planning and implementation.

---

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

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

Networks:

• Management network (secure)
• Corosync/Cluster network (separate!)
• Storage network (if Ceph / storage-intensive) – never share with Corosync!

Optional: Redundancy for the cluster network (second ring) – recommended via two physically separate networks (RRP).

---

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.

---

Step-by-Step Approach

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!)

A simple plan saves days later:

• 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

Step 5: Properly Assign Proxmox Interfaces

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

With "just default" clustering, Corosync often ends up in the same network as GUI and VM traffic – exactly what to avoid. Unsure about the assignment? We can advise you.

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

---

Common Mistakes and How to Avoid Them

Mistake 1: Corosync and Storage in the Same Network

Storage communication never in the Corosync network.

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: MTU consistent end-to-end. If jumbo: everywhere. If not: everywhere 1500.

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

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