Proxmox Networking Explained: Bridges, VLANs, and Firewall Basics

Networking is the piece of Proxmox that trips up more beginners than anything else. Not because it’s actually complicated (the default setup for a home homelab is straightforward). But because Proxmox uses terminology and concepts (bridges, bond interfaces, VLAN tags, firewall zones) that come from enterprise networking, and most beginner resources gloss over what’s actually happening.

This guide explains how Proxmox networking works in plain language, covers the most common configurations you’ll actually need at home, and walks through the firewall setup that most guides skip entirely.

If you’re not yet running Proxmox, start with the Proxmox install guide and the Proxmox beginner’s guide first. This guide assumes you have Proxmox installed and VMs or containers running.

See the full homelab stack this fits into at /stack/.

How Proxmox networking actually works

When Proxmox installs on your machine, it takes your physical network interface (usually named eno1, eth0, or something similar on mini PCs) and creates a virtual bridge called vmbr0 on top of it.

Think of vmbr0 as a virtual network switch. Your physical NIC connects to one port of that switch. Every VM and container you create gets its own virtual NIC connected to another port of the switch. Traffic flows between them the same way traffic flows across a physical switch.

The result from your router’s perspective: each VM appears as its own separate device with its own MAC address and IP address. Your router doesn’t know or care that they’re all running on one physical machine.

Physical Machine
┌──────────────────────────────────────────┐
│  eno1 (physical NIC)                     │
│     |                                    │
│  vmbr0 (Linux bridge)                    │
│     |         |         |         |      │
│   VM100    LXC101    LXC102    VM103      │
│ .10/24    .11/24    .12/24    .13/24      │
└──────────────────────────────────────────┘
         |
     Your Router (192.168.1.1)

The Proxmox Network tab

In the web UI, go to your node name (usually pve) then System -> Network.

You’ll see two kinds of entries by default:

Physical interface (e.g., eno1, enp2s0): this is your actual NIC. It shows up as a network device with no IP assigned. The IP lives on the bridge, not the physical interface directly.

Linux Bridge (vmbr0): this is the virtual switch. The Bridge ports field will show your physical NIC name. The IP address listed here is the Proxmox host’s own IP: the one you use to reach the web UI.

One important quirk: changes you make in this UI are staged. They show up with a pending indicator. They don’t apply until you click Apply Configuration. If you apply a bad config and lose connectivity, a reboot restores the previous state. Keep this in mind before making changes remotely.

Static IPs: where they actually live

A common point of confusion: the IP address you see in a VM’s Proxmox config page is not the IP the VM will use. It’s metadata at most. The IP is set inside the VM’s operating system.

For Ubuntu VMs, that means editing Netplan:

sudo nano /etc/netplan/00-installer-config.yaml

A static IP config looks like this:

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: no
      addresses:
        - 192.168.1.20/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [192.168.1.11, 1.1.1.1]

Replace ens18 with your actual interface name (ip a will show it), and replace the IPs to match your network. Apply it:

sudo netplan apply

For Debian LXC containers, it’s the older interfaces format:

nano /etc/network/interfaces

auto eth0
iface eth0 inet static
    address 192.168.1.21
    netmask 255.255.255.0
    gateway 192.168.1.1

Then systemctl restart networking.

A few practical notes:

• Pick IPs outside your router’s DHCP range to avoid conflicts. If your router hands out .100 through .200, use .10 through .50 for static assignments.
• Pointing your VMs at a local DNS resolver (like Technitium DNS) instead of 1.1.1.1 lets you use internal hostnames and enables split-DNS for your self-hosted services.
• Write down what IP you assigned to what. A simple text file or spreadsheet is enough. You’ll look this up constantly when you have 15 services running.

Adding a second bridge

The default single-bridge setup works fine for a basic homelab. You’ll want a second bridge when:

• You want an isolated network for untrusted VMs (a separate bridge with no physical NIC attached means those VMs can only talk to each other, not to your LAN)
• You’re integrating with a managed switch that handles VLANs
• You want to separate homelab traffic from the rest of your network

Adding a bridge in the web UI: System -> Network -> Create -> Linux Bridge

Name it vmbr1 (the naming convention is just vmbr + a number). The key field is Bridge ports:

• Leave it empty for an isolated internal network. VMs on this bridge can only communicate with each other and with VMs that have a second NIC on the same bridge. They can’t reach your LAN or the internet by default.
• Enter a physical interface (e.g., eno1) to share the same physical connection as vmbr0. Usually not what you want.
• Enter a VLAN-tagged interface (e.g., eno1.20) to route this bridge through VLAN 20 on a managed switch.

To assign a VM to the second bridge, go to the VM’s Hardware tab, select its network device, and change the bridge from vmbr0 to vmbr1. Or add a second network device if you want the VM on both networks.

The isolated bridge use case

An isolated bridge (no Bridge ports) is useful for services you don’t fully trust: a media server that’s internet-accessible, a honeypot, an experiment you’re not sure about. VMs on the isolated bridge can’t reach your main LAN. You can still reach them from a VM that has NICs on both bridges, which acts as a gateway.

This is a lightweight alternative to full network segmentation that doesn’t require a managed switch.

VLANs in Proxmox

