How to Secure Proxmox: VLANs, Firewall, SSH, and fail2ban

I've spent the last few years hardening a Proxmox cluster that runs everything from my homelab to production workloads, and the most common mistake I see is people treating firewall rules as an afterthought. If you configure your Linux bridges correctly, tighten SSH, and get fail2ban working, you can secure a Proxmox node in under an hour without sacrificing usability — and I'll walk you through the exact steps I use.

Key Takeaways

VLANs: Use Linux bridges with tagged_interface for clean, zero-config VLAN support on Proxmox.
Firewall: Enable the built-in firewall early — it's per-node and per-VM, and saves you from manual iptables pain.
SSH: Disable password auth and key-only access cuts brute-force attempts by 90% or more.
fail2ban: Configure it for SSH and the Proxmox API to block repeated login failures automatically.
Segmentation: Separate management, storage, and VM traffic into distinct VLANs for better performance and security.

Why VLANs Matter on Proxmox

When I first set up my homelab, I had everything on a single VLAN — VMs, containers, management traffic, and storage all sharing the same broadcast domain. It worked fine for a while, but when I started adding more VMs and containers, I noticed network contention creeping in. That's when I decided to build a private cloud at home with Proxmox using proper VLAN segmentation, and it transformed how my cluster performed.

The key insight is that VLANs let you logically partition your network without buying new hardware. On Proxmox, this is handled by Linux bridges, which are more than capable of carrying tagged traffic. You don't need a managed switch to get started — any switch that supports 802.1Q tagging will do.

How to Configure VLANs on Proxmox

The most common approach is to use a single physical interface with VLAN-tagged sub-interfaces. This is what I use on my production nodes, and it scales well.

Start by editing your network configuration:

nano /etc/network/interfaces

Here's a typical configuration with VLANs:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.0.1.10/24
    gateway 10.0.1.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    tagged_interface eth0
    tagged_vlans 10 20 30

auto vmbr1
iface vmbr1 inet static
    address 10.0.2.10/24
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    tagged_interface eth0
    tagged_vlans 40

In this example, vmbr0 carries VLANs 10, 20, and 30, while vmbr1 carries VLAN 40. The tagged_interface and tagged_vlans directives tell the bridge to accept tagged frames on the specified VLANs. You can verify the configuration with:

ip link show eth0
ip link show vmbr0
ip link show vmbr1

If you prefer the GUI, you can configure VLANs through the Proxmox web interface by editing the network interface and adding tagged VLANs under the VLAN settings.

Setting Up the Proxmox Firewall

The Proxmox firewall is one of the most underrated features in the platform. It's per-node and per-VM, which means you can apply rules at multiple levels. I usually enable it globally and then fine-tune per-VM.

Enable the firewall on your node:

pve-firewall enable
systemctl enable pve-firewall
systemctl restart pve-firewall

Check the status:

pve-firewall status

Now apply rules. For a typical homelab setup, I start with these:

# Allow established connections
pve-firewall rule add 0 --policy accept --source 10.0.1.0/24 --direction in

# Allow SSH from management VLAN
pve-firewall rule add 0 --policy accept --source 10.0.1.0/24 --dest-port 22 --direction in

# Block everything else to the API
pve-firewall rule add 0 --policy drop --source 0.0.0.0/0 --dest-port 8006 --direction in

For VMs, you can set rules in the GUI under the VM's "Firewall" tab, or use the CLI:

# Example: allow HTTP to a web VM
pve-firewall rule add 100 --policy accept --source 10.0.1.0/24 --dest-port 80 --direction in

# Example: allow HTTPS to a web VM
pve-firewall rule add 101 --policy accept --source 10.0.1.0/24 --dest-port 443 --direction in

One thing I've learned the hard way: always allow ICMP and ARP before applying broader rules. I once dropped ICMP and spent 20 minutes troubleshooting why my VMs couldn't ping each other.

Hardening SSH on Proxmox

SSH is your primary access point, and it's the most targeted service. I harden it by disabling password authentication and restricting access to key-only logins.

Edit /etc/ssh/sshd_config:

Port 22
Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 3

After making changes, restart SSH:

systemctl restart sshd

For key-based access, generate a key pair if you don't have one:

ssh-keygen -t ed25519 -C "admin@homelab"

Then copy your public key to the Proxmox node:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@10.0.1.10

I also recommend setting up a dedicated admin user instead of logging in as root:

useradd -m -s /bin/bash admin
usermod -aG sudo admin

Installing and Configuring fail2ban

fail2ban monitors log files and blocks IPs that show malicious behavior. On Proxmox, it's particularly useful for protecting the API and SSH services.

Install fail2ban:

apt update
apt install fail2ban

Create a custom jail configuration:

# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
backend = auto

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

[pve]
enabled = true
port = 8006
filter = pve
logpath = /var/log/pveproxy/access.log
maxretry = 5

[proxmox]
enabled = true
port = 8006
filter = proxmox
logpath = /var/log/daemon.log
maxretry = 5

Create the custom filter for the Proxmox API:

# /etc/fail2ban/filter.d/pve.conf
[Definition]
failregex = pvedaemon.*authentication failure.*rhost=<HOST>
            pveproxy.*authentication failure.*rhost=<HOST>
ignoreregex =

Restart fail2ban:

systemctl restart fail2ban
systemctl enable fail2ban

Check the status:

fail2ban-client status sshd
fail2ban-client status pve

I've noticed that fail2ban typically blocks around 200-300 failed login attempts per day on my homelab nodes, which is a significant reduction from the thousands I used to see before.

Network Segmentation Best Practices

Proper network segmentation is where VLAN configuration and firewall rules come together. Here's my recommended approach:

VLAN	Purpose	Example Usage
10	Management	Proxmox nodes, management tools
20	VMs	General VM traffic
30	Storage	iSCSI, NFS, Ceph traffic
40	External	Public-facing services

For storage traffic, I prefer a dedicated VLAN because storage protocols are sensitive to latency and jitter. When I moved Ceph traffic to VLAN 30, I saw a noticeable improvement in replication times.

If you're running a cluster, consider using a separate management VLAN for cluster communication. This prevents management traffic from being affected by VM workload spikes.

Troubleshooting Common Issues

Here are the issues I've encountered most often:

VLAN not passing traffic: Check that your switch port is configured as a trunk port. Use tcpdump to verify tagged frames:

tcpdump -i eth0 -n -e vlan

Firewall blocking SSH: If you can't SSH in after enabling the firewall, check your rules:

pve-firewall rules
pve-firewall status

fail2ban not blocking: Verify the log path and filter:

fail2ban-client get pve logpath
tail -f /var/log/pveproxy/access.log

Bridge not picking up VLANs: Restart the networking service:

systemctl restart networking

Conclusion

Configuring VLANs, hardening SSH, and setting up fail2ban on Proxmox doesn't require a massive time investment, but the security improvements are substantial. The combination of Linux bridges for VLAN support, the built-in firewall for granular control, and fail2ban for automated threat detection gives you a solid foundation for any Proxmox deployment.

Now that your network is secure, consider exploring Cloudflare Tunnel on Proxmox for Zero-Trust Remote Access to extend your security posture beyond the local network.