Proxmox VLANs Configuration for Secure Network Access

Configuring VLANs on Proxmox with Linux bridges and pairing them with the built-in firewall and fail2ban creates a network layer that blocks unauthorized traffic before it reaches your workloads. This setup isolates management, VM, and storage traffic into dedicated segments while automatically blocking brute-force attempts across all tagged interfaces. The result is a Proxmox host that enforces least-privilege network access and recovers quickly from scanning or credential-stuffing attacks.

Key Takeaways

• VLAN Tagging: Tagging the uplink port on the Linux bridge lets a single physical NIC carry multiple isolated networks without sub-interfaces.
• Firewall Policies: Proxmox's native firewall supports per-VLAN rules, so you can restrict inter-VLAN traffic without external routers.
• fail2ban Integration: Monitoring SSH and the Proxmox API across VLAN-tagged interfaces catches brute-force attempts within minutes.
• SSH Hardening: Disabling password auth and restricting listening interfaces reduces the attack surface on every VLAN segment.
• Tradeoff: VLAN segmentation adds configuration overhead but eliminates the need for a separate hardware firewall in most homelab and small-production environments.

Why VLANs Matter for Proxmox Security

A flat network treats every VM, container, and the Proxmox host itself as peers on the same broadcast domain. That simplicity works until you need to isolate management traffic from VM workloads, or when an untrusted device on the guest VLAN can reach your storage backend. VLANs solve this by splitting the broadcast domain at Layer 2, and Proxmox handles this natively through Linux bridges.

When you combine VLAN segmentation with Proxmox's built-in firewall, you get policy enforcement at the hypervisor level. This means rules travel with the VMs during live migration, unlike rules tied to a specific physical switch port. You also avoid the latency and CPU overhead of routing between VLANs for east-west traffic, since the bridge forwards frames directly.

For environments that already use Cloudflare Tunnel on Proxmox for Zero-Trust Remote Access, VLANs provide a clean internal boundary. The tunnel handles external authentication, while VLANs enforce internal segmentation, creating a defense-in-depth model.

How to Configure VLAN-Aware Linux Bridges

The most reliable way to handle multiple VLANs on Proxmox is to enable VLAN filtering directly on the Linux bridge. This approach uses a single physical NIC and lets the bridge tag and untag frames based on the port configuration. It is simpler than creating sub-interfaces and performs well even under heavy I/O.

Start by checking your current Proxmox version and bridge status:

pveversion -v
brctl show

Edit the network configuration file to define the bridge with VLAN filtering enabled:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

The bridge-vlan-aware yes directive turns on VLAN filtering, and bridge-vids 2-4094 allows all standard VLAN IDs to pass through. The management IP stays on the untagged port, typically VLAN 1, which is implicit.

Apply the changes and verify the bridge is filtering correctly:

systemctl restart networking
bridge vlan show dev enp3s0

You should see the physical port listed as a member of the allowed VLANs, with the management VLAN marked as untagged. For deeper automation, consider pairing this with Automate Proxmox VE: Essential Scripts for Homelab Backups, Health Checks & VLANs to validate VLAN assignments after every network restart.

Setting Up Proxmox Firewall Rules for VLAN Segmentation

Proxmox's firewall can enforce policies per node, per VM, or per container, and it understands VLANs when the bridge is configured correctly. This allows you to create rules that apply only to traffic on specific VLANs, reducing the need for complex iptables chains.

Enable the firewall at the node level:

pve-firewall enable
pve-firewall start

Create a firewall group to represent your guest VLAN traffic:

pve-firewall group add guest_vlan
pve-firewall group add mgmt_vlan

Assign VMs and containers to these groups based on their network interface VLAN tag. For example, a VM with net0=virtio,bridge=vmbr0,tag=100 would belong to the guest_vlan group.

Define rules to allow established connections and restrict new traffic:

pve-firewall rule add guest_vlan --source 192.168.100.0/24 --dest 192.168.10.0/24 --proto tcp --dport 80,443 --action accept
pve-firewall rule add guest_vlan --source any --dest any --proto tcp --dport 22 --action drop

The first rule allows HTTP and HTTPS traffic from the guest VLAN to the management VLAN, while the second drops all other TCP port 22 traffic unless explicitly allowed. This setup works well alongside Cockpit on Proxmox: Manage KVM, LXC, and Docker in One UI for visual rule management.

