Proxmox VE Network Configuration for Host Nodes: Bridged vs Routed IP Blocks, Extra /24 Subnets, MAC Binding and IPv6

Most problems with VPS on a Proxmox VE host node are network problems: VMs that cannot reach their gateway, an extra /24 that works on the host but not in the VMs, or IPv6 that never answers. The fix depends on how your provider delivers the IP addresses. This guide explains the two common delivery models, bridged (on-link) and routed, shows the matching /etc/network/interfaces for each, covers MAC-bound IPs, additional /24 blocks and IPv6 subnets, and how to verify and troubleshoot the result.

Step 1: Find Out How Your IPs Are Delivered

Your server's delivery information lists each IP block with its gateway and netmask. If it does not say whether a block is routed or on-link, ask support before configuring; guessing costs hours.

Step 2: Bridged Setup (Gateway Inside the Block)

The physical NIC becomes a port of vmbr0, and the host's own IP moves to the bridge. VMs attached to vmbr0 sit on the provider's network like separate servers.

# /etc/network/interfaces  (main IP 198.51.100.10/24, gateway 198.51.100.1)
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 198.51.100.10/24
    gateway 198.51.100.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

An additional block delivered on-link (for example 203.0.113.0/24 with gateway 203.0.113.1) needs no change on the host: configure VMs on vmbr0 with an address from the block and that block's gateway, e.g. ip=203.0.113.11/24,gw=203.0.113.1.

Step 3: Routed Setup (Block Routed to the Main IP)

When the provider routes 203.0.113.0/24 to your main IP, put the block on an internal bridge that is not connected to any physical NIC, give the host the first address as the VMs' gateway, and enable forwarding.

# /etc/network/interfaces  (vmbr0 as in Step 2, plus:)
auto vmbr1
iface vmbr1 inet static
    address 203.0.113.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/80-forward.conf
sysctl --system
ifreload -a

VMs attach to vmbr1 and use addresses 203.0.113.2–254 with gateway 203.0.113.1. Because the host takes .1 and the network/broadcast addresses remain reserved, a routed /24 gives 253 usable VM addresses. Traffic leaves through the host's main interface with the VMs' own source IPs; no NAT is involved.

Step 4: MAC-Bound IPs

Some networks accept traffic for your IPs only from the server's own MAC address. Bridged VMs each have their own MAC, so their packets are dropped and they appear to have "no network" although the configuration looks right. Two solutions:

• Routed setup: ask your provider to route the block to your server's main IP, then use Step 3, so all traffic leaves through the host's own MAC address.
• Virtual MACs: if your provider offers them, request one MAC per IP and set it on the VM NIC: qm set 101 --net0 virtio=02:00:00:AA:BB:CC,bridge=vmbr0.

Step 5: IPv6 Subnets for VMs

If an IPv6 subnet (for example a /64 or /56) is routed to your host, handle it exactly like the routed IPv4 block in Step 3: put an address from the subnet on vmbr1, enable IPv6 forwarding and use that address as the VMs' gateway.

# /etc/network/interfaces: add an IPv6 stanza to vmbr1
iface vmbr1 inet6 static
    address 2001:db8:200::1/64

echo 'net.ipv6.conf.all.forwarding = 1' > /etc/sysctl.d/81-ipv6-forward.conf
sysctl --system
ifreload -a

# VM configuration (cloud-init)
qm set 101 --ipconfig0 ip=203.0.113.11/24,gw=203.0.113.1,ip6=2001:db8:200::11/64,gw6=2001:db8:200::1

Note that enabling forwarding makes Linux ignore router advertisements on the uplink, so the host's own IPv6 default route must be configured statically on vmbr0 (an iface vmbr0 inet6 static stanza with address and gateway).

If instead your only /64 is on-link on the uplink (the provider's router expects to find every address directly through neighbour discovery), VMs on a separate bridge are unreachable unless the host answers neighbour discovery on their behalf (NDP proxying, for example with ndppd) and the routing is adjusted carefully. The simpler and more reliable solution is to ask your provider for a subnet routed to your host; IMIDC support can tell you which option your server has.

Step 6: Apply and Verify

cp /etc/network/interfaces /root/interfaces.bak.$(date +%F)
ifreload -a

ip -br addr          # addresses on vmbr0 / vmbr1
ip route             # default route via the provider's gateway
bridge link          # which ports and VM taps belong to which bridge

# Watch ARP and traffic for one VM address while it pings out
tcpdump -ni vmbr0 host 203.0.113.11

# From inside the VM
ping -c3 203.0.113.1   # gateway
ping -c3 1.1.1.1       # internet
ping -c3 google.com    # DNS

If the VM can reach the gateway but not the internet, the upstream is dropping its traffic (MAC binding, missing route or wrong netmask). If it cannot reach the gateway at all, check the bridge, the VM's IP and prefix, and whether the Proxmox firewall's IP filter allows that address.

FAQ

Should I use bridged or routed networking?

Use whatever matches your provider's delivery. Bridged is simplest when the block has its own gateway on-link. Routed is required when the block is routed to your main IP, and is the robust choice when IPs are MAC-bound.

Can I mix public VMs and NAT VMs on one host?

Yes. Keep public VMs on vmbr0 or vmbr1 and put NAT VMs on a separate private bridge, as described in Proxmox VE NAT networking.

Does IMIDC deliver blocks bridged or routed?

It depends on the location and server. The gateway and netmask are in your delivery information; if anything is unclear, open a ticket and we will confirm the model and help with the configuration.

Still stuck after following these steps? Open a support ticket and the IMIDC 24/7 technical team will help. Include the host server IP, your IP blocks, the content of /etc/network/interfaces and the output of ip -br addr and ip route so we can pinpoint the issue faster.