WZ-IT supports setup and network planning for Proxmox on IONOS. Arrange a conversation.
As of October 2026. Recheck product conditions before making changes.
Contents
- A private VM network is not an IONOS Private Network
- Check the product line before bridging
- Plan a private bridge and NAT
- Checks and distinction from public IPs
A private VM network is not an IONOS Private Network
A local private bridge connects guests on one Proxmox host. An IONOS Private Network connects assigned dedicated servers in the Cloud Panel through tagged VLANs. It does not by itself provide internet access for private guests. The Proxmox networking documentation distinguishes bridging, routing and masquerading.
This article covers guests behind one public IPv4. The existing cluster networking guide covers provider VLAN setup.
Check the product line before bridging
The older IONOS virtualization guidelines explicitly cover the listed products managed through server administration: unauthorized guest MACs on the public network can trigger disconnection; NAT is prescribed instead of direct bridging. This is not a blanket rule for every current IONOS product.
The Cloud Panel documentation describes dedicated servers with a public network that permits multiple MAC addresses. Establish the contract, management interface and network conditions first. IONOS Cloud with Data Center Designer is not an interchangeable configuration target either.
Plan a private bridge and NAT
Masquerading is the documented Proxmox mechanism for private guests to communicate outward using the host IP. For one host, plan to:
- Record the existing uplink, default route, DNS and management access. Check console access and rollback before a network change.
- Choose a non-overlapping private subnet. Create the local VM bridge without a physical uplink and give the host a gateway address on it.
- Attach private guests to the bridge and configure the host gateway and a reachable DNS resolver.
- Configure forwarding, source NAT and forwarding filters for the active firewall backend. Allow only planned destinations and services.
- Publish inbound services individually through DNAT or an intended proxy. Outbound NAT does not automatically expose inbound services.
Example configuration. The setup follows the masquerading pattern of the Proxmox documentation. <uplink> is the interface with the public IP (found with ip -br link and ip route); subnet and addresses are placeholders:
# /etc/sysctl.d/ip-forwarding.conf
net.ipv4.ip_forward = 1
# /etc/network/interfaces, in addition to the existing uplink configuration
auto vmbr1
iface vmbr1 inet static
address 10.20.0.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up iptables -t nat -A POSTROUTING -s 10.20.0.0/24 -o <uplink> -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s 10.20.0.0/24 -o <uplink> -j MASQUERADE
# example: publish an HTTPS service of a VM
post-up iptables -t nat -A PREROUTING -i <uplink> -p tcp --dport 443 -j DNAT --to-destination 10.20.0.20:443
post-down iptables -t nat -D PREROUTING -i <uplink> -p tcp --dport 443 -j DNAT --to-destination 10.20.0.20:443
Guests get addresses from 10.20.0.0/24, 10.20.0.1 as gateway and a reachable DNS resolver. The further notes on console access, restarting the network configuration and the firewall backend match the example in Proxmox on Hetzner with one IP and a firewall VM; the configuration differs only in the uplink name and the product check above.
After applying, check:
sysctl net.ipv4.ip_forward # expected: 1
iptables -t nat -L -n -v # MASQUERADE and DNAT rules with counters
# in the guest:
ip route # default route via 10.20.0.1
curl -4 ifconfig.me # should show the public host IP
For multiple hosts, first assign the provider VLAN using the IONOS guide and the actual VLAN ID. A local bridge without an uplink does not create a network between servers by itself.
Checks and distinction from public IPs
For acceptance, we recommend a recorded matrix: the guest reaches its gateway, DNS and intended external services; the expected host IP appears externally; only explicitly published services are reachable from outside. Check behavior after host reboot and with forwarding blocked. Across multiple hosts, also check VLAN reachability and possible address conflicts.
Give management, cluster communication and guest traffic separate rules. An additionally ordered public IP is a different scenario: allocation, routing and return path need checking. Do not simply replace private addresses with public ones.
Related guides
- Proxmox Cluster Networking on IONOS: Private Network with VLAN (802.1Q)
- Proxmox on IONOS: multiple public IPs and routing
WZ-IT supports setup and network planning for Proxmox on IONOS. Arrange a conversation.
