VLAN Segmentation in Homelabs: Tagged Sub-vlans vs Untagged Bridges

Key Takeaways: Building VLAN Segmentation in Your Homelab

Tagging — Use sub-ifaces with tagged ports to multiplex multiple networks across one physical link, keeping your switch config clean and letting each VM or LXC pick the right lane.
Segmentation strategy — Tagged sub-vlans on a single bridge are usually enough for homelabs; reach for untagged bridges only when you need distinct routing domains per VLAN (storage vs management traffic separation, for example).
Fail2ban — A lightweight iptables-based defender that catches SSH brute-force attempts in seconds and adds real protection without the overhead of CrowdSec or a full firewall VM.

How to Build Clean Network Segmentation on Proxmox VE Without Overcomplicating It

I've spent years building homelabs around Proxmox, starting with one bare-metal server running everything through untagged ports and ending up with five VLANs per node — management, storage, VM traffic, a dedicated container network, and an isolated guest LAN for external-facing services. The secret isn't the number of VLANs; it's choosing between tagged sub-vlans on vmbr0 versus creating separate bridged interfaces (like vmbr10, vmbr20) that each carry their own IP address and route table entries independently.

Both approaches work, but they serve different goals: tagging keeps your switch configuration simple — one port carries everything with the VLAN ID as a label on every frame; untagged bridges give you true network separation at Layer 2 because each bridge is its own interface with its own MAC address and routing table. For most homelabs, tagged sub-vlans win. But if your storage traffic (iSCSI or Ceph) needs to stay completely isolated from guest VMs even on the same physical switch port, untagged bridges give you that guarantee without extra switches.

Let me show you how I set up VLAN segmentation in Proxmox VE 8.x and later with practical examples — including fail2ban for SSH protection, DNS management via dnsweaver (which automates DNS across your homelab so you stop managing records by hand), and the tradeoffs that matter when things go sideways.

The Core Approach: Tagged Sub-Vlans on vmbr0

The most common pattern I see in Proxmox installations is a single Linux bridge (vmbr0) with tagged sub-vlan interfaces for each VLAN you want to use internally. Here's what the configuration looks like when your physical NIC (say enp3s0) carries multiple networks:

auto vmbr0
iface vmbr0 inet static
    address 192.168.50.4/24
    gateway 192.168.50.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0

# Tagged sub-vlans on vmbr0
auto vmbr0.10   # Management VLAN
iface vmbr0.10 inet static
    address 192.168.50.4/24

auto vmbr0.20   # Guest VMs - tagged to enp3s0 (untagged for port)
iface vmbr0.20 inet manual
    bridge-ports none
    bridge-slaves enp3s0.20

The key insight: vmbr0 itself handles the primary network, and each .N sub-interface carries traffic tagged with VLAN N on that physical link. Your switch just needs to be configured as a trunk port carrying those VLAN IDs — no extra cabling required.

When you create VMs or LXCs through Proxmox VE's GUI (or via qm/pct CLI tools), each container gets assigned the appropriate bridge (vmbr0.10, for example). The traffic flows like this: your LXC sends a frame with VLAN tag 20 → switch sees it on trunk port and forwards accordingly → destination receives untagged or tagged depending on its config.

How Many VLANS Do You Actually Need? (Tagged vs Untagged)

Here's the comparison that saved me hours of debugging when I first started building out a homelab:

Approach	IP per VLAN	Routing complexity	Switch requirement	Best for...
Tagged sub-vlans on vmbr0	One shared primary IP; VMs get IPs via DHCP or static in each subnet	Single route table entry (bridge handles forwarding)	Trunk port with VLAN IDs configured	Homelabs, small clusters where one physical link is sufficient
Untagged bridges (`vmbr10`, `vmbr20`)	One unique IP per bridge interface; VMs share that network segment	Multiple independent subnets on the same host; routing between them requires explicit rules or a router VM like OPNsense (see OPNsense on Proxmox: Setup Guide for VLANs and HA if you want to go this route)	Access port per bridge, OR trunk with untagged mapping	Production clusters needing true Layer-2 isolation between traffic types (storage vs guest VMs)
macvlan on a single NIC	Each container gets its own MAC and IP directly from the upstream router	No bridging overhead; containers appear as direct hosts to your network	Any port type; no special switch config needed	Containerized workloads that need host-like networking without NAT (like Docker in LXC vs VMs on Proxmox — Which Setup Wins? discusses this pattern)