VLANs let you segment network traffic without running separate physical cables. A managed switch understands VLAN tags on frames; traffic tagged with VLAN 10 stays separate from traffic tagged with VLAN 20, even on the same physical wire. If you haven’t set up your external VLAN layout yet, the homelab network setup guide covers picking VLAN IDs, configuring a managed switch, and writing the firewall rules before you get to the Proxmox side.

For a home homelab with an unmanaged switch, VLANs require either:

1. A managed switch that supports 802.1Q VLAN tagging
2. Running entirely in software (using isolated bridges without physical NIC ports)

If you have a managed switch, the Proxmox side looks like this:

Enable VLAN awareness on the bridge: In the bridge’s settings, check “VLAN aware.” This tells Proxmox to process VLAN tags rather than strip them.

Tag the VM’s NIC: In the VM’s Hardware settings, find the Network Device and set the VLAN Tag field to the VLAN ID you want (e.g., 20 for IoT devices). Proxmox adds the 802.1Q tag to frames from that VM before they hit the bridge.

Configure the switch: Set the uplink port to Proxmox as a trunk (passes all VLANs), and configure each downstream port as an access port on the appropriate VLAN.

If you don’t have a managed switch yet, isolated bridges give you the traffic separation without the hardware. You lose VLAN segmentation at the physical layer, which matters less for a home setup than it would in a real datacenter.

The Proxmox firewall

Proxmox has a built-in firewall that operates on iptables under the hood. It’s useful but has a quirk that catches almost everyone: it has three separate scopes and you need to enable it at each scope for rules to actually apply.

The three scopes:

Scope	Location in UI	What it controls
Datacenter	Datacenter -> Firewall	Global defaults and security groups
Node	Node name -> Firewall	Traffic to/from the Proxmox host itself
VM/Container	VM -> Firewall	Traffic to/from that specific VM

The firewall must be enabled at Datacenter level AND at the individual VM level for VM rules to take effect. Enabling one without the other does nothing.

Enabling the firewall

Datacenter level: Datacenter -> Firewall -> Options -> Firewall: Yes

VM level: Click the VM in the tree -> Firewall -> Options -> Firewall: Yes

Now you can add rules. Rules at the VM level only apply to that VM. Rules in a security group (Datacenter -> Firewall -> Security Groups) can be applied to multiple VMs.

Basic firewall rules for a self-hosted service

Most people want the same thing: block everything inbound by default, allow specific ports.

The Proxmox firewall defaults to allowing all traffic (input policy: ACCEPT). To flip it:

Datacenter -> Firewall -> Options -> Input Policy: DROP

Now everything is blocked unless you explicitly allow it. Add allow rules for what you need:

Direction	Action	Protocol	Port	Comment
in	ACCEPT	tcp	22	SSH
in	ACCEPT	tcp	80	HTTP
in	ACCEPT	tcp	443	HTTPS
in	ACCEPT	tcp	8006	Proxmox web UI

Add these at the Datacenter level so they apply everywhere, then override at the VM level for specific services.

A practical note: if you’re using Tailscale for remote access (which avoids port forwarding entirely), you may not need to open ports at the firewall level at all. Tailscale creates encrypted tunnels at the VM level that bypass the need for open ports. The Tailscale homelab setup guide covers this.

Security groups

Security groups are reusable sets of firewall rules. Create one called web-services with rules to allow ports 80 and 443, then apply that group to every VM that hosts web services. When you add a new port to the group, it automatically applies to every VM in it.

To create: Datacenter -> Firewall -> Security Groups -> Create

To apply to a VM: VM -> Firewall -> Add -> Security Group -> select the group name

This is worth setting up once your firewall rules mature. You don’t need it on day one, but it beats maintaining the same rules in 12 different places.

Common networking tasks

Renaming your node

The Proxmox node name (usually pve) affects internal DNS and cluster naming. Renaming it requires editing /etc/hosts, /etc/hostname, and a few Proxmox config files. It’s possible but fiddly. If it bothers you, do it now before you have a lot of VMs configured. After that, leave it.

Bonding two NICs for redundancy

If your hardware has two NICs, you can bond them into a single logical interface for failover. In the web UI: System -> Network -> Create -> Linux Bond. Set the bond mode to active-backup for simple failover. Attach the bond to your bridge instead of the physical NIC.

On most mini PCs this doesn’t apply; they typically have one NIC. But the MINISFORUM UN100L has dual LAN ports, which makes this possible.

Checking what’s connected to a bridge

On the Proxmox host via SSH or the shell:

brctl show

This lists all bridges and which physical and virtual interfaces are attached to each one. Useful for debugging when something isn’t reaching the network.

ip a

Shows all interfaces with their current IPs and status. If a bridge shows state DOWN in this output, it means no active interfaces are connected to it.

Connecting everything with the right services

Networking in Proxmox sets the foundation for the rest of the stack. Once your VMs have static IPs on the right bridges, you can layer on:

Local DNS: Run Technitium DNS in an LXC container. Give your services internal hostnames (jellyfin.home, vault.home) instead of IP addresses.

HTTPS reverse proxy: Run Nginx Proxy Manager in Docker. It handles SSL certificates and routes traffic to the right service by hostname. No more port numbers in URLs.

Remote access: Tailscale connects your homelab to all your devices without opening any firewall ports. Your phone, laptop, and any off-site machine can reach your internal services by IP or hostname as if they were on your local network.

These three together (DNS + reverse proxy + VPN) are what turn a collection of VMs into a coherent homelab you can actually use.