Proxmox Cluster Networking on IONOS: Private Network with VLAN (802.1Q)

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

IONOS setups rarely fail because "Proxmox can't do that", but because people don't build a clean private backend network – and then Corosync or storage runs over public IPs. Yet IONOS describes very clearly how to build a private network for Dedicated Servers: via tagged VLANs according to IEEE 802.1Q (IONOS Docs).

Table of Contents

• Proxmox Needs Network Separation – IONOS Provides the Building Blocks
• What Does "tagged VLAN (802.1Q)" Mean at IONOS?
• Reference Architectures
• Step-by-Step Approach
• Common Mistakes and How to Avoid Them
• Our Approach at WZ-IT
• Related Guides

Proxmox Needs Network Separation – IONOS Provides the Building Blocks

Proxmox says: separate Corosync network is good practice; Storage must never be on the same network as Corosync (Proxmox Wiki).

IONOS provides the technical foundation for Dedicated Servers to build a private network: tagged VLANs (IEEE 802.1Q) (IONOS Docs).

What Does "tagged VLAN (802.1Q)" Mean at IONOS?

A private network of Dedicated Servers can be created by configuring tagged VLANs. VLANs are standardized in IEEE 802.1Q (IONOS Docs).

IONOS has OS-specific guides:

• AlmaLinux/Rocky: VLAN trunk (802.1Q) (IONOS Docs)
• Ubuntu/Debian: tagged VLAN for private network (IONOS Docs)

Practically this means:

• You define VLAN IDs (e.g., VLAN 10 = Management, VLAN 20 = Corosync, VLAN 30 = Storage)
• The interface becomes VLAN-aware, and traffic is logically separated
• You can build a "backend" that doesn't route publicly

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 (Dedicated)

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

Networks:

• Public: only what's really necessary (e.g., services)
• Private/VLAN: Management (or just VPN/Bastion), optional backup backend

Goal: Fast, robust, operationally secure (backups/monitoring/updates).

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 (Recommended)

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

Networks:

• Management VLAN
• Corosync VLAN (separate!) (Proxmox Wiki)
• Storage VLAN (if Ceph/storage-intensive) – never share with Corosync!

Pattern C: "2 VLANs Are Often Enough" (small cluster without Ceph)

If no Ceph:

• VLAN A: Management
• VLAN B: Corosync + Migration (or migration separate if you want to do it cleanly)

But: As soon as storage becomes intensive, separate again.

Step-by-Step Approach

Step 1: Network Plan (VLAN IDs, IP Ranges, Roles)

Before you "configure" at the OS level:

• Define VLAN IDs
• IP plan per VLAN
• Which servers go in which VLANs?
• Where does VPN/Bastion run?

Step 2: Configure VLAN/802.1Q on Dedicated Servers (IONOS Guides)

IONOS documents this as step-by-step per OS:

• AlmaLinux/Rocky: VLAN Trunk (802.1Q) for private network (IONOS Docs)
• Ubuntu/Debian: tagged VLAN for private network (IONOS Docs)

Important (Real-Life): If VLAN module/802.1Q is not correctly loaded, it won't work (IONOS mentions this in their troubleshooting notes).

You can check whether the 802.1Q module is loaded like this:

lsmod | grep 8021q || modprobe 8021q

Step 3: Properly Assign Proxmox Bridges

• Management Bridge on Management VLAN
• Corosync Interface/Bridge on Corosync VLAN
• Storage Interface/Bridge on Storage VLAN (if needed)

A VLAN-aware bridge with tagged subinterfaces looks like this in /etc/network/interfaces (Proxmox docs):

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

# VLAN 10 = Management
auto vmbr0.10
iface vmbr0.10 inet static
        address 10.10.10.11/24

# VLAN 20 = Corosync
auto vmbr0.20
iface vmbr0.20 inet static
        address 10.10.20.11/24

Unsure about the assignment? We can advise you.

Step 4: Really Run Corosync Separately

Proxmox: separate cluster network is good practice, and storage must not run in the Corosync network (Proxmox Wiki).

That's your guardrail when defining VLANs.

When creating the cluster, bind Corosync explicitly to the IP in the Corosync VLAN (Proxmox docs):

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

Step 5: Validation & Tests

After setup (before production):

• Corosync stable under load?
• Storage recovery doesn't affect Corosync?
• Migration runs over a network with bandwidth (and not over Corosync) – Proxmox otherwise often uses cluster network for migration, which is not optimal (Proxmox Forum)

Common Mistakes and How to Avoid Them

Mistake 1: "VLAN planned, but not implemented end-to-end"

One node has VLAN 20, the other doesn't → "works weird".

Fix: VLAN plan + consistent OS config everywhere.

Mistake 2: 802.1Q Module Missing / Wrong Kernel

IONOS explicitly mentions that 802.1Q module availability can be an error cause (IONOS Docs).

Fix: Load module / check kernel.

Mistake 3: Corosync + Storage in Same VLAN

Proxmox says: no (Proxmox Wiki).

Fix: Separate Storage VLAN.

Mistake 4: Management Public

Unnecessary risk.

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

Mistake 5: Migration Kills Cluster Network

When migration runs over cluster network, Corosync can suffer (Proxmox Forum).

Fix: Migration on "fat pipe" VLAN.

Our Approach at WZ-IT

For Proxmox on IONOS, we proceed as follows:

1. Requirements Analysis: Single node vs. cluster, HA goals, storage requirements
2. Network Design: IP plan, VLAN IDs, interface assignment
3. Setup: VLAN configuration (802.1Q), Proxmox installation with clean bridge 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 IONOS →

Related Guides

• Proxmox Overview
• Proxmox Maintenance & Support
• VMware to Proxmox Migration
• Proxmox on Hetzner
• Proxmox on OVH