Your server was handed over with its first IPv4 address configured on the host and nothing else. Every other address on your account is yours to place. This guide covers the three ways to do it on a Server Room machine: bridged, where a guest sits on our network with its own MAC address; routed, where the host forwards for it; and a private subnet behind your primary address. Each configuration here was tested on our own network before it was published.
Work through step one and two first. Then pick step three, four or five — they are three answers to the same question, not a sequence.
The Dedicated Server Setup email sent when your machine was built lists every address allocated to it, IPv4 first and then IPv6. The same list is in your control panel on the server's page, under Access, Networking & rDNS, where each address is shown with its reverse DNS record.
On a Proxmox build the email carries an extra line, and it is the reason this page exists: only the first address is configured on the host. The others are yours to assign from Proxmox, to your virtual machines or to the host itself. Our installer deliberately configures one address and stops, because a host holding all of them would answer for every one of them and leave nothing for your guests.
The netmask is always /24 (255.255.255.0) and the gateway is always the .1 of the /24 that address itself sits in. That second half matters more than it looks. Addresses ordered together are consecutive inside one /24, so they share a gateway. Addresses added to an existing server later can come from a different range of ours, and then each one uses its own .1 — for example an address in 203.0.113.0/24 uses 203.0.113.1 even on a machine whose primary address is in another range. Both work on the same port and on the same bridge.
The resolver our installer configures is 209.244.0.3. You are free to point your guests anywhere else.
Sign in over SSH as root and look at the interfaces the installer wrote:
ip -br addr cat /etc/network/interfaces
A freshly built machine looks like this, with your own interface name and your own primary address in place of the examples:
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 203.0.113.10/24
gateway 203.0.113.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
vmbr0 is already a bridge and the physical interface is already a port on it. That is the whole of the bridged model, which is why step three asks you to change nothing on the host.
Proxmox VE 9 is Debian 13 and uses ifupdown2, so a configuration change does not need a reboot. Edit /etc/network/interfaces and apply it with:
ifreload -a
If you edit the network through the Proxmox web interface instead, your changes are staged in /etc/network/interfaces.new until you press Apply Configuration. Either way, open the server console from your control panel before you reload. A mistake in this file takes the machine off the network, and the console is how you get back in without a ticket.
This is the one to use unless you have a reason not to. The guest is an ordinary machine on the same segment as the host, it talks to our routers directly, and nothing on the host changes at all.
In the Proxmox interface, give the virtual machine a network device on bridge vmbr0 and leave the MAC address Proxmox generated for it. Then configure the address inside the guest exactly as you would on any server. For a Debian or Ubuntu guest using ifupdown:
auto lo
iface lo inet loopback
auto ens18
iface ens18 inet static
address 203.0.113.58/24
gateway 203.0.113.1
dns-nameservers 209.244.0.3 1.1.1.1
For an Ubuntu guest using netplan, in /etc/netplan/01-netcfg.yaml:
network:
version: 2
ethernets:
ens18:
addresses: [203.0.113.58/24]
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses: [209.244.0.3, 1.1.1.1]
A Windows guest takes the same three values in the adapter's IPv4 properties. Any operating system works, because from our side this is simply another machine on the subnet.
You do not have to register a guest's MAC address with us, and we do not limit how many your port may use. Some hosting companies do, and their documentation tells you to declare a MAC for every virtual machine. Ours does not: the switch port your server is on carries no MAC-count restriction and port security is switched off, so a guest MAC is learned exactly like the host's. We tested this before publishing it, by putting a second MAC and a spare address on a staff server's own customer port and reaching it from the public internet.
Three things to keep right:
• Give every guest a distinct MAC address. Two guests sharing one, or a guest copying the host's, breaks both of them.
• Use the gateway belonging to that address's own /24, from step one.
• Only ever configure an address that is allocated to your account. The bridge faces a real network shared with other machines. Taking an address that is not yours takes somebody else's traffic with it.
For the same reason, do not run a DHCP server, a rogue router advertisement daemon or anything else that answers for the segment on vmbr0. If you want to serve DHCP to your own guests, use the private-subnet model in step five, where the bridge has no physical port and cannot reach anyone else.
Use this when you want every packet to and from a guest to pass through the host, so that the host's firewall sees it, or when you would rather your guests never appeared on our layer 2 at all. The address is still a public one from your account; only the path changes.
The public address moves off the bridge and onto the physical interface, the host forwards, and it answers ARP on behalf of the guests it routes for. On the host:
auto lo
iface lo inet loopback
auto eno1
iface eno1 inet static
address 203.0.113.10/24
gateway 203.0.113.1
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up echo 1 > /proc/sys/net/ipv4/conf/eno1/proxy_arp
auto vmbr0
iface vmbr0 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
up ip route add 203.0.113.58/32 dev vmbr0
down ip route del 203.0.113.58/32 dev vmbr0
Add one up and down pair per routed address. Inside the guest, the address is a /32 and the host is reached by an explicit on-link route before the default route:
auto lo
iface lo inet loopback
auto ens18
iface ens18 inet static
address 203.0.113.58/32
post-up ip route add 203.0.113.10 dev ens18
post-up ip route add default via 203.0.113.10
dns-nameservers 209.244.0.3 1.1.1.1
Two notes on the host stanza. The proxy_arp line is what makes this work here: our routers ask on the segment for the guest's address, and the host answers for it. Without that line the guest is silent from outside. And the two post-up echo lines are Proxmox's own documented form; if you would rather set them once and for all, put net.ipv4.ip_forward=1 and net.ipv4.conf.eno1.proxy_arp=1 in a file under /etc/sysctl.d/ instead.
Routed costs you a little configuration in every guest and gives you a host that can filter, count and log everything. Bridged costs nothing and gives you neither. That is the whole trade.
Guests that only need to reach out — build agents, workers, a database that nothing outside should touch — do not need a public address at all. Put them on a bridge with no physical port and let the host translate their traffic to its own address on the way out. This costs no addresses and is the cheapest way to run a lot of machines.
Add a second bridge on the host, leaving vmbr0 as it is:
auto vmbr1
iface vmbr1 inet static
address 10.10.10.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
Guests go on vmbr1 with an address in that range, 10.10.10.1 as their gateway, and whatever resolver you prefer. They reach the internet as your server; nothing from outside reaches them unless you say so. To publish one service, add a forwarding rule beside the masquerade rule, choosing a port the host is not using itself:
post-up iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443 post-down iptables -t nat -D PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443
Since this bridge has no physical port, a DHCP server on it is perfectly safe and is a reasonable way to address your guests.
Your IPv6 allocation is a set of individual addresses, not a delegated prefix you can carve up. They are listed in the same setup email, under the IPv4 ones, and they are placed one at a time exactly as IPv4 addresses are: one on the host if you want the host reachable, the rest on guests. The installer configures none of them.
Configure each with a /64 prefix length, and the gateway is the prefix followed by ::1 — so an address inside 2001:db8:1234::/64 uses 2001:db8:1234::1. On the host, add an IPv6 stanza beside the existing bridge:
iface vmbr0 inet6 static
address 2001:db8:1234::2/64
gateway 2001:db8:1234::1
And in a bridged guest:
iface ens18 inet6 static
address 2001:db8:1234::5/64
gateway 2001:db8:1234::1
Apply with ifreload -a as before. Because the addresses are individual rather than a prefix of your own, do not run router advertisements or hand out addresses you were not given. If you need more than you have, ask us.
Reverse DNS is yours to edit, on every address, without a ticket. Sign in, open the server's page, and find the Access, Networking & rDNS panel. Every address on the account is listed there with its current record and an Edit rDNS button. IPv4 and IPv6 both work.
The form takes a hostname: letters, digits, hyphens and dots only, each label between 1 and 63 characters, at least two labels, and it adds the trailing dot for you. Changes take a few minutes to appear.
If the machine sends mail, set the reverse record on the address the mail actually leaves from — which, in the private-subnet model above, is the host's address rather than the guest's — and create the matching forward record at your own DNS provider. Receiving mail servers check that the two agree.
The questions this configuration actually generates.