OVH Additional IP in Proxmox: bridge, gateway and NAT

WZ-IT supports setup and network planning for Proxmox on OVHcloud. Arrange a conversation.

An OVH Additional IP is an extra public IPv4 address. How it reaches a Proxmox VM depends on the server range and network mode: in bridge mode the VM gets a virtual MAC, in routed mode the host routes. This article shows both with example configuration, separates vRack and lists checks. Sources: OVHcloud documentation, as of October 2026.

Contents

• Check server range and network mode first
• Set up an Additional IP in bridge mode
• Set up an Additional IP in routed mode
• Separate vRack
• Single IP with OPNsense
• Acceptance and common mistakes

Check server range and network mode first

Record product range, generation, allocated IPs and the current network mode before changing the host configuration. A single gateway recipe for all OVH servers would be wrong.

Set up an Additional IP in bridge mode

The vendor procedure provides these steps:

1. Assign the Additional IP to the correct dedicated server and check the availability of virtual MACs for the product line.
2. In the Control Panel under Network > Public IP Addresses select the single IP and add a virtual MAC. For Proxmox use type ovh (vmware is for ESXi).
3. Power off the VM and enter the MAC under Hardware > Network Device.
4. Read the server's gateway from the Control Panel (Network, General Information) or through the API. Do not derive it from the IP.
5. In the guest, configure the Additional IP with mask /32 and this gateway, and set the route to the gateway as on-link.

Example for Netplan (/etc/netplan/00-installer-config.yaml) with addresses from the documentation range:

network:
  ethernets:
    ens18:
      addresses:
        - 192.0.2.1/32
      routes:
        - to: 0.0.0.0/0
          via: 203.0.113.254
          on-link: true

Or on Debian with /etc/network/interfaces:

auto ens192
iface ens192 inet static
  address 192.0.2.1
  netmask 255.255.255.255
  gateway 203.0.113.254

The mask is always 255.255.255.255 because the gateway lies outside the guest prefix. The public bridge provides the network path; guest and provider filters still need separate checking.

Set up an Additional IP in routed mode

In the routed procedure the host handles forwarding and routes to the guests. The Additional IPs are assigned to the server but carry no virtual MAC.

Host: The guide creates the public bridge vmbr0 with the server IP as /32 and the gateway from the guide, plus a private network such as 192.168.0.1/24 and one route per Additional IP onto the bridge. On HG/Scale vmbr0 sits on a bond0 in 802.3ad mode, on Advance directly on the physical interface. The pattern:

up ip route add <ADDITIONAL_IP>/32 dev $IFACE

Enable forwarding (/etc/sysctl.conf):

net.ipv4.ip_forward = 1

Guest: The VM gets the private address (192.168.0.x/24, gateway 192.168.0.1) and the Additional IP as /32. So that outbound traffic uses the Additional IP as source, bind the route to that address with src (ifupdown) or from (Netplan). Test from the guest: curl ifconfig.io must return the Additional IP.

With a server-bound Additional IP, a VM move must also account for the provider assignment of the IP.

Separate vRack

vRack is a different path: the OVHcloud procedure requires an Additional IP block, not a single /32 directly in the vRack. Plan the block and its reserved addresses according to that guide. Private cluster communication and public guest addresses are separate tasks; network separation for Corosync and storage is covered in Proxmox cluster networking on OVH.

Single IP with OPNsense

Without an Additional IP, a private guest network behind the host IP can be planned. Proxmox documents masquerading, OPNsense NAT and port forwards. The configuration with bridge, masquerading and port forward matches the setup in Proxmox on Hetzner with one IP and a firewall VM; only the uplink name differs. Such a setup is not bridge mode with its own public VM IP. Do not forward management ports across the board and secure console or rescue access before changes.

Acceptance and common mistakes

For acceptance: compare IP assignment and MAC, check gateway reachability, verify DNS and outbound source IP (curl ifconfig.io), test permitted and blocked services from outside, and assess reboot and VM move.

• No connectivity in bridge mode: The virtual MAC does not match the VM, the VM was not powered off when entering it, or the gateway was derived from the IP.
• No connectivity in routed mode: A virtual MAC sits on the Additional IP, ip_forward is not active or the route to the Additional IP is missing on the host.
• Wrong source IP: In routed mode src or from is missing on the guest route.
• /32 in the vRack: The procedure requires an Additional IP block.
• Connection gone after a move: The Additional IP is not assigned to the target server.

Related guides

• Proxmox cluster networking on OVH: separating vRack, Corosync and storage
• Proxmox on Hetzner with one IP and a firewall VM

WZ-IT supports setup and network planning for Proxmox on OVHcloud. Arrange a conversation.

Sources

• OVHcloud: Network Bridging
• OVHcloud: Proxmox networking in routed mode (HG/Scale/Advance)
• pve.proxmox.com: Administration Guide, networking
• docs.opnsense.org: NAT