Proxmox Cluster Networking on IONOS: Private Network with VLAN (802.1Q)
Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.
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.
Written by
Timo Wevelsiep
Co-Founder & CEO
Co-Founder of WZ-IT. Specialized in cloud infrastructure, open-source platforms and managed services for SMEs and enterprise clients worldwide.
LinkedInLet'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