DEV Community: Luna Commsnet

Self-Hosted Monitoring Stack: Zabbix + Grafana for Home Infrastructure

Luna Commsnet — Mon, 22 Jun 2026 15:51:36 +0000

Self-Hosted Monitoring Stack: Zabbix + Grafana for Home Infrastructure

Published: June 15, 2026 | CommsNet

You know that feeling when something breaks and you only find out because the website is down? That's not monitoring — that's embarrassment detection. Real monitoring tells you before things break. It shows you the memory leak that started three hours ago, the disk that's filling at 2% per day, the SSL certificate expiring in 12 days.

Enterprise monitoring platforms (Datadog, New Relic, Splunk) cost hundreds to thousands per month. For a homelab, that's absurd. But running blind is worse. The answer: self-hosted Zabbix for data collection and alerting, paired with Grafana for visualization. Together, they give you enterprise-grade observability at the cost of the electricity to run them.

In this article, I'll walk through deploying a complete Zabbix + Grafana monitoring stack on Proxmox, configuring agents across VLANs, building dashboards that actually tell you something, and setting up alerts that wake you up when they matter — not at 3 AM for a transient spike.

Why Zabbix + Grafana?

The Monitoring Landscape

Solution	Cost	Data Ownership	Complexity	Alerting	Dashboards
Datadog	$15-23/host/mo	Cloud (theirs)	Low	Excellent	Excellent
Prometheus + Grafana	Free	Self-hosted	Medium	Good	Excellent
Zabbix + Grafana	Free	Self-hosted	Medium-High	Excellent	Excellent (with Grafana)
Netdata	Free	Self-hosted	Low	Basic	Good (built-in)
Uptime Kuma	Free	Self-hosted	Low	Basic	Basic

Why Not Just Prometheus?

Prometheus is the darling of the cloud-native world, and for good reason. But for homelab monitoring, Zabbix has advantages:

Agent-based collection works across VLANs — Prometheus pull-based scraping struggles with firewall rules between VLANs. Zabbix agents push data to the server (or use active checks), making firewall rules simpler.
Auto-discovery — Zabbix can discover hosts, interfaces, and services automatically. With Prometheus, you're writing prometheus.yml targets by hand.
Built-in templates — Zabbix has 400+ out-of-the-box templates for everything from Linux to pfSense to Proxmox to SNMP devices. Prometheus requires exporters for everything.
Trigger logic — Zabbix triggers support expressions like "average of last 5 minutes > threshold AND last value > threshold". Prometheus alerting rules are powerful but harder to compose.
Grafana integration — Zabbix data in Grafana gives you the best of both: Zabbix collection + Grafana visualization.

Where Grafana Fits

Zabbix has its own dashboards, but they look like 2005. Grafana is the visualization layer:

Beautiful, customizable dashboards
Unified view across multiple data sources
Annotation layers (deploy events, maintenance windows)
Alerting with deduplication and routing
Mobile-responsive (check your homelab from your phone)

Architecture

┌────────────────────────────────────────────────────────────────┐
│                    Monitoring Architecture                       │
│                                                                  │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────────┐  │
│  │ Proxmox  │   │ pfSense  │   │ Docker   │   │ IoT Devices  │  │
│  │ Agent    │   │ Agent    │   │ Agent    │   │ SNMP         │  │
│  │ (VLAN20) │   │ (VLAN10) │   │ (VLAN20) │   │ (VLAN30)    │  │
│  └────┬─────┘   └────┬─────┘   └────┬─────┘   └──────┬───────┘  │
│       │              │              │                 │          │
│       └──────────────┴──────┬───────┴─────────────────┘          │
│                             │                                     │
│                    ┌────────▼────────┐                            │
│                    │  Zabbix Server  │                            │
│                    │  (VLAN 20)      │                            │
│                    │  - Collection  │                            │
│                    │  - Alerting    │                            │
│                    │  - Triggers    │                            │
│                    └────────┬──────┘                            │
│                             │                                     │
│                    ┌────────▼────────┐                            │
│                    │    Grafana      │                            │
│                    │  (VLAN 20)      │                            │
│                    │  - Dashboards   │                            │
│                    │  - Visualization│                            │
│                    │  - Alert UI     │                            │
│                    └─────────────────┘                            │
│                                                                  │
│  Alert Channels: Telegram, Email, Webhook                       │
└────────────────────────────────────────────────────────────────┘

Network Considerations (VLAN-Aware)

Following our zero-trust VLAN architecture from the previous article:

Zabbix Server lives on VLAN 20 (Servers)
Zabbix Agents on VLAN 10 (Management) push data to server via active checks
SNMP polling from Zabbix to VLAN 30 (IoT) requires explicit firewall allow rules
Grafana on VLAN 20, with an optional reverse proxy on VLAN 50 (Services) if you want external access

Firewall rules needed:

# Allow Zabbix agents → Zabbix server (active checks)
ALLOW  VLAN10 → VLAN20  TCP 10051  — "Management agents → Zabbix"
ALLOW  VLAN20 → VLAN20  TCP 10051  — "Server agents → Zabbix"

# Allow Zabbix server → IoT (SNMP polling, if desired)
ALLOW  VLAN20 → VLAN30  UDP 161    — "Zabbix SNMP poll IoT"

# Allow Grafana access from Management VLAN
ALLOW  VLAN10 → VLAN20  TCP 3000   — "MGMT → Grafana dashboard"

Deployment on Proxmox

Step 1: Create the Zabbix Server LXC

Proxmox LXC containers are perfect for monitoring — low overhead, fast startup, full Linux userspace.

# Download Debian 12 LXC template
pveam download local debian-12-standard_12.2-1_amd64.tar.zst

# Create container
pct create 200 local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst \
  --hostname zabbix \
  --memory 4096 \
  --swap 2048 \
  --cores 2 \
  --storage local-lvm \
  --rootfs local-lvm:32 \
  --net0 name=eth0,bridge=vmbr0.20,ip=10.0.20.10/24,gw=10.0.20.1 \
  --unprivileged 1 \
  --onboot 1 \
  --start 1

Why LXC instead of VM: Zabbix doesn't need its own kernel. LXC gives you 95% of a VM's isolation with 5% of the overhead. Your monitoring shouldn't be the heaviest thing on the host.

Step 2: Install Zabbix Server + PostgreSQL

# Enter the container
pct enter 200

# Install PostgreSQL
apt update && apt install -y postgresql postgresql-contrib

# Create Zabbix database
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix -E Unicode -T template0 zabbix

# Add Zabbix repository
wget https://repo.zabbix.com/zabbix/7.2/debian/pool/main/z/zabbix-release/zabbix-release_7.2-1+debian12_all.deb
dpkg -i zabbix-release_7.2-1+debian12_all.deb
apt update

# Install Zabbix server, frontend, and agent
apt install -y zabbix-server-pgsql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent2

# Import initial schema
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
  sudo -u zabbix psql zabbix

# Configure Zabbix server
cat > /etc/zabbix/zabbix_server.conf << 'EOF'
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=YOUR_POSTGRES_PASSWORD_HERE
LogFile=/var/log/zabbix/zabbix_server.log
LogFileSize=50
DebugLevel=3
StartPollers=5
StartPollersUnreachable=2
StartTrappers=5
StartDiscoverers=2
StartHTTPPollers=2
CacheSize=64M
HistoryCacheSize=32M
TrendCacheSize=8M
ValueCacheSize=32M
Timeout=10
EOF

# Start services
systemctl restart zabbix-server zabbix-agent2 apache2
systemctl enable zabbix-server zabbix-agent2 apache2

Step 3: Install Grafana

# Add Grafana repository
apt install -y apt-transport-https software-properties-common
wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key

echo "deb [signed-by=/usr/share/keyrings/grafana.key] https://apt.grafana.com stable main" | \
  tee /etc/apt/sources.list.d/grafana.list

apt update && apt install -y grafana

# Configure Grafana
cat > /etc/grafana/grafana.ini << 'EOF'
[server]
http_addr = 10.0.20.11
http_port = 3000
domain = grafana.commsnet.local

[security]
admin_user = admin
admin_password = CHANGE_ME_IMMEDIATELY

[database]
type = sqlite3

[analytics]
reporting_enabled = false
check_for_updates = false

[auth.anonymous]
enabled = false
EOF

systemctl restart grafana-server
systemctl enable grafana-server

Step 4: Connect Grafana to Zabbix

Install the Zabbix data source plugin in Grafana:

grafana-cli plugins install alexanderzobnin-zabbix-app
systemctl restart grafana-server

In Grafana UI (Configuration → Plugins → Zabbix):

Enable the Zabbix app plugin
Add data source:
- Name: Zabbix
- Type: Zabbix API
- URL: http://10.0.20.10/zabbix/api_jsonrpc.php
- Username: Admin
- Password: Your Zabbix admin password
- Trends: Enable (use trends for long-term graphs)

Configuring Zabbix Agents

Agent on Proxmox Host

# On the Proxmox host itself
apt install -y zabbix-agent2

cat > /etc/zabbix/zabbix_agent2.conf << 'EOF'
Server=10.0.20.10
ServerActive=10.0.20.10
Hostname=proxmox-host
LogFile=/var/log/zabbix/zabbix_agent2.log
DebugLevel=3

# Custom metrics for Proxmox
UserParameter=pve.cluster.status,/usr/bin/pvesh get /cluster/status --output json 2>/dev/null | grep -c '"online"'
UserParameter=pve.vm.count,/usr/bin/qm list 2>/dev/null | wc -l
UserParameter=pve.ct.count,/usr/bin/pct list 2>/dev/null | wc -l
UserParameter=pve.storage.used[*],/usr/bin/pvesm status --storage $1 --output json 2>/dev/null | grep -o '"used":[0-9]*' | cut -d: -f2
UserParameter=pve.storage.total[*],/usr/bin/pvesm status --storage $1 --output json 2>/dev/null | grep -o '"total":[0-9]*' | cut -d: -f2
EOF

systemctl restart zabbix-agent2
systemctl enable zabbix-agent2

Agent on pfSense

pfSense has a Zabbix agent package:

System → Package Manager → Available Packages → pfSense-zabbix-agent

Configuration:

