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).
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)
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.
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:
- Requirements Analysis: Single node vs. cluster, HA goals, storage requirements
- Network Design: IP plan, VLAN IDs, interface assignment
- Setup: VLAN configuration (802.1Q), Proxmox installation with clean bridge assignment
- Hardening: Secure management, firewall, Bastion/VPN
- Validation: Corosync stability, failover tests, monitoring
- Documentation: Network plan, runbooks, escalation paths
We handle the complete setup or audit existing infrastructures.
View Service Page: Proxmox on IONOS →
Related Guides
Frequently Asked Questions
Answers to important questions about this topic
A private network can be built via tagged VLANs; VLAN is standardized according to IEEE 802.1Q.
A VLAN tag logically separates traffic into different networks over a single interface (trunk).
So that Corosync/cluster and storage/backend run privately and separately – exactly as Proxmox recommends.
Yes. VLAN is particularly important when you want to cleanly separate multiple nodes/backend traffic.
IONOS has OS guides (AlmaLinux/Rocky, Ubuntu/Debian) for VLAN trunk 802.1Q.
Inconsistent configuration (one node tags VLAN, another doesn't) or wrong VLAN ID.
Because other traffic can interfere with Corosync; Proxmox recommends a separate cluster network.
No. Proxmox: Storage never in the Corosync network.
Single node: optional. Cluster: at least Mgmt + Corosync; with Ceph better to add Storage.
IONOS mentions missing 802.1Q kernel module as a possible error cause.
IONOS describes exactly this in their guides: configuring an interface as 802.1Q VLAN trunk.
Not public: Bastion/VPN + Firewall, only allow admin networks.
Single node: usually ZFS. Ceph only if your network/disks/nodes are set up for it.
Put migration on a wide VLAN/network; Proxmox otherwise often uses cluster network for migration.
Yes – best to set up a clean IP/VLAN plan and operations (backup/monitoring) early.
Check routing/interfaces: Corosync/Storage IPs must not be on public interfaces; firewall logs help additionally.
Let's Talk About Your Idea
Whether a specific IT challenge or just an idea – we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.
Trusted by leading companies
Timo Wevelsiep & Robin Zins
CEOs of WZ-IT