VLAN ID	Purpose	Example Subnet	Firewall Group	Default Action
1	Management	192.168.1.0/24	mgmt_vlan	Accept
100	Guest VMs	192.168.100.0/24	guest_vlan	Drop
200	Storage	192.168.200.0/24	storage_vlan	Drop
300	DMZ	192.168.300.0/24	dmz_vlan	Accept

This table illustrates a typical segmentation scheme. The management VLAN accepts all traffic, while guest, storage, and DMZ VLANs drop traffic by default, requiring explicit rules for allowed flows.

Integrating fail2ban with Proxmox VLAN Interfaces

fail2ban monitors log files for repeated authentication failures and temporarily bans the offending IP addresses. On a Proxmox host with multiple VLANs, it is crucial to ensure fail2ban tracks SSH connections across all tagged interfaces, not just the management IP.

Install fail2ban if it is not already present:

apt update
apt install fail2ban

Configure fail2ban to monitor the Proxmox SSH service on all VLAN interfaces:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

The port = ssh directive tells fail2ban to use the SSH service definition from /etc/ssh/sshd_config, which should list all VLAN interfaces. Verify this by checking the SSH configuration:

grep "^ListenAddress" /etc/ssh/sshd_config

If you see multiple ListenAddress entries, fail2ban will correctly identify bans across all VLANs. For a cluster-wide approach, consider CrowdSec on Proxmox: Cluster-Wide Brute-Force Defense as an alternative that shares ban lists between nodes.

Test the configuration by attempting multiple failed SSH logins from a guest VLAN IP:

systemctl status fail2ban
fail2ban-client status sshd

You should see the guest IP added to the ban list after three failed attempts, with a ban duration of one hour.

SSH Hardening for VLAN Isolation

SSH is the primary management interface for Proxmox, and hardening it reduces the risk of unauthorized access across VLANs. Key steps include disabling password authentication, restricting the SSH port, and enabling key-based auth for all users.

Edit the SSH configuration file to apply these changes:

Port 22
Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers pveadmin docker

The AllowUsers directive restricts SSH access to specific users, which is particularly useful when multiple VLANs share the same SSH service. For example, the pveadmin user might handle management tasks, while docker manages container workloads on the guest VLAN.

Restart the SSH service to apply the changes:

systemctl restart ssh

Verify the configuration by attempting to log in from a guest VLAN IP without a key:

ssh -o PreferredAuthentications=password pveadmin@192.168.100.50

The connection should be rejected, confirming that only key-based authentication is allowed. This setup complements the firewall rules defined earlier, creating a two-layer defense for SSH traffic.

For users who prefer a graphical interface, Cockpit on Proxmox: Manage KVM, LXC, and Docker in One UI provides a web-based SSH client that simplifies these configurations.

Tagged vs Untagged VLANs on Proxmox

Understanding the difference between tagged and untagged VLANs is essential for correct bridge configuration. Untagged VLANs are used for the management interface, while tagged VLANs carry traffic for VMs and containers.

Feature	Tagged VLANs	Untagged VLANs
Use Case	VM and container traffic	Management interface
Bridge Configuration	bridge-vids 2-4094	Implicit VLAN 1
Switch Port Mode	Trunk	Access
Proxmox Interface	tag=100 in net0	Default
Example Subnet	192.168.100.0/24	192.168.1.0/24

This table summarizes the key differences. Tagged VLANs require explicit configuration in the Proxmox network interface definition, while untagged VLANs use the default VLAN 1 and do not require tagging.

A common gotcha is forgetting to set the tag parameter in the VM or container network interface definition. Without it, the traffic will be sent untagged and may not reach the correct VLAN on the switch. Always verify the VLAN assignment by checking the bridge VLAN table after configuring new workloads.

Conclusion

Configuring VLANs on Proxmox with Linux bridges and pairing them with the built-in firewall and fail2ban creates a network layer that enforces least-privilege access and automates threat response. This setup isolates management, guest, and storage traffic while blocking brute-force attempts across all tagged interfaces. The next step is to validate your configuration by simulating traffic flows and monitoring ban events in the fail2ban logs. For further automation, consider Automate Proxmox VE with Ansible Full VM Playbooks to manage these settings across multiple hosts.