Zabbix Server IP: 10.0.20.10
Zabbix Server Port: 10051
Hostname: pfsense
Enable active checks: Yes

pfSense-specific items to monitor:

CARP status (if using HA)
Gateway quality (packet loss, latency, jitter)
State table utilization
DHCP lease counts per VLAN
Firewall rule denials per VLAN (from our zero-trust setup)
OpenVPN/WireGuard client counts
Interface traffic per VLAN

Agent on Docker Hosts

# docker-compose.yml for Zabbix agent
version: '3.8'
services:
  zabbix-agent:
    image: zabbix/zabbix-agent2:latest
    container_name: zabbix-agent
    restart: unless-stopped
    environment:
      - ZBX_SERVER_HOST=10.0.20.10
      - ZBX_HOSTNAME=docker-host-01
      - ZBX_ACTIVE_ALLOW=true
    volumes:
      - /:/hostfs:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
    network_mode: host
    privileged: true

Docker-specific metrics:

# Additional UserParameters for Docker
UserParameter=docker.container.count,/usr/bin/docker ps -q | wc -l
UserParameter=docker.container.running,/usr/bin/docker ps --filter status=running -q | wc -l
UserParameter=docker.image.count,/usr/bin/docker images -q | wc -l
UserParameter=docker.volume.count,/usr/bin/docker volume ls -q | wc -l

Zabbix Host Configuration

Adding Hosts in Zabbix UI

Configuration → Hosts → Create Host:

Host	Templates	Groups	Interface	Proxy
proxmox-host	Linux by Zabbix agent, Proxmox VE by Zabbix	Servers	Agent: 10.0.20.5:10051	None
pfsense	pfSense by Zabbix	Network	Agent: 10.0.10.1:10051	None
docker-host-01	Linux by Zabbix agent, Docker by Zabbix	Servers	Agent: 10.0.20.20:10051	None
unifi-switch	SNMP Generic, Ubiquiti Switch	Network	SNMP: 10.0.10.2:161	None
cisco-2960	SNMP Generic, Cisco Switch	Network	SNMP: 10.0.10.3:161	None

Template Customization

Zabbix templates are good out of the box but need tuning for homelab scale:

Linux by Zabbix agent — Adjust trigger thresholds:

Trigger	Default	Homelab Adjusted	Reason
CPU load > 5min per core	5 per core	80% sustained 10min	Homelab CPUs burst, don't alert on spikes
Available memory < 20%	20%	10%	Homelab hosts use more memory; 20% is too sensitive
Disk space < 20%	20%	10%	Small disks fill faster; 20% on 100GB = 20GB free
Swap usage > 50%	50%	80%	Some swap usage is normal in homelabs

pfSense template — Add custom items:

# Custom pfSense items via UserParameter
UserParameter=pfsense.gateway.loss[*],/usr/local/bin/php -r "require '/etc/inc/util.inc'; echo get_gateway_loss('$1');"
UserParameter=pfsense.dhcp.leases[*],/usr/local/bin/php -r "require '/etc/inc/util.inc'; echo count_dhcp_leases('$1');"
UserParameter=pfsense.firmware.version,/usr/local/bin/php -r "require '/etc/inc/util.inc'; echo get_firmware_version();"

Building Grafana Dashboards

Dashboard 1: Infrastructure Overview

The single pane of glass for your entire homelab:

Panels:

Row: "Host Status" ────────────────────────────────
  [Stat]  Hosts Up          zabbix: hosts.count{status=0}
  [Stat]  Hosts Down        zabbix: hosts.count{status=1}
  [Stat]  Active Triggers   zabbix: triggers.count{value=1}

Row: "System Health" ──────────────────────────────
  [Time Series]  CPU Usage per Host    zabbix: system.cpu.util{host=*}
  [Gauge]        Memory % per Host     zabbix: vm.memory.util{host=*}
  [Time Series]  Disk I/O per Host     zabbix: vfs.dev.read{host=*}, vfs.dev.write{host=*}

Row: "Network" ─────────────────────────────────────
  [Time Series]  Traffic per VLAN      zabbix: net.if.in{host=pfsense,if=VLAN*}
  [Stat]         Firewall Denials/h    zabbix: pf.deny.count
  [Table]        Top Talkers          zabbix: net.if.total{host=*}

Row: "Storage" ─────────────────────────────────────
  [Gauge]   Proxmox Storage Used  zabbix: pve.storage.used[*]
  [Bar]     Docker Disk Usage     zabbix: vfs.fs.size{host=docker*,fs=/var/lib/docker}

Dashboard 2: pfSense Network Security

Dedicated to monitoring the zero-trust firewall:

Panels:

Row: "Firewall Activity" ──────────────────────────
  [Time Series]  Denials per VLAN/hour    zabbix: pf.deny{vlan=*}
  [Table]        Top Denied Sources       zabbix: pf.deny.src{groupby=src_ip}
  [Time Series]  Allow vs Deny Ratio      zabbix: pf.allow / pf.deny

Row: "Gateway Quality" ────────────────────────────
  [Time Series]  Packet Loss %             zabbix: pfsense.gateway.loss[*]
  [Time Series]  Latency ms               zabbix: pfsense.gateway.latency[*]
  [Stat]         Gateway Status            zabbix: pfsense.gateway.status

Row: "DHCP Leases" ────────────────────────────────
  [Stat]     MGMT Leases       zabbix: pfsense.dhcp.leases[MGMT]
  [Stat]     Server Leases     zabbix: pfsense.dhcp.leases[SERVERS]
  [Stat]     IoT Leases        zabbix: pfsense.dhcp.leases[IOT]
  [Stat]     Guest Leases      zabbix: pfsense.dhcp.leases[GUEST]
  [Table]    New Leases (24h)   zabbix: pfsense.dhcp.new_leases

Dashboard 3: Proxmox Virtualization

Panels:

Row: "Cluster Health" ─────────────────────────────
  [Stat]    Cluster Status          zabbix: pve.cluster.status
  [Stat]    VMs Running             zabbix: pve.vm.count
  [Stat]    CTs Running             zabbix: pve.ct.count

Row: "Resource Usage" ─────────────────────────────
  [Gauge]    CPU Total              zabbix: system.cpu.util{host=proxmox*}
  [Gauge]    Memory Total           zabbix: vm.memory.util{host=proxmox*}
  [Bar]      Storage per Pool      zabbix: pve.storage.used[*] / pve.storage.total[*]

Row: "VM/CT Details" ─────────────────────────────
  [Table]    All VMs + CPU/Mem/Disk  zabbix: pve.vm.{cpu,mem,disk}[*]
  [Table]    All CTs + CPU/Mem/Disk  zabbix: pve.ct.{cpu,mem,disk}[*]

Grafana Variables for Reusable Dashboards

Set up template variables so dashboards work across all hosts:

Variable: $host
  Type: Query
  Query: zabbix: hosts*
  Multi-value: Yes
  Include All: Yes

Variable: $vlan
  Type: Custom
  Values: MGMT, SERVERS, IOT, GUEST, SERVICES

Variable: $interval
  Type: Interval
  Values: 1m,5m,10m,30m,1h,6h,1d
  Auto: Yes

Alerting: Wake Me When It Matters

Zabbix Triggers → Grafana Alerts

The alerting pipeline:

Zabbix Agent → Zabbix Server (trigger fires) → Grafana Alert Rule → Notification Policy → Channel

Critical Alerts (Wake Me Up)

Alert	Trigger Expression	Severity	Channel
Host down	`nodata(5m)`	Disaster	Telegram + Email
Disk > 90%	`last(/{HOST}/vfs.fs.size[pct])>90`	High	Telegram
pfSense down	`nodata(3m)` on pfSense	Disaster	Telegram + Email
Gateway packet loss > 10%	`last(/{HOST}/pfsense.gateway.loss)>10`	High	Telegram
Zabbix server down	Internal zabbix trigger	Disaster	Email (fallback)

Warning Alerts (Check in Morning)

Alert	Trigger Expression	Severity	Channel
CPU > 80% sustained	`avg(10m)>80`	Warning	Dashboard only
Memory > 85%	`last(/{HOST}/vm.memory.util)>85`	Warning	Dashboard only
Certificate expiring < 14 days	`last(/{HOST}/cert.days_left)<14`	Warning	Email digest
Docker container stopped	`last(/{HOST}/docker.container.running)<expected`	Warning	Dashboard only

Information Alerts (Weekly Digest)

Alert	Trigger Expression	Severity	Channel
New DHCP lease on MGMT VLAN	Event log match	Info	Weekly digest
Firmware update available	`diff(/{HOST}/pfsense.firmware.version)`	Info	Weekly digest
Storage growth rate > 5%/week	`trend(7d)>5`	Info	Weekly digest

Telegram Alert Integration

Grafana supports Telegram natively. Create a bot via @BotFather:

Grafana → Alerting → Contact points → Add Contact Point
  Type: Telegram
  BOT API Token: YOUR_BOT_TOKEN
  Chat ID: YOUR_CHAT_ID

Notification Policy:
  Group by: alertname, severity
  Group wait: 30s
  Group interval: 5m
  Repeat interval: 4h

  Route: severity=disaster → Telegram immediately
  Route: severity=high → Telegram, 5m repeat
  Route: severity=warning → Email digest, 1d repeat
  Route: severity=info → Weekly email

Performance Tuning

Zabbix Housekeeper

Zabbix's built-in housekeeper is notoriously slow with PostgreSQL. Replace it with partitioned tables:

-- Connect to Zabbix database
sudo -u postgres psql zabbix

-- Enable partitioning extension
CREATE EXTENSION IF NOT EXISTS timescaledb;

-- Convert history tables to hypertables (TimescaleDB)
SELECT create_hypertable('history', 'clock', chunk_time_interval => 86400);
SELECT create_hypertable('history_uint', 'clock', chunk_time_interval => 86400);
SELECT create_hypertable('history_str', 'clock', chunk_time_interval => 86400);
SELECT create_hypertable('trends', 'clock', chunk_time_interval => 2592000);
SELECT create_hypertable('trends_uint', 'clock', chunk_time_interval => 2592000);

Disable Zabbix internal housekeeper (TimescaleDB handles it now):

# /etc/zabbix/zabbix_server.conf
DisableHousekeeping=1