For most homelabs, tagged sub-vlans are the sweet spot. You get clean separation at Layer 2 with minimal switch configuration and no extra IP addresses needed for bridge interfaces themselves (beyond vmbr0's primary). The tradeoff is that all VLANs share the same physical link — so if you're saturating bandwidth on one port, everything shares it equally until things start queuing.

fail2ban: Lightweight SSH Brute-Force Defense

Once your networking is set up and VMs are talking to each other across those isolated bridges, don't overlook the front door — sshd's default brute-force protection via iptables in Proxmox VE 8.x (and later) handles this beautifully without requiring a separate tool like CrowdSec. Here's how I configure it for my homelab:

# Install fail2ban if not already present
apt update && apt install -y fail2ban

# Configure jail.local to protect SSH with iptables backend
cat > /etc/fail2ban/jail.d/ssh.conf << 'EOF'
[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
backend  = systemd

# Aggressive settings for homelab use (adjust based on your needs)
findtime    = 600
bantime     = 3600
maxretry    = 5
action      = iptables-multiport[name=sshd, port="ssh", protocol=tcp]
EOF

# Restart and verify
systemctl restart fail2ban
fail2ban-client status sshd

This setup catches failed SSH login attempts within a 10-minute window (findtime) and bans the offending IP for one hour if it exceeds five retries. The iptables-multiport action is more efficient than the default single-port rule — especially useful when you're running multiple services on different ports through your VLAN-bonded interfaces in Proxmox VE 9.x.

One gotcha I've hit repeatedly: fail2ban's log parsing can miss entries if /var/log/auth.log rotates too quickly. Check that your logrotate config isn't compressing logs before fail2ban reads them — set compress = no in /etc/logrotate.d/rsyslog for production homelabs.

DNS Management: Stop Managing Records by Hand

A common pain point once you have multiple VMs, LXCs, and services across VLANs is keeping DNS records consistent. I've used dnsweaver to automate this process — it watches your Proxmox cluster's network state (both KVM guests via qm CLI tools and LXC containers via pct) and automatically updates A/AAAA/PTR records in your upstream resolver, so you don't have to manually edit bind or CoreDNS config files.

The result: when I create a new VM through the GUI with IP 192.168.50.45 on VLAN 30 (vmbr0.30), dnsweaver picks up that event and publishes proxmox-vm-nodeX.lan IN A 192.168.50.45. No manual DNS editing, no host file hacks.

SSH Hardening Beyond fail2ban

Fail2ban handles the brute-force attacks; now let's harden sshd itself so it resists credential stuffing and protocol downgrade:

# /etc/ssh/sshd_config additions (Proxmox VE 8.x+ ships with good defaults)
Port 22
Protocol 2               # Enforce SSHv2 only
PermitRootLogin no       # Use sudo instead of root login
PasswordAuthentication no   # Key-only auth; enable temporarily for initial setup if needed
PubkeyAcceptedKeyTypes +ssh-ed25519,rsa-sha2-512,ecdsa-sha2-nistp384
X11Forwarding no         # Disable unless you need X forwarding (most don't)

# Restart sshd to apply changes
systemctl restart ssh

I've found that ssh-ed25519 keys offer the best performance-to-security ratio for homelab use. The key generation is fast (ssh-keygen -t ed25519) and they're shorter than RSA equivalents while providing comparable security margins — critical when you have dozens of VMs connecting to your Proxmox cluster over VLAN-tagged links.

When You Need More Than Linux Bridges Alone

Linux bridges work great for most homelab scenarios, but there are cases where additional hardening helps:

VLAN-aware switches: If your managed switch supports 802.1Q (nearly all do), tagged sub-vlans on vmbr0 will carry traffic cleanly without needing separate physical ports per VLAN — this is what I use in my five-VLAN setup and it works beautifully with the Automate Proxmox VE with Ansible Full VM Playbooks approach for large clusters.

Tradeoff: A single switch failure takes out all VLANs unless you have redundant switches or a second NIC bonded in LACP (which adds complexity to your bridge config).
Firewall rules: Proxmox VE's built-in firewall can enforce segmentation between VMs on different bridges without needing an external appliance. For more advanced routing and NAT, consider OPNsense on Proxmox: Setup Guide for VLANs and HA — it adds Layer 3 capabilities that Linux bridges don't provide natively (like inter-VLAN routing).

Putting It All Together in Production

Here's my typical homelab setup after five years of iteration:

vmbr0: Primary bridge on enp1s0 with tagged sub-vlans for management, storage, guest VM traffic
fail2ban guarding SSH (port 22) and Proxmox API ports (8006/8443)
dnsweaver keeping DNS records current across ~50 containers as they start/shutdown/restart
iptables rules on each bridge interface limiting inter-VLAN traffic to only what's needed

The total overhead for this setup is negligible — tagged VLAN frames add about 2 bytes per frame (4-byte tag plus FCS), and the additional routing table entries in Proxmox VE 9.x are small enough that even a modest homelab server handles thousands of simultaneous connections without noticeable latency. For most people, Build a Software-Defined Datacenter with Proxmox VE covers much of the same ground but adds more on storage and clustering details I'll explore in future posts.

Conclusion: Start Simple, Scale Smartly

VLAN segmentation on Proxmox VE doesn't require exotic tools or extra hardware — tagged sub-vlans with fail2ban protection give you clean network isolation for most homelab scenarios at a fraction of the complexity that production clusters need. The real value comes from knowing when to reach beyond Linux bridges (OPNsense VMs, separate storage VLANs) and using automation like dnsweaver so your DNS stays in sync as your cluster grows.

The next step is picking one or two services — maybe Nextcloud on an LXC with a dedicated IP — testing it across the tagged bridge setup I described above, then expanding to more complex routing rules before committing everything through Automated Backups with Proxmox Backup Server so your network changes are recoverable if something goes sideways.