How a routed subnet works in Proxmox

Get the upstream design first

Request more than the prefix. You need the next hop, mask, node primary address, VLAN and route-binding rule. Confirm whether additional MAC addresses are allowed and whether port anti-spoofing is active.

• public address and gateway of the physical interface;
• allocated IPv4 prefix and its actual next hop;
• VLAN ID when the subnet arrives in a separate VLAN;
• permitted MAC addresses and quantity limits;
• available MTU and any proxy ARP requirement.

Understand the routed model

The physical interface keeps the server primary address. A bridge without a physical port holds the guest network, and Linux routes packets between the external interface and that bridge. Guest MAC addresses are not exposed upstream.

IPv4 forwarding is enabled on the node. Proxy ARP is not universal; it depends on how the upstream delivers traffic to the host. Copying it from an unrelated configuration can break connectivity.

The diagram is an educational example, not a deployed Q-DC facility design. The 192.0.2.0/24 and 198.51.100.0/24 blocks are reserved for documentation and are not public Internet addresses. Here the operator routes the guest block to the host primary IP. Bridge 198.51.100.1/24 acts as the gateway for a VM at 198.51.100.10/24.

Upstream operator
  route 198.51.100.0/24 via 192.0.2.10
       |
Proxmox primary IP: 192.0.2.10
  IPv4 forwarding
       |
vmbr1: 198.51.100.1/24 (no physical port)
       |
VM: 198.51.100.10/24
  gateway: 198.51.100.1

Proxmox: network configuration IANA: TEST-NET address blocks

Assign guest addresses without conflicts

The bridge address, guest gateway and mask depend on the provider route. Some designs give each guest a /32 and an internal gateway, while others use the block mask. Both exist, but they must not be mixed accidentally.

Mark reserved addresses and keep an IPAM table with IP, VM, MAC, purpose, PTR and allocation date. This becomes essential with a /24 and several nodes.

Include firewall and anti-spoofing

Forwarding alone does not permit every required flow. Check the node firewall, Proxmox rules, guest firewall and reverse-path filtering. Strict reverse-path checks can interfere with an asymmetric design.

Prevent guests from using other addresses in the block. Large subnets need source-IP filters, MAC control and a change log so one incorrect VM cannot disrupt the fleet.

Plan for clusters and migration

When a prefix is routed to one physical server, moving a VM to another node does not move the route. You need a next-hop change, dynamic routing, a shared L2 segment or another planned failover design.

For BGP, define where provider responsibility ends and customer configuration begins. Two sessions help only when both paths and the failover mechanism have been tested.

Test the route before launch

Test inbound and outbound traffic from several external networks. Check traceroute, MTU, loss, the return path, a node reboot and network-interface restart.

A remote SSH network change can lock you out. Prepare IPMI/KVM, a configuration backup and an automatic rollback before applying it.

These read-only commands show state without changing the network. Run them on your own host and replace the documentation addresses. ip_forward should be 1, and the guest route should use the internal bridge rather than the external gateway. The local route alone does not prove upstream delivery; test inbound access from an external network.

• the guest is reachable and uses the expected source address;
• the route returns after a reboot;
• another VM cannot claim the address;
• PTR and firewall match the workload;
• IPMI/KVM provides a tested recovery path.

ip -br address
ip -4 route show
sysctl net.ipv4.ip_forward
ip -4 route get 198.51.100.10
ip -4 neigh show dev vmbr1