Set retention policies:

-- Keep raw history for 14 days
SELECT add_retention_policy('history', INTERVAL '14 days');
SELECT add_retention_policy('history_uint', INTERVAL '14 days');
SELECT add_retention_policy('history_str', INTERVAL '14 days');

-- Keep trends for 2 years
SELECT add_retention_policy('trends', INTERVAL '2 years');
SELECT add_retention_policy('trends_uint', INTERVAL '2 years');

Database Size Estimates

Monitoring	Items	History/Day	14-Day History	2-Year Trends	Total DB Size
5 hosts	~500	~15 MB	~210 MB	~200 MB	~500 MB
10 hosts	~1000	~30 MB	~420 MB	~400 MB	~1 GB
20 hosts	~2000	~60 MB	~840 MB	~800 MB	~2 GB

A homelab with 10-20 hosts will use 1-2 GB of storage over 2 years. That's nothing.

Backup Strategy

Your monitoring data is valuable — it contains your baseline, your history, your incident timeline. Back it up.

Zabbix Database Backup

#!/bin/bash
# zabbix-backup.sh — Daily Zabbix database backup
BACKUP_DIR="/mnt/nas/backups/zabbix"
DATE=$(date +%Y-%m-%d)
RETENTION_DAYS=30

# PostgreSQL dump
sudo -u postgres pg_dump zabbix | gzip > "${BACKUP_DIR}/zabbix_${DATE}.sql.gz"

# Zabbix config
tar czf "${BACKUP_DIR}/zabbix_config_${DATE}.tar.gz" \
  /etc/zabbix/ /etc/grafana/

# Cleanup old backups
find "${BACKUP_DIR}" -name "zabbix_*.sql.gz" -mtime +${RETENTION_DAYS} -delete
find "${BACKUP_DIR}" -name "zabbix_config_*.tar.gz" -mtime +${RETENTION_DAYS} -delete

echo "Backup complete: ${DATE}"

Grafana Dashboard Export

Grafana dashboards should be version-controlled:

#!/bin/bash
# grafana-export.sh — Export all dashboards as JSON
GRAFANA_URL="http://10.0.20.11:3000"
API_KEY="YOUR_GRAFANA_API_KEY"
OUTPUT_DIR="/home/commstech/grafana-dashboards"

# Get all dashboard UIDs
DASHBOARDS=$(curl -s -H "Authorization: Bearer ${API_KEY}" \
  "${GRAFANA_URL}/api/search?type=dash-db" | \
  jq -r '.[] | .uid')

# Export each dashboard
for UID in ${DASHBOARDS}; do
  curl -s -H "Authorization: Bearer ${API_KEY}" \
    "${GRAFANA_URL}/api/dashboards/uid/${UID}" | \
    jq '.dashboard' > "${OUTPUT_DIR}/${UID}.json"
done

echo "Exported $(echo ${DASHBOARDS} | wc -w) dashboards"

Commit these to git. Your dashboards are code.

Cost Summary

Item	Cost	Notes
Zabbix Server (LXC on Proxmox)	$0	Already have hardware
Grafana (LXC on Proxmox)	$0	Already have hardware
PostgreSQL + TimescaleDB	$0	Open source
Zabbix Agents	$0	Open source
Storage (2 GB over 2 years)	$0	Negligible
Telegram bot for alerts	$0	Free tier
Total Monthly Cost	$0	Self-hosted, zero subscriptions

Compare to Datadog at $15/host/month for 10 hosts = $150/month = $1,800/year. You're saving $1,800/year by self-hosting.

Dashboard Screenshots Description

Since this is a text article, here's what your dashboards should look like:

Infrastructure Overview Dashboard

Top row: Three large stat panels — green "5 Hosts Up", red "0 Hosts Down", orange "2 Active Warnings"
Middle left: Time series graph showing CPU usage for all hosts over last 1 hour, with 80% threshold line
Middle right: Gauge panels showing memory usage per host (color-coded: green < 60%, yellow 60-80%, red > 80%)
Bottom left: Network traffic stacked area chart per VLAN
Bottom right: Storage usage horizontal bar chart per Proxmox pool

pfSense Security Dashboard

Top row: Firewall deny rate time series — should show consistent low rate, any spike is suspicious
Middle: Table of top 10 denied source IPs with last attempt time
Bottom: DHCP lease count per VLAN as small bar charts, with "new in 24h" annotation

Next Steps

With monitoring in place, you can now:

Set up automated remediation — Zabbix can run scripts on alert (restart a service, clear a cache)
Add log monitoring — Forward syslog from pfSense, Proxmox, and Docker to Zabbix
Implement capacity planning — Use trend data to predict when you'll run out of disk/CPU/memory
Add synthetic monitoring — Zabbix web scenarios to check your services are actually responding
Integrate with Home Assistant — Send Zabbix alerts to your home automation for visual/audio alerts

Key Takeaways

Self-hosted monitoring costs nothing but electricity — Zabbix + Grafana is enterprise-grade, free, and yours
Zabbix for collection, Grafana for visualization — each tool does what it does best
Active checks work across VLANs — agents push data, no need to open inbound ports
Tune your triggers for homelab scale — enterprise defaults are too sensitive for home infrastructure
TimescaleDB partitioning is essential — the built-in housekeeper will kill your database performance
Alert on what matters, ignore what doesn't — disaster = wake me, warning = check in morning, info = weekly digest
Version-control your dashboards — they're infrastructure code, not click-and-hope
Back up your monitoring data — it's your operational history, and losing it means losing your baselines

CommsNet — Building infrastructure that respects your privacy and your intelligence.

Follow on Medium and Dev.to for more homelab, networking, and self-hosting content.

Zero-Trust Homelab: Network Segmentation with VLANs and pfSense

Luna Commsnet — Mon, 22 Jun 2026 15:51:19 +0000

Zero-Trust Homelab: Network Segmentation with VLANs and pfSense

Published: June 15, 2026 | CommsNet

If everything on your network can reach everything else, you don't have a network — you have a single point of failure the size of your entire infrastructure. One compromised IoT lightbulb becomes a pivot to your NAS. One breached container becomes a foothold on your management VLAN. In a flat network, trust is binary: you're either in, or you're out.

Zero-trust networking changes the assumption. Nothing is trusted by default. Every segment, every device, every flow must prove it belongs. And the mechanism that enforces this at the homelab scale isn't some expensive SDN controller — it's VLANs on a managed switch, enforced by pfSense firewall rules.

In this article, I'll walk through designing and implementing a zero-trust network segmentation strategy using IEEE 802.1Q VLANs, a managed switch, and pfSense as the inter-VLAN router and policy enforcement point. By the end, your IoT devices won't be able to touch your servers, your guest WiFi will be isolated at L2, and your management interfaces will require explicit allow rules.

Why Zero-Trust for a Homelab?

The Flat Network Problem

Most homelabs start as flat networks — one /24, everything plugged into one switch, maybe a consumer router doing NAT. It works until it doesn't:

Attack Vector	Flat Network Impact	Segmented Network Impact
Compromised IoT device	Lateral movement to NAS, servers	Contained to IoT VLAN, blocked at firewall
Malware on guest laptop	Access to all L2 hosts	Isolated to guest VLAN, no cross-VLAN routing
Exposed service exploit	Direct path to management interfaces	Must traverse firewall rules between VLANs
DNS poisoning on one host	Affects entire broadcast domain	Limited to single VLAN scope

Zero-Trust Principles (Adapted for Homelab)

Enterprise zero-trust frameworks (NIST SP 800-207, Forrester ZTX) assume things homelabbers don't have — identity providers, microsegmentation platforms, continuous verification. But the core principles translate:

Never trust, always verify — Every inter-VLAN flow is denied by default, explicitly allowed
Least privilege access — VLANs get only the routing rules they need
Assume breach — Design so that compromising one VLAN doesn't compromise others
Verify explicitly — pfSense rules are the policy; logging proves enforcement

Network Design

VLAN Architecture

Here's the segmentation model I use. It's designed around the principle of isolation by trust level:

┌─────────────────────────────────────────────────────────┐
│                    VLAN Architecture                      │
│                                                          │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌─────────┐ │
│  │  VLAN 10  │  │  VLAN 20  │  │  VLAN 30  │  │ VLAN 40 │ │
│  │Management│  │  Servers  │  │   IoT     │  │  Guest  │ │
│  │10.0.10/24│  │10.0.20/24│  │10.0.30/24│  │10.0.40 │ │
│  │ TRUST: H │  │ TRUST: H │  │ TRUST: L │  │TRUST: N│ │
│  └─────┬────┘  └─────┬────┘  └─────┬────┘  └────┬────┘ │
│        │              │              │            │       │
│        └──────────────┴──────┬───────┴────────────┘       │
│                              │                            │
│                     ┌────────┴────────┐                   │
│                     │    pfSense      │                   │
│                     │  Inter-VLAN     │                   │
│                     │  Router + FW    │                   │
│                     └────────────────┘                   │
└─────────────────────────────────────────────────────────┘

VLAN Definitions

VLAN ID	Name	Subnet	Trust Level	Purpose
10	Management	10.0.10.0/24	High	pfSense, Proxmox, switches, IPMI/iDRAC
20	Servers	10.0.20.0/24	High	NAS, Docker hosts, application servers
30	IoT	10.0.30.0/24	Low	Smart devices, sensors, cameras
40	Guest	10.0.40.0/24	None	Guest WiFi, untrusted devices
50	Services	10.0.50.0/24	Medium	Exposed services, reverse proxy, tunnel endpoints

Trust Model and Flow Rules

The firewall policy is the heart of zero-trust. Every rule is explicit:

Source VLAN → Destination VLAN → Allowed? → Reason
─────────────────────────────────────────────────────
Management → Any              → ALLOW     → Admin access
Servers    → Management       → DENY      → No reverse access to mgmt
Servers    → Servers          → ALLOW     → Internal service communication
Servers    → IoT              → DENY      → No need to reach IoT
Servers    → Services         → ALLOW     → Publish services
IoT       → Servers           → LIMITED   → Only specific ports (DNS, NTP, specific API)
IoT       → Management       → DENY      → No access to mgmt interfaces
IoT       → Internet         → ALLOW     → Firmware updates, cloud APIs
IoT       → Guest            → DENY      → Mutual isolation
Guest     → Any (internal)   → DENY      → Complete isolation
Guest     → Internet          → ALLOW     → Internet-only access
Services  → Servers           → ALLOW     → Reverse proxy to backends
Services  → Management       → DENY      — No access to mgmt

