Server Network

The source material this page replaces covers systemd-networkd configuration on a bare Ubuntu server with LACP bonding. For this series, network configuration is handled by Proxmox’s own networking stack, which sits on top of Linux networking primitives but is configured via the Proxmox web interface and /etc/network/interfaces rather than systemd-networkd unit files.

This page covers two distinct networking layers: the Proxmox host itself, and the network configuration inside containers.

Proxmox host networking

Proxmox uses traditional Linux networking via ifupdown2 rather than systemd-networkd. All configuration lives in /etc/network/interfaces. The Proxmox web interface edits this file when you make changes via the GUI.

The network design for the Proxmox host involves:

• One or two physical NICs (the February server has a dual NIC)
• A management bridge (vmbr0) for the Proxmox management interface
• VLAN-aware bridges for passing VLAN-tagged traffic to containers and VMs
• Optional bonding of the dual NICs for redundancy and throughput

Identifying the network interfaces

Connect to the Proxmox shell and list the available interfaces:

ip link show

Or from the Proxmox web interface: node > Network. The interfaces show with their current configuration.

On the February server, two NICs are available. Their names depend on the hardware: typically enp6s0 and enp7s0 for PCI-e NICs, or eth0 and eth1 on some systems. Identify them by MAC address if needed:

ip link show | grep -A1 "enp"

Option 1: Single NIC (simple setup)

If only one NIC is active or bonding is not needed, the simplest configuration creates a management bridge on that NIC:

auto lo
iface lo inet loopback

auto enp6s0
iface enp6s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.1.0.10/24
    gateway 10.1.0.1
    bridge-ports enp6s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

The bridge-vlan-aware yes and bridge-vids 2-4094 settings make the bridge VLAN-aware, allowing tagged VLAN traffic to pass through to containers and VMs.

Option 2: Bonded NICs with LACP (recommended for February)

The February server has a dual NIC. Bonding both interfaces provides redundancy and can increase throughput depending on the switch configuration. The UDM-SE’s 10G SFP+ LAN port handles the upstream connection.

This requires the upstream switch (or the UDM-SE) to support LACP (802.3ad). Verify before configuring.

auto lo
iface lo inet loopback

# Physical NICs - set to manual, enslaved to bond
auto enp6s0
iface enp6s0 inet manual
    bond-master bond0

auto enp7s0
iface enp7s0 inet manual
    bond-master bond0

# LACP bond interface
auto bond0
iface bond0 inet manual
    bond-slaves enp6s0 enp7s0
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer2+3
    bond-lacp-rate fast

# Management bridge on the bond
auto vmbr0
iface vmbr0 inet static
    address 10.1.0.10/24
    gateway 10.1.0.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

The bond parameters layer2+3 and lacp-rate fast are appropriate for a connection to a Ubiquiti switch. Adjust if your switch requires different LACP settings.

Applying the configuration

After editing /etc/network/interfaces, apply the changes. On the Proxmox host this can be done without a full reboot via the web interface (node > Network > Apply Configuration) or from the command line:

ifreload -a

ifreload is part of ifupdown2 and applies configuration changes without bringing all interfaces down simultaneously. Unlike traditional ifdown && ifup, it minimises disruption.

If the changes cause loss of management connectivity, recovery requires physical console access or out-of-band management (the UDM-SE’s serial console could be used to reach the Proxmox console if direct console access is not available).

VLAN bridge for specific VLANs

For containers that need to be on specific VLANs from the network design, the VLAN-aware bridge handles this per container rather than requiring a separate bridge per VLAN. When creating or editing a container in Proxmox, the VLAN tag is set on the container’s network interface:

• Bridge: vmbr0
• VLAN tag: 14 (for Core VLAN)

The bridge automatically tags outgoing traffic and untagged incoming traffic from the container with the configured VLAN ID.

DNS server container: multiple VLANs

The DNS resolver container (Unbound) needs to be reachable from all three site subnets via the inter-site VPN. This is handled at the routing level rather than by connecting the container to multiple VLANs directly. The container sits on the Core VLAN (10.1.0.x) and the router handles routing queries from other VLANs to it.

If a container genuinely needs interfaces on multiple VLANs, Proxmox supports adding multiple network interfaces to a single container:

# Add a second interface to a container (CT ID 101) on a different VLAN
pct set 101 --net1 name=eth1,bridge=vmbr0,tag=20,ip=10.1.10.x/24

Container networking

Each LXC container gets a network interface configured when it is created. The container sees a standard Ethernet interface. From inside the container, the network looks like a normal Ubuntu server connected to a single LAN.

DHCP assignment

For containers that receive their address via DHCP from the UDM-SE (the typical case):

In the Proxmox web interface when creating the container, set:

• Bridge: vmbr0
• VLAN tag: the appropriate VLAN ID from the network design
• IPv4: DHCP

The container’s interface gets an address from the UDM-SE’s DHCP server for the specified VLAN.

Static address

For infrastructure containers that should always have the same address (DNS resolver, mail server, monitoring), set a static address either in Proxmox during container creation, or inside the container:

Edit /etc/network/interfaces inside the container:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.1.0.x/24
    gateway 10.1.0.1
    dns-nameservers 10.1.0.x
    dns-search yourdomain.net

Or use netplan if the container runs Ubuntu 24.04 with netplan enabled:

# /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        eth0:
            addresses:
                - 10.1.0.x/24
            routes:
                - to: default
                  via: 10.1.0.1
            nameservers:
                addresses: [10.1.0.x]
                search: [yourdomain.net]

Apply with:

sudo netplan apply

Verifying container network configuration

From inside a container:

# Show IP configuration
ip address show

# Verify gateway
ip route show

# Confirm DNS resolution
resolvectl status
resolvectl query google.com
resolvectl query server.yourdomain.net

From the Proxmox host, check which bridge a container interface is connected to:

brctl show vmbr0

Static address assignment reference

As service containers are deployed, record their addresses in one place. The addresses chosen should fall within the static range reserved outside the DHCP pool on the UDM-SE.

The UDM-SE DHCP pool for the Core VLAN starts at 10.1.0.100. Addresses 10.1.0.10 through 10.1.0.99 are reserved for static assignment to infrastructure.

Useful commands

# Show all network interfaces on the Proxmox host
ip addr show

# Show bridge configuration
brctl show

# Show VLAN configuration on a bridge
bridge vlan show

# Show bonding status
cat /proc/net/bonding/bond0

# Test connectivity to the UDM-SE
ping -c3 10.1.0.1

# Test connectivity across the inter-site VPN
ping -c3 10.2.0.1
ping -c3 10.3.0.1

# Show container network interfaces
pct config 101 | grep net

# Show IP routes
ip route show
ip -6 route show

Making network changes on a remote Proxmox host requires extreme care. A misconfigured bridge or bonding configuration can render the host unreachable and require physical console access to recover. Always test changes on a non-critical interface first, keep the Proxmox web interface open during changes, and have a console recovery plan before editing /etc/network/interfaces.