Hardware Requirements

You don't need enterprise gear. Here's what works at the homelab scale:

Managed Switch (Required)

You need a switch that supports 802.1Q VLAN tagging. Options by budget:

Switch	Ports	VLAN Support	Price (Used)	Notes
Cisco Catalyst 2960	24/48	Full 802.1Q	$30-80	Bulletproof, CLI only
HPE ProCurve 2530	24	Full 802.1Q	$40-100	Web UI + CLI
TP-Link SG108E	8	Basic 802.1Q	$25	Budget starter, limited CLI
Ubiquiti USW-24	24	Full + UI	$100-200	UniFi ecosystem
MikroTik CRS326	24	Full + RouterOS	$80	Powerful but steep learning curve

My pick: Cisco Catalyst 2960G — cheap on eBay, never dies, full VLAN feature set. The CLI is an investment that pays off.

pfSense Hardware

pfSense runs the inter-VLAN routing and firewall. Options:

Option	Cost	Performance	Notes
Netgate SG-1100	$179	~1 Gbps routing	Purpose-built, low power
Protectli Vault	$300+	~2 Gbps routing	Intel NICs, fanless
Repurposed PC + 4 NICs	$50-100	3+ Gbps routing	Best performance/$, more power draw
Proxmox VM + virtio NICs	$0	~10 Gbps routing	Already have Proxmox? Use it

My pick: pfSense as a Proxmox VM with 4 virtio NICs. You already have the hardware.

Implementation: Step by Step

Step 1: Configure VLANs on pfSense

Navigate to Interfaces → Assignments → VLANs and create each VLAN:

Parent Interface: vmx0 (LAN)
VLAN Tag: 10  Priority: 0  Description: Management
VLAN Tag: 20  Priority: 0  Description: Servers  
VLAN Tag: 30  Priority: 0  Description: IoT
VLAN Tag: 40  Priority: 0  Description: Guest
VLAN Tag: 50  Priority: 0  Description: Services

Then assign each VLAN as a new interface:

Interfaces → Assignments:

vmx0.10 → OPT1 → rename to MGMT
vmx0.20 → OPT2 → rename to SERVERS
vmx0.30 → OPT3 → rename to IOT
vmx0.40 → OPT4 → rename to GUEST
vmx0.50 → OPT5 → rename to SERVICES

Enable each interface and set its IPv4 Static address:

MGMT:     10.0.10.1/24
SERVERS:  10.0.20.1/24
IOT:      10.0.30.1/24
GUEST:    10.0.40.1/24
SERVICES: 10.0.50.1/24

Step 2: Configure DHCP for Each VLAN

Services → DHCP Server — enable on each VLAN interface:

Interface	Range	DNS	Gateway	Lease Time
MGMT	10.0.10.100-10.0.10.200	10.0.10.1	10.0.10.1	86400
SERVERS	10.0.20.100-10.0.20.200	10.0.20.1	10.0.20.1	86400
IOT	10.0.30.50-10.0.30.200	1.1.1.1, 9.9.9.9	10.0.30.1	3600
GUEST	10.0.40.50-10.0.40.200	1.1.1.1	10.0.40.1	3600
SERVICES	Static only	10.0.50.1	10.0.50.1	N/A

Key decisions:

IoT/Guest DNS: Point to public resolvers (1.1.1.1), NOT your internal DNS. These VLANs don't need to resolve internal names.
Services: No DHCP — all services get static IPs. If someone plugs into this VLAN, they get nothing.
Short lease times on IoT/Guest: Limits how long a rogue device keeps an address.

Step 3: Configure the Managed Switch

This is where VLAN theory meets physical reality. Each switch port must be configured as access (untagged, single VLAN) or trunk (tagged, multiple VLANs).

Port assignments:

Port 1-8:   Access, VLAN 20 (Servers)      — NAS, Proxmox hosts, Docker servers
Port 9-12:  Access, VLAN 30 (IoT)          — Smart devices, cameras
Port 13-16: Access, VLAN 40 (Guest)        — Guest WiFi AP
Port 17-20: Access, VLAN 10 (Management)   — Management workstations
Port 21-24: Trunk, VLAN ALL (tagged)        — pfSense, Proxmox, WiFi AP

Cisco 2960 example config:

! Trunk port to pfSense
interface GigabitEthernet0/21
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30,40,50
  switchport trunk native vlan 99  ! Never use VLAN 1 as native
  spanning-tree portfast trunk

! Access port for server
interface range GigabitEthernet0/1 - 8
  switchport mode access
  switchport access vlan 20
  spanning-tree portfast

! Access port for IoT
interface range GigabitEthernet0/9 - 12
  switchport mode access
  switchport access vlan 30
  spanning-tree portfast

! Access port for management workstation
interface range GigabitEthernet0/17 - 20
  switchport mode access
  switchport access vlan 10
  spanning-tree portfast

Critical: Set native vlan 99 (or any unused VLAN) on trunk ports. Never use VLAN 1 as the native VLAN — it's the default attack surface on every Cisco switch.

Step 4: Firewall Rules — The Zero-Trust Core

This is where zero-trust is actually enforced. Navigate to Firewall → Rules for each interface.

Management VLAN (Highest Trust)

# MGMT Interface Rules (evaluated top-to-bottom)
#
# 1. Allow MGMT to anything (admin access)
IPv4 *  MGMT net  *  *  *  →  ALLOW  — "MGMT: Allow all outbound"
#
# 2. Allow pfSense DNS from MGMT
IPv4 TCP/UDP  MGMT net  *  MGMT address  53  →  ALLOW  — "MGMT: DNS to pfSense"
#
# 3. Block everything else (implicit, but be explicit)
IPv4 *  *  *  MGMT net  *  →  DENY  — "MGMT: Block all inbound"

Management is simple — full outbound access, no inbound from other VLANs. Admins initiate connections to infrastructure; infrastructure never reaches back.

Servers VLAN

# SERVERS Interface Rules
#
# 1. Allow Servers → Servers (internal communication)
IPv4 *  SERVERS net  *  SERVERS net  *  →  ALLOW  — "SERVERS: Inter-server communication"
#
# 2. Allow Servers → Internet (updates, API calls)
IPv4 *  SERVERS net  *  !RFC1918  *  →  ALLOW  — "SERVERS: Internet access"
#
# 3. Allow Services → Servers (reverse proxy backends)
IPv4 TCP  SERVICES net  *  SERVERS net  80,443,8080  →  ALLOW  — "SERVICES: Reverse proxy to backends"
#
# 4. Block everything else
IPv4 *  *  *  SERVERS net  *  →  DENY  — "SERVERS: Block all other inbound"

Key rule: SERVERS → !RFC1918 allows internet access but blocks access to any other internal VLAN. Servers can reach the internet for updates but cannot reach IoT, Guest, or Management.

IoT VLAN (Low Trust)

# IOT Interface Rules — MOST RESTRICTIVE
#
# 1. Allow IoT → pfSense DNS
IPv4 TCP/UDP  IOT net  *  IOT address  53  →  ALLOW  — "IOT: DNS to pfSense"
#
# 2. Allow IoT → pfSense NTP
IPv4 UDP  IOT net  *  IOT address  123  →  ALLOW  — "IOT: NTP to pfSense"
#
# 3. Allow specific IoT → Server API (e.g., Home Assistant)
IPv4 TCP  IOT net  *  10.0.20.50  8123  →  ALLOW  — "IOT: Home Assistant API"
#
# 4. Allow IoT → Internet (firmware, cloud APIs)
IPv4 *  IOT net  *  !RFC1918  *  →  ALLOW  — "IOT: Internet access"
#
# 5. Block everything else
IPv4 *  *  *  IOT net  *  →  DENY  — "IOT: Block all other inbound"

The IoT rules are surgical — only DNS, NTP, one specific API endpoint, and internet. This is the most important VLAN to lock down because IoT devices are the most likely to be compromised.

Pro tip: Use aliases in pfSense for the IoT API rules. Create an alias IoT_Allowed_Services with the specific server IPs and ports IoT devices need. This makes it easy to add new devices without creating new rules.

Guest VLAN (No Trust)

# GUEST Interface Rules — TOTAL ISOLATION
#
# 1. Allow Guest → Internet only
IPv4 *  GUEST net  *  !RFC1918  *  →  ALLOW  — "GUEST: Internet only"
#
# 2. Allow Guest → pfSense DNS (DHCP-assigned)
IPv4 TCP/UDP  GUEST net  *  GUEST address  53  →  ALLOW  — "GUEST: DNS"
#
# 3. Block everything else
IPv4 *  *  *  GUEST net  *  →  DENY  — "GUEST: Complete isolation"

Guests get internet. Nothing else. This is the simplest and most important rule set.

Services VLAN (Exposed Services)

# SERVICES Interface Rules
#
# 1. Allow Services → Servers (reverse proxy backends)
IPv4 TCP  SERVICES net  *  SERVERS net  80,443,8080,8123  →  ALLOW  — "SERVICES: Proxy to backends"
#
# 2. Allow Services → Internet (cert renewal, API calls)
IPv4 *  SERVICES net  *  !RFC1918  *  →  ALLOW  — "SERVICES: Internet access"
#
# 3. Block everything else
IPv4 *  *  *  SERVICES net  *  →  DENY  — "SERVICES: Block all other inbound"

Services VLAN is the DMZ equivalent. It can reach backends on specific ports and the internet for Let's Encrypt/certbot renewals. It cannot reach management, IoT, or guest.

Advanced: pfSense Aliases for Zero-Trust Maintenance

One of the most underused features in pfSense is aliases — named groups of networks, hosts, or ports that make firewall rules readable and maintainable.

Firewall → Aliases:

Name: MGMT_Net        Type: Host(s)    Value: 10.0.10.0/24
Name: SERVERS_Net     Type: Host(s)    Value: 10.0.20.0/24
Name: IOT_Net         Type: Host(s)    Value: 10.0.30.0/24
Name: GUEST_Net       Type: Host(s)    Value: 10.0.40.0/24
Name: SERVICES_Net    Type: Host(s)    Value: 10.0.50.0/24
Name: RFC1918         Type: Network   Value: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Name: IoT_API_Targets Type: Host(s)    Value: 10.0.20.50  (Home Assistant)
Name: Web_Ports       Type: Port(s)    Value: 80, 443, 8080
Name: IoT_Allowed     Type: Port(s)    Value: 8123, 1883, 5353

Now your rules use human-readable names:

DENY  IOT_Net    →  RFC1918       —  *        —  "IOT: Block internal access"
ALLOW IOT_Net    →  IoT_API_Targets → IoT_Allowed —  "IOT: Allowed services only"

When you add a new IoT device that needs to reach a different service, you update the alias — not the rule. This prevents rule sprawl, which is the #1 way zero-trust degrades over time.

Verification: Proving Your Segmentation Works

Setting up rules isn't enough. You need to verify they work. Here's how:

Test 1: IoT Cannot Reach Management

From an IoT device (or a laptop plugged into an IoT port):

# Should FAIL — blocked by firewall
nmap -p 22 10.0.10.1    # pfSense SSH
nmap -p 443 10.0.10.1   # pfSense WebUI
nmap -p 8006 10.0.10.5  # Proxmox WebUI

# Should SUCCEED — allowed
ping 1.1.1.1            # Internet
dig @10.0.30.1 example.com  # DNS

Test 2: Guest Cannot Reach Any Internal Host

From a guest device:

# All should FAIL
ping 10.0.10.1    # Management
ping 10.0.20.1    # Servers
ping 10.0.30.1    # IoT
nmap 10.0.20.0/24 # Scan entire server VLAN

# Should SUCCEED
ping 1.1.1.1      # Internet

Test 3: Servers Cannot Reach Management

From a server:

# Should FAIL
ssh admin@10.0.10.1     # pfSense
curl https://10.0.10.5:8006  # Proxmox

# Should SUCCEED
ping 10.0.20.1          # Servers gateway
curl https://example.com # Internet

Test 4: pfSense Firewall Logs

Status → System Logs → Firewall:

Watch for denied packets between VLANs. If you see unexpected allowed traffic, your rules are wrong. If you see denied traffic that should be allowed, check your alias definitions.

Pro tip: Enable Log packets that are handled by this rule on every DENY rule. This gives you a complete audit trail of every attempted cross-VLAN connection.

WiFi Considerations

If you're running WiFi (and you should for IoT/mobile), the AP must support multiple SSIDs mapped to VLANs.

UniFi AP VLAN Configuration

SSID: "CommsNet-Home"     → VLAN 20 (Servers/Trusted devices)
SSID: "CommsNet-IoT"      → VLAN 30 (IoT only)
SSID: "CommsNet-Guest"    → VLAN 40 (Guest, rate-limited)

Each SSID gets its own DHCP scope from pfSense, its own firewall rules, and complete L2 isolation. The AP tags frames with the appropriate VLAN ID; pfSense routes and enforces policy.

WiFi-Specific Firewall Additions

# Rate limit Guest WiFi
IPv4 *  GUEST net  *  *  *  →  ALLOW  —  "GUEST: Rate limited"
  ↑ Limit: 10 Mbps down, 5 Mbps up per client
  ↑ Connection limit: 100 concurrent per /32

pfSense traffic shaping (limiter queues) can enforce per-client bandwidth caps on guest and IoT VLANs. This prevents one guest device from consuming your entire upstream.

Monitoring and Alerting

Zero-trust without monitoring is just wishful thinking. You need to know when segmentation fails.

pfSense Integration with Zabbix/Grafana

Install the pfSense Zabbix Agent package:

Package Manager → Available Packages → pfSense-zabbix-agent

Monitor these key metrics:

Metric	What It Tells You	Alert Threshold
Firewall deny rate	How many cross-VLAN attempts blocked	Sudden spike = scanning/recon
Interface traffic per VLAN	Normal traffic baseline	IoT VLAN talking to server VLAN = breach
DHCP lease count per VLAN	Device count per segment	New device on Management VLAN = investigate
State table utilization	Active connections	>80% = possible flood or compromised host
pfSense CPU/memory	Router health	>80% sustained = capacity issue

Suricata IDS on pfSense

Enable Suricata on each VLAN interface for deep packet inspection:

Services → Suricata → Interfaces → Add
  Interface: VLAN_30 (IoT)
  Mode: IPS (Inline Prevention)
  Block offenders: Yes
  Alert only on new threats: Yes

Suricata on the IoT VLAN catches:

IoT devices phoning home to unexpected IPs
Malware C2 beacon patterns
Known exploit signatures targeting IoT firmware

Common Mistakes and Fixes

Mistake 1: Forgetting to Disable VLAN 1

VLAN 1 is the default on every switch. Every port is in it. If you don't explicitly disable it, you have a shadow flat network running alongside your segmented one.

Fix: Create a VLAN 99 as the native VLAN on all trunk ports and move all unused ports to a dead VLAN.

! Move all unused ports to dead VLAN
interface range GigabitEthernet0/22 - 24
  switchport mode access
  switchport access vlan 99
  shutdown

Mistake 2: Over-Allowing on Trunk Ports

switchport trunk allowed vlan all is lazy and dangerous. Only allow the VLANs that need to traverse each trunk.

Fix:

interface GigabitEthernet0/21
  switchport trunk allowed vlan 10,20,30,40,50
  ! NOT: switchport trunk allowed vlan all

Mistake 3: pfSense Floating Rules Bypassing Interface Rules

Floating rules in pfSense apply globally and can bypass per-interface rules. If you use floating rules, make sure they don't accidentally allow cross-VLAN traffic.

Fix: Avoid floating rules for inter-VLAN policies. Use interface-specific rules. Use floating rules only for traffic shaping or QoS.

Mistake 4: No Logging on Deny Rules

If you don't log denied packets, you have no way to detect reconnaissance, failed intrusion attempts, or misconfigured devices.

Fix: Enable logging on every DENY rule. Set up a syslog server to aggregate and analyze firewall logs.

Cost Summary

Item	Cost	Notes
Cisco 2960G (used)	$50	eBay, 24-port managed
pfSense (VM on Proxmox)	$0	Already have hardware
Cat6 patch cables	$15	Monoprice 10-pack
UniFi AP AC Lite (used)	$40	Multi-SSID VLAN support
Total	$105	One-time cost

No subscriptions. No per-device licensing. No cloud dependencies. This is infrastructure you own, understand, and control.

What's Next?

This article covers L2/L3 segmentation. In the next article in this series, we'll add:

WireGuard VPN for remote management VLAN access (never expose pfSense to the internet)
Cilium eBPF policies for micro-segmentation within the server VLAN (container-to-container)
pfSense CARP for high-availability firewall failover
Automated compliance checks — scripts that verify your firewall rules match your zero-trust policy

Key Takeaways

Flat networks are the enemy — one compromised device becomes a pivot to everything
VLANs + pfSense rules = zero-trust at homelab scale — no enterprise license required
Deny by default, allow by exception — every inter-VLAN flow must be justified
IoT is your biggest risk — isolate it to DNS + NTP + one API endpoint
Guest gets internet only — no exceptions, no "just this once"
Log every deny — visibility is how you prove zero-trust works
Aliases keep rules maintainable — rule sprawl is how zero-trust dies
Test your segmentation — if you haven't verified it, it's probably broken

CommsNet — Building infrastructure that respects your privacy and your intelligence.

Follow on Medium and Dev.to for more homelab, networking, and self-hosting content.

From ISP Lock-in to Control: Self-Hosting Nextcloud/Home Assistant Behind Cloudflare Tunnels

Luna Commsnet — Mon, 22 Jun 2026 15:51:00 +0000

From ISP Lock-in to Control: Self-Hosting Nextcloud/Supervised Behind Cloudflare Tunnels

Published: May 27, 2026 | CommsNet

Your ISP gave you a CGNAT address, blocked port 25, and thinks "advanced router settings" means changing the WiFi password. You're paying for a connection you don't control, and every cloud subscription is another monthly tax on data you should own.

This article is the exit strategy. We're going to self-host Nextcloud for file sync, calendar, and contacts — and Home Assistant Supervised for home automation — all behind Cloudflare Tunnels so nothing is exposed directly to the internet. No port forwarding, no DDNS, no static IP required. Your ISP doesn't even need to know you're running services.

The Problem with ISP Defaults

What ISPs Do	Why It Matters
CGNAT (Carrier-Grade NAT)	You can't receive inbound connections — no port forwarding possible
Blocked ports (25, 80, 443)	Even with a public IP, common services are blocked
Dynamic IP addresses	DDNS works around this, but it's fragile
Residential TOS restrictions	"No servers" clauses in fine print
No IPv6 or broken IPv6	Dual-stack isn't optional anymore
Asymmetric bandwidth	Upload is 10% of download — your "cloud" uploads crawl

The answer isn't a VPS that adds another monthly bill and another provider who can suspend you. The answer is Cloudflare Tunnels — outbound-only connections that punch through CGNAT, avoid blocked ports, and give you your own domain with TLS termination.

Architecture

                    ┌─────────────────┐
                    │  Cloudflare Edge  │
                    │  (Anycast CDN)    │
                    └────────┬─────────┘
                             │ HTTPS
                    ┌────────┴─────────┐
                    │ Cloudflare Tunnel  │
                    │ (cloudflared)      │
                    │ ← outbound only → │
                    └────────┬─────────┘
                             │ localhost
              ┌──────────────┼──────────────┐
              │              │              │
        ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
        │ Nextcloud  │ │  Home      │ │  Other     │
        │ :8080      │ │ Assistant  │ │ Services   │
        │            │ │  :8123     │ │  :XXXX     │
        └────────────┘ └───────────┘ └────────────┘
              │              │              │
        ┌─────┴─────────────┴──────────────┴────┐
        │            Docker Network              │
        │         (internal only)                │
        └───────────────────────────────────────┘

Key insight: All connections are outbound from your server to Cloudflare. Your firewall never opens an inbound port. Your ISP never sees a server.

Step 1: Domain and Cloudflare Setup

Prerequisites

A domain name (transfer to Cloudflare Registrar or use any registrar with Cloudflare DNS)
A Cloudflare account (free tier works for tunnels)
Docker and Docker Compose on your server

DNS Configuration

Point your domain's nameservers to Cloudflare, then add A/AAAA records for your services:

nextcloud.commsnet.org    → Proxied (orange cloud) → Tunnel
hass.commsnet.org         → Proxied (orange cloud) → Tunnel
files.commsnet.org        → Proxied (orange cloud) → Tunnel

The "Proxied" toggle is critical — it enables Cloudflare's TLS termination and DDoS protection. Your origin server IP never appears in DNS.

Step 2: Cloudflare Tunnel

Install cloudflared

# Debian/Ubuntu
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
sudo dpkg -i cloudflared.deb

# Or via package manager
sudo cloudflared --version

Authenticate and Create Tunnel

# Authenticate with your Cloudflare account
cloudflared tunnel login

# Create the tunnel
cloudflared tunnel create homelab

# Note the tunnel ID from the output — you'll need it
# Example: TUNNEL_ID=a1b2c3d4-e5f6-7890-abcd-ef1234567890

Configure the Tunnel

Create ~/.cloudflared/config.yml:

tunnel: TUNNEL_ID
credentials-file: /home/youruser/.cloudflared/TUNNEL_ID.json

ingress:
  # Nextcloud
  - hostname: nextcloud.commsnet.org
    service: http://localhost:8080
    originRequest:
      noTLSVerify: true

  # Home Assistant
  - hostname: hass.commsnet.org
    service: http://localhost:8123
    originRequest:
      noTLSVerify: true

  # Catch-all rule (required)
  - service: http_status:404

DNS Records

# Create CNAME records pointing to the tunnel
cloudflared tunnel route dns homelab nextcloud.commsnet.org
cloudflared tunnel route dns homelab hass.commsnet.org

This automatically creates the CNAME records in Cloudflare DNS pointing <subdomain>.commsnet.org to <TUNNEL_ID>.cfargotunnel.com.

Test the Tunnel

cloudflared tunnel run homelab

If everything works, you'll see the tunnel connect and your services will be accessible at their respective hostnames — all over HTTPS, all without opening a single inbound port.

Run as a Service

# Install as systemd service
sudo cloudflared service install

# Enable and start
sudo systemctl enable cloudflared
sudo systemctl start cloudflared

# Check status
sudo systemctl status cloudflared

Step 3: Nextcloud with Docker Compose

Directory Structure

nextcloud/
├── docker-compose.yml
├── .env
├── data/
│   ├── nextcloud/
│   ├── db/
│   └── redis/
└── config/
    ├── nginx/
    │   └── nginx.conf
    └── php/
        └── uploads.ini

docker-compose.yml

version: "3.8"

services:
  nextcloud-db:
    image: postgres:16-alpine
    container_name: nextcloud-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./data/db:/var/lib/postgresql/data
    networks:
      - nextcloud-internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 30s
      timeout: 10s
      retries: 3

  nextcloud-redis:
    image: redis:7-alpine
    container_name: nextcloud-redis
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}
    volumes:
      - ./data/redis:/data
    networks:
      - nextcloud-internal
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 30s
      timeout: 10s
      retries: 3

  nextcloud-app:
    image: nextcloud:30-apache
    container_name: nextcloud-app
    restart: unless-stopped
    depends_on:
      nextcloud-db:
        condition: service_healthy
      nextcloud-redis:
        condition: service_healthy
    environment:
      POSTGRES_HOST: nextcloud-db
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      REDIS_HOST: nextcloud-redis
      REDIS_HOST_PASSWORD: ${REDIS_PASSWORD}
      NEXTCLOUD_ADMIN_USER: ${NEXTCLOUD_ADMIN_USER}
      NEXTCLOUD_ADMIN_PASSWORD: ${NEXTCLOUD_ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: nextcloud.commsnet.org
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://nextcloud.commsnet.org
      SMTP_HOST: ${SMTP_HOST}
      SMTP_PORT: 587
      SMTP_SECURE: tls
      SMTP_NAME: ${SMTP_USER}
      SMTP_PASSWORD: ${SMTP_PASSWORD}
      MAIL_FROM_ADDRESS: nextcloud
      MAIL_DOMAIN: commsnet.org
    volumes:
      - ./data/nextcloud:/var/www/html
      - ./config/php/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
    networks:
      - nextcloud-internal
      - nextcloud-exposed
    healthcheck:
      test: ["CMD-SHELL", "curl -sf http://localhost:80/status.php || exit 1"]
      interval: 60s
      timeout: 15s
      retries: 3

  nextcloud-cron:
    image: nextcloud:30-apache
    container_name: nextcloud-cron
    restart: unless-stopped
    depends_on:
      nextcloud-app:
        condition: service_healthy
    volumes:
      - ./data/nextcloud:/var/www/html
    entrypoint: /cron.sh
    networks:
      - nextcloud-internal

networks:
  nextcloud-internal:
    driver: bridge
    internal: true   # No external access — only app is exposed
  nextcloud-exposed:
    driver: bridge

Environment File

# .env — NEVER commit this to git
POSTGRES_DB=nextcloud
POSTGRES_USER=nextcloud_db
POSTGRES_PASSWORD=<generate-with: openssl rand -hex 32>

REDIS_PASSWORD=<generate-with: openssl rand -hex 32>

NEXTCLOUD_ADMIN_USER=admin
NEXTCLOUD_ADMIN_PASSWORD=<generate-with: openssl rand -hex 32>

SMTP_HOST=smtp.example.com
SMTP_USER=nextcloud@commsnet.org
SMTP_PASSWORD=<your-smtp-password>

PHP Upload Limits

; config/php/uploads.ini
upload_max_filesize = 16G
post_max_size = 16G
max_execution_time = 3600
max_input_time = 3600
memory_limit = 512M

Important: Internal Network Segmentation

Notice the two Docker networks in the compose file:

nextcloud-internal — no external routing. Database and Redis can only be reached by Nextcloud containers.
nextcloud-exposed — the app container sits on this network too, so Cloudflare Tunnel can reach it on localhost:8080.

The database and Redis are never accessible from outside the Docker network. Even if an attacker compromises the tunnel, they can't directly reach PostgreSQL or Redis.

Step 4: Home Assistant Supervised

Why Supervised, Not Home Assistant OS?

Home Assistant OS is the easy path, but it's a black box — you can't install custom add-ons, manage it with Docker Compose, or integrate it with your existing infrastructure. Supervised gives you the same UI and add-on store, but on your terms.

Prerequisites

# Install required packages for Supervised
sudo apt install -y \
  apparmor \
  jq \
  network-manager \
  dbus \
  curl \
  socat \
  avahi-daemon \
  udisks2 \
  libglib2.0-bin

Docker Compose for Home Assistant

version: "3.8"

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    restart: unless-stopped
    environment:
      - TZ=America/Chicago
    volumes:
      - ./config/hass:/config
      - /etc/localtime:/etc/localtime:ro
    network_mode: host  # HA needs host networking for device discovery
    # Health check
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://localhost:8123"]
      interval: 60s
      timeout: 10s
      retries: 5

  # Home Assistant Supervised Installer
  # Run this ONCE to install the supervisor, then remove this service
  hass-supervisor-installer:
    image: homeassistant/amd64-hassio-supervisor:latest
    container_name: hassio_supervisor
    restart: unless-stopped
    privileged: true
    environment:
      - SUPERVISOR_SHARE=/etc/hassio
      - SUPERVISOR_NAME=hassio_supervisor
    volumes:
      - /etc/hassio:/etc/hassio
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/run/dbus:/var/run/dbus
      - /etc/machine-id:/etc/machine-id:ro
    network_mode: host

Alternative: Simpler Home Assistant Container (Non-Supervised)

If you don't need the add-on store, a plain HA container is simpler and more maintainable:

version: "3.8"

services:
  homeassistant:
    container_name: homeassistant
    image: ghcr.io/home-assistant/home-assistant:stable
    restart: unless-stopped
    environment:
      - TZ=America/Chicago
    volumes:
      - ./config/hass:/config
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "8123:8123"
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://localhost:8123"]
      interval: 60s
      timeout: 10s
      retries: 5
    networks:
      - homeassistant

networks:
  homeassistant:
    driver: bridge

Cloudflare Tunnel Configuration for HA

Add to your ~/.cloudflared/config.yml:

  # Home Assistant
  - hostname: hass.commsnet.org
    service: http://homeassistant:8123
    originRequest:
      noTLSVerify: true

Important: Home Assistant requires WebSocket support for real-time updates. Cloudflare Tunnels handle WebSocket proxying automatically — no extra configuration needed.

Step 5: Security Hardening

Nextcloud Security

After first login, configure these in config.php (or via OCC):

<?php
// data/nextcloud/config/config.php additions

'force_ssl' => true,
'default_phone_region' => 'US',
'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => [
    'host' => 'nextcloud-redis',
    'port' => 6379,
    'password' => 'your-redis-password',
],
'maintenance' => false,
'theme' => '',
'loglevel' => 2,
'auth.bruteforce.protection.enabled' => true,
'share_folder' => '/Shared',
'trashbin_retention_obligation' => '30,180',
'activity_expire_days' => 90,
'simpleSignUpLink.shown' => false,
];

Fail2Ban Integration (Optional but Recommended)

If someone tries to brute-force your Nextcloud login, fail2ban will ban their IP at the firewall level:

# /etc/fail2ban/filter.d/nextcloud.conf
[Definition]
groups = nextcloud
failregex = ^.*Login failed.*Remote IP.*<HOST>.*$
            ^.*Bruteforce attempt.*Remote IP.*<HOST>.*$
ignoreregex =

# /etc/fail2ban/jail.d/nextcloud.conf
[nextcloud]
enabled = true
port = 80,443
filter = nextcloud
logpath = /path/to/nextcloud/data/nextcloud.log
maxretry = 5
bantime = 3600
findtime = 600

Note: Cloudflare Tunnels mean all traffic appears from Cloudflare IPs. Fail2ban won't be effective unless you configure the TRUSTED_PROXIES setting and use the X-Forwarded-For header. For most homelab users, Nextcloud's built-in brute-force protection is sufficient.

Home Assistant Security

# config/hass/configuration.yaml additions

# Require login
homeassistant:
  auth_providers:
    - type: homeassistant
    - type: legacy_api_password  # Remove after migration

# IP ban after failed attempts
http:
  ip_ban_enabled: true
  login_attempts_threshold: 5
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.16.0.0/12    # Docker networks
    - 127.0.0.1        # Localhost (cloudflared)

Cloudflare Access (Zero Trust Authentication)

For an extra layer, add Cloudflare Zero Trust authentication before your service:

# Create an Access application in Cloudflare Zero Trust dashboard
# Settings → Zero Trust → Access → Applications → Add Application

# Configuration:
# Application name: Home Assistant
# Domain: hass.commsnet.org
# Policy: Email OTP (one-time password to your email)
# Or: Identity provider (Google, GitHub, etc.)

Now visitors hit Cloudflare's login wall before they even see Home Assistant. Two layers of authentication, zero ports open.

Step 6: Monitoring and Backups

Health Checks

# Add to your docker-compose.yml
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_SCHEDULE=0 0 4 * * *    # 4 AM daily
      - WATCHTOWER_NOTIFICATIONS=email
      - WATCHTOWER_NOTIFICATION_EMAIL_FROM=watchtower@commsnet.org
      - WATCHTOWER_NOTIFICATION_EMAIL_TO=admin@commsnet.org
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER=smtp.example.com
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=587
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=${SMTP_USER}
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=${SMTP_PASSWORD}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - nextcloud-internal

Backup Strategy

#!/bin/bash
# backup-nextcloud.sh — Run daily via cron

# 1. Put Nextcloud in maintenance mode
docker exec -u www-data nextcloud-app php occ maintenance:mode --on

# 2. Dump PostgreSQL
docker exec nextcloud-db pg_dump -U nextcloud_db nextcloud > /backups/nextcloud-db-$(date +%Y%m%d).sql

# 3. Sync data directory
rsync -az --delete /path/to/nextcloud/data/ /backups/nextcloud-data/

# 4. Take Nextcloud out of maintenance mode
docker exec -u www-data nextcloud-app php occ maintenance:mode --off

# 5. Upload to offsite (optional — Backblaze B2, S3, etc.)
# rclone sync /backups/ remote:nextcloud-backups/

Home Assistant Backups

# Home Assistant automatic backups (in configuration.yaml)
automation:
  - alias: "Daily Backup"
    trigger:
      - platform: time
        at: "03:00:00"
    action:
      - service: backup.create
        data:
          name: "Daily Backup {{ now().strftime('%Y-%m-%d') }}"
          keep_days: 7

Troubleshooting

Tunnel Won't Connect

# Check cloudflared logs
sudo journalctl -u cloudflared -f

# Common issues:
# 1. DNS records not created — run `cloudflared tunnel route dns` again
# 2. Credentials file missing — check ~/.cloudflared/ for the JSON file
# 3. Firewall blocking outbound 7844 — Cloudflare uses this port for tunnel protocol

Nextcloud Shows Wrong URL

# Force the correct URL in config.php
docker exec -u www-data nextcloud-app php occ config:system:set overwrite.cli.url --value="https://nextcloud.commsnet.org"
docker exec -u www-data nextcloud-app php occ config:system:set overwriteprotocol --value="https"

Home Assistant Not Accessible

# Check container health
docker inspect homeassistant | jq '.[0].State'

# Check logs
docker logs homeassistant --tail 50

# Common issue: WebSocket not upgrading
# Ensure your Cloudflare tunnel config has noTLSVerify: true
# and that you're using http:// not https:// in the service URL

Performance: Nextcloud Slow

# Enable Redis caching (verify in config.php)
docker exec -u www-data nextcloud-app php occ status

# Check Redis connection
docker exec nextcloud-redis redis-cli -a "$REDIS_PASSWORD" ping

# Run maintenance tasks
docker exec -u www-data nextcloud-app php occ maintenance:repair
docker exec -u www-data nextcloud-app php occ files:scan --all

What You've Gained

Before (ISP Defaults)	After (This Setup)
CGNAT — no inbound connections	Cloudflare Tunnel — outbound only
Cloud storage subscriptions	Self-hosted Nextcloud — your data, your rules
Exposed ports for services	Zero open inbound ports
No home automation centralization	Home Assistant with full control
Dynamic IP DDNS hacks	Cloudflare-managed DNS with automatic TLS
No backup strategy	Automated daily backups to offsite
Single point of failure	Health checks and automated recovery

Monthly Cost Comparison

Service	Cloud Subscription	Self-Hosted
File storage (1TB)	Google One: $9.99/mo	Nextcloud: $0
Calendar/Contacts	Google: Free (data tax)	Nextcloud: $0
Home Automation	Nabu Casa: $6.50/mo	HA Supervised: $0
Domain	—	Cloudflare: ~$10/yr
Cloudflare Tunnels	—	Free
Electricity (est.)	—	~$5-10/mo
Total	$16.49/mo	~$1/mo + electricity

You break even in under a year, and you own your data forever.

Next Steps

Get a domain — transfer to Cloudflare or point nameservers there
Set up Cloudflare Tunnel — 15 minutes, zero ports opened
Deploy Nextcloud — Docker Compose up, configure, migrate your data
Deploy Home Assistant — start small, add integrations over time
Set up backups — automated, offsite, tested
Monitor — add Watchtower for updates, health checks for uptime

Self-hosting isn't just about saving money. It's about owning your infrastructure, your data, and your time. When Google sunsets a product or Dropbox changes their terms, you won't care — because your files are on your hardware, behind your domain, on your terms.

CommsNet builds secure, sovereign infrastructure. More at wiki.commsnet.org

Tags: #selfhosted #nextcloud #homeassistant #cloudflare #tunnels #docker #privacy #homelab #degoogling

Building a Secure Homelab with Proxmox VE, pfSense, and Cilium

Luna Commsnet — Mon, 22 Jun 2026 15:50:33 +0000

Building a Secure Homelab with Proxmox VE, pfSense, and Cilium

Published: May 25, 2026 | CommsNet

Your homelab shouldn't be a flat network where every container can talk to every service. That's the ISP's model — one big subnet, trust everything. But you're running your own infrastructure now. You get to do better.

In this article, I'll walk through building a layered, observable homelab using three technologies that complement each other beautifully: Proxmox VE for virtualization, pfSense for network segmentation, and Cilium for eBPF-based observability and micro-segmentation. By the end, you'll have a setup where a compromised container can't pivot to your storage array, your traffic flows are visible at the kernel level, and your firewall rules actually mean something because your VLANs enforce them.

Why This Stack?

Proxmox VE — The Foundation

Proxmox gives you KVM virtual machines and LXC containers on the same hypervisor, with a decent web UI, ZFS-backed storage, and cluster support. It's the closest thing to an enterprise data center you can run on repurposed desktop hardware.

What matters for security:

Separate physical NICs for WAN, LAN, and management — don't trunk everything over one interface
Linux Bridge isolation — each VLAN gets its own bridge, and bridges don't route between each other without explicit firewall rules
AppArmor profiles for LXC containers — even your unprivileged containers get kernel-level confinement

pfSense — The Gatekeeper

pfSense sits at your network boundary and between your VLANs. It's not sexy, but it's reliable. FreeBSD's packet filter is battle-tested, and pfSense gives you a usable GUI on top of it.

What you get:

Inter-VLAN firewalling — your IoT VLAN cannot reach your server VLAN unless you write a rule
Alias-based rules — group IPs and ports by function, not by individual addresses
VPN concentrator — WireGuard or OpenVPN for remote access without exposing services
Traffic shaping — because your backup job shouldn't saturate your upload

Cilium — The Observer

This is where it gets interesting. Cilium uses eBPF to inject observability and security policies directly into the Linux kernel — no sidecar proxies, no iptables chaos. It sees every packet, every connection, every DNS lookup, and it can enforce policy at Layer 3/4 and Layer 7.

Why Cilium in a homelab:

Hubble — real-time service map showing every connection between your workloads
Network policies — Kubernetes-native micro-segmentation that pfSense can't see inside your cluster
eBPF observability — kernel-level tracing without modifying applications
Transparent encryption — WireGuard-based encryption between nodes, managed declaratively

Architecture Overview

                    ┌─────────────┐
                    │   Internet   │
                    └──────┬──────┘
                           │ WAN
                    ┌──────┴──────┐
                    │   pfSense    │
                    │  (VM on      │
                    │  Proxmox)    │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────┴─────┐ ┌───┴───┐ ┌─────┴─────┐
        │  VLAN 10   │ │VLAN 20│ │  VLAN 30   │
        │  Trusted   │ │  IoT  │ │  Servers   │
        │  LAN       │ │       │ │  (K8s)     │
        └─────┬─────┘ └───────┘ └─────┬─────┘
              │                        │
        ┌─────┴─────┐          ┌───────┴────────┐
        │ Workstations│        │  Proxmox Node   │
        │ Printers    │        │  ┌─────────────┐│
        │ Media        │        │  │  K8s Cluster  ││
        └─────────────┘        │  │  + Cilium    ││
                               │  │  + Hubble     ││
                               │  └─────────────┘│
                               └─────────────────┘

Step 1: Proxmox Network Foundation

Physical NIC Assignment

Don't skip this. Using a single NIC with VLAN tagging works in a pinch, but separate physical interfaces eliminate a whole class of failure modes.

# Check your NICs
ip link show

# Assign roles in /etc/network/interfaces
# eno1 → WAN (passed through to pfSense VM)
# eno2 → vmbr0 (LAN - VLAN 10)
# eno3 → vmbr1 (Server - VLAN 30)
# eno4 → vmbr2 (IoT - VLAN 20)

Bridge Configuration

# /etc/network/interfaces on Proxmox host

# Management bridge (access your Proxmox web UI)
auto vmbr0
iface vmbr0 inet static
    address 10.10.10.1/24
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

# Server VLAN bridge
auto vmbr1
iface vmbr1 inet static
    address 10.30.10.1/24
    bridge-ports eno3
    bridge-stp off
    bridge-fd 0

# IoT VLAN bridge (isolated)
auto vmbr2
iface vmbr2 inet static
    address 10.20.10.1/24
    bridge-ports eno4
    bridge-stp off
    bridge-fd 0

Proxmox Firewall Basics

Enable the datacenter firewall, but keep it simple initially. Block all by default, allow only what's needed:

# /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
# Allow SSH from management subnet only
IN ACCEPT -source 10.10.10.0/24 -p tcp -dport 22 -log nolog
# Allow Proxmox web UI from management subnet
IN ACCEPT -source 10.10.10.0/24 -p tcp -dport 8006 -log nolog
# Allow pfSense management
IN ACCEPT -source 10.10.10.0/24 -p tcp -dport 443 -dest 10.10.10.2 -log nolog

Step 2: pfSense as VLAN Firewall

VM Setup

Create pfSense as a VM with at least 2 vCPUs and 2GB RAM. Attach NICs:

Interface	Bridge	Role
vtnet0	WAN passthrough	Internet
vtnet1	vmbr0	LAN (VLAN 10)
vtnet2	vmbr1	Server (VLAN 30)
vtnet3	vmbr2	IoT (VLAN 20)

Inter-VLAN Rules

This is where most homelabs fall apart. If your IoT devices can reach your NAS, you've already lost. Here's the principle:

Default deny. Allow only what's explicitly needed.

LAN → Any (Trusted)

# LAN interface — your workstations and admin machines
# Allow all outbound (your trusted users)
pass in on vtnet1 from 10.10.10.0/24 to any

Server → LAN (Selective)

# Server interface — K8s nodes, storage, services
# Allow established connections back
pass in on vtnet2 proto tcp from 10.30.10.0/24 to 10.10.10.0/24 port { 22, 443, 6443 } keep state
# Block everything else
block in on vtnet2 from 10.30.10.0/24 to 10.10.10.0/24

IoT → Only Internet (Locked Down)

# IoT interface — your smart devices, cameras, TVs
# Allow DNS and NTP outbound
pass in on vtnet3 proto { tcp, udp } from 10.20.10.0/24 to any port { 53, 123 }
# Allow HTTP/HTTPS outbound for firmware updates
pass in on vtnet3 proto tcp from 10.20.10.0/24 to any port { 80, 443 }
# Block ALL access to internal networks
block in on vtnet3 from 10.20.10.0/24 to { 10.10.10.0/24, 10.30.10.0/24, 10.10.10.1, 10.30.10.1 }

Aliases — Manage Rules at Scale

Don't hardcode IPs. Use aliases:

# pfSense aliases (Diagnostics → Aliases)
TRUSTED_NET    = 10.10.10.0/24
SERVER_NET     = 10.30.10.0/24
IOT_NET        = 10.20.10.0/24
DNS_PORTS      = 53
NTP_PORTS      = 123
ADMIN_PORTS    = 22, 443, 8006

Then your rules reference aliases, not IPs. When you add a new server subnet, update the alias, not every rule.

Step 3: Cilium for Kubernetes Observability and Micro-Segmentation

Installation

Deploy Cilium as your CNI on your K8s cluster running inside Proxmox VMs or LXC:

# Install Cilium via Helm
helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=strict \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set operator.replicas=1

Why kube-proxy Replacement Matters

Running kubeProxyReplacement=strict means Cilium replaces iptables-based kube-proxy entirely with eBPF. Benefits:

Faster service routing — eBPF programs run in-kernel, no context switches to userspace
Lower latency — direct packet processing at the socket layer
Consistent observability — every connection goes through the same eBPF programs
No iptables drift — one mechanism, not two

Hubble — See Every Connection

Hubble is Cilium's observability layer. It streams every network connection in real time:

# Port-forward Hubble Relay
kubectl port-forward -n kube-system svc/hubble-relay 4245:4245

# Watch all connections in real time
hubble observe --since 1m

# Filter by namespace
hubble observe --namespace production --since 5m

# Track DNS resolution failures (classic IoT misbehavior indicator)
hubble observe --type trace:to-endpoint:dns --verdict DROPPED

The Hubble UI gives you a visual service map. You'll see immediately if your Home Assistant container is phoning home to sketchy endpoints, or if your Nextcloud pod is trying to reach the Kubernetes API when it shouldn't.

Network Policies — Defense in Depth

pfSense controls traffic between VLANs. Cilium NetworkPolicies control traffic inside your cluster. Both layers matter.

Default Deny All Ingress

# default-deny.yaml — apply to every namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Allow Specific Service Communication

# nextcloud-policy.yaml — Nextcloud can reach its DB and Redis, nothing else
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nextcloud-ingress
  namespace: home-services
spec:
  podSelector:
    matchLabels:
      app: nextcloud
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: nginx-ingress
      ports:
        - port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres-nextcloud
      ports:
        - port: 5432
    - to:
        - podSelector:
            matchLabels:
              app: redis-nextcloud
      ports:
        - port: 6379
    - to: []  # Allow DNS
      ports:
        - port: 53
          protocol: UDP

CiliumNetworkPolicy — L7 Visibility

Standard Kubernetes NetworkPolicies are L3/L4. Cilium extends this to L7:

# cilium-l7-policy.yaml — restrict Nextcloud egress at HTTP level
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: nextcloud-l7-egress
  namespace: home-services
spec:
  endpointSelector:
    matchLabels:
      app: nextcloud
  egress:
    - toFQDNs:
        - matchName: "updates.nextcloud.com"
        - matchName: "download.nextcloud.com"
      toPorts:
        - ports:
            - port: "443"
          rules:
            http:
              - method: GET
                path: "/.*"

Now your Nextcloud instance can only make outbound GET requests to specific domains. If an attacker compromises it, they can't exfiltrate data to arbitrary endpoints — the eBPF program in the kernel drops the connection before it reaches the wire.

Step 4: Observability Pipeline

Metrics Flow

Cilium eBPF → Hubble → Prometheus → Grafana
     ↓
pfSense (netflow) → Prometheus → Grafana
     ↓
Proxmox (node metrics) → Prometheus → Grafana

Key Dashboards to Build

Inter-VLAN traffic — who's talking to whom? Any IoT device hitting server subnets?
DNS queries per namespace — spot DNS tunneling or C2 callbacks
Connection drops per policy — are your policies actually working?
pfSense rule hits — which rules fire most? Tune your alias groups.
eBPF program latency — should be sub-microsecond. If it spikes, you've got a problem.

Alerting Rules

# Prometheus alerts for your homelab security
groups:
  - name: homelab-security
    rules:
      - alert: IoTDeviceReachingServerNet
        expr: |
          hubble_flows_total{
            source_namespace="iot",
            destination_namespace="servers"
          } > 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "IoT device reaching server network"

      - alert: UnexpectedDNSQueries
        expr: |
          count(hubble_dns_queries_total) by (namespace, qname) 
          > 100
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Unusual DNS query volume from {{ $labels.namespace }}"

      - alert: CiliumPolicyDrop
        expr: |
          cilium_policy_verdict_total{verdict="dropped"} > 0
        for: 2m
        labels:
          severity: info
        annotations:
          summary: "Cilium policy dropping traffic — expected behavior"

Security Best Practices Checklist

Proxmox

[ ] Enable Proxmox firewall at datacenter level
[ ] Use separate physical NICs for WAN, LAN, management
[ ] Run LXC containers as unprivileged with AppArmor profiles
[ ] Enable 2FA on Proxmox web UI
[ ] Regular ZFS snapshots with automated send to offsite
[ ] Keep Proxmox updated — subscribe to enterprise repo or use no-subscription

pfSense

[ ] Default deny on all interfaces except LAN
[ ] Use aliases, not hardcoded IPs, in rules
[ ] Enable pfBlockerNG for ad/malware blocking at the gateway
[ ] Set up WireGuard VPN for remote access — don't expose services
[ ] Regular config backups (Automated via cron to offsite storage)
[ ] Disable WAN responses — no ping, no admin interface on WAN

Cilium/Kubernetes

[ ] Default deny all ingress NetworkPolicy in every namespace
[ ] Use CiliumNetworkPolicy for L7 egress restrictions
[ ] Enable Hubble for real-time observability
[ ] Run kubeProxyReplacement=strict — don't mix iptables and eBPF
[ ] Enable Cilium encryption (WireGuard) for inter-node traffic
[ ] Audit NetworkPolicies regularly — use kubectl get networkpolicies -A to review

General

[ ] All management interfaces behind VPN or local access only
[ ] SSH key-only authentication — disable password auth
[ ] Automated security updates (unattended-upgrades on Debian/Ubuntu hosts)
[ ] Centralized logging to a write-once destination
[ ] Document your network topology — future you will thank present you

What This Gets You

Threat	Mitigation
Compromised IoT device	Can't reach server VLAN (pfSense drops it)
Lateral movement in K8s	NetworkPolicy default deny + Cilium L7 rules
Data exfiltration from container	Cilium FQDN egress policy + DNS monitoring
Unauthorized remote access	WireGuard VPN, no exposed ports
Blind spots	Hubble service map + Prometheus alerts
Insider threat (rogue admin)	Separate management VLAN + audit logging

Cost Breakdown

Component	Hardware	Cost
Proxmox host	Refurbished Dell OptiPlex (i5, 32GB RAM, 2TB NVMe)	~$200
NICs	Intel X710-T2L (2.5GbE, SR-IOV capable)	~$80 each × 2
pfSense	VM on Proxmox (free CE edition)	$0
Cilium	Open source	$0
Switch	Used managed switch (VLAN-capable)	~$40
Total		~$400

That's enterprise-grade network segmentation for less than a single rack-mount firewall license.

Next Steps

Start with Proxmox — get your VMs running, assign NICs properly
Add pfSense — configure VLANs before you deploy services
Deploy K8s with Cilium — enable Hubble from day one
Layer in policies — default deny first, then add specific allows
Observe — watch Hubble for a week before you think you know your traffic patterns

The homelab that's invisible to its own admin is the homelab that gets owned. Build with observability from day one, and you'll catch problems when they're misconfigurations, not breaches.

CommsNet builds secure, observable infrastructure. More at wiki.commsnet.org

Tags: #homelab #proxmox #pfsense #cilium #ebpf #kubernetes #networking #security #selfhosted