01 April 2026

πŸ“Œ pfSense. Installed months ago. Never touched. Tonight that changed.

The setup was already there β€” VM 130 on Proxmox, 4GB disk, one NIC on vmbr0, WebUI accessible at 192.168.0.36. A firewall with no configuration is not a firewall. It's a placeholder.

The goal: VLAN segmentation. Separate the homelab containers from the main LAN. Simple enough in theory.

proxmox

Two new Linux bridges needed. vmbr1 already existed β€” VLAN-aware, 10.1.149.30/24, no physical ports. Created as part of the ntopng setup. vmbr2 did not. Created it clean: no IP, no ports, no VLAN tagging. Just a bridge.

auto vmbr2
iface vmbr2 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0

Adding bridges to a running Proxmox node has no impact on existing containers. Apply Configuration is not dramatic.

Two VirtIO NICs added to the pfSense VM β€” net1 on vmbr1, net2 on vmbr2. The existing net0 on vmbr0 stays as WAN. The VM was shut down for this. Hardware changes require it.

pfsense

After boot, Interfaces β†’ Interface Assignments showed vtnet0 and vtnet1 as available. Added both. pfSense named them LAN and OPT1 automatically. Renamed OPT1 description to LAN_PC later.

Configured LAN (vtnet0 β†’ vmbr1): Static IPv4, 10.1.149.1/24. Saved. Applied.

Lost the WebUI immediately.

This is expected behaviour. pfSense blocks WebUI access from WAN by default. The interface change moved where pfSense expected the admin traffic to come from. The firewall was doing its job.

recovery

Proxmox console works without network. That's the point of a console.

From the pfSense menu, option 8 β€” Shell:

pfctl -d

Disables the packet filter entirely. Temporary. Enough to get back in.

From there, added a WAN rule: pass TCP from 192.168.0.0/24 to This Firewall (self) on port 443. Applied. WebUI accessible again. pfctl -d is not a solution β€” it's a recovery tool.

the uncomfortable discovery

All containers are on 192.168.0.x via vmbr0. Not 10.1.149.x. vmbr1 is essentially empty β€” only the Proxmox host has an IP there.

Checked from lldap:

ip addr show eth0
# inet 192.168.0.108/24

The segmentation plan assumed containers were already distributed across bridges. They are not. Twenty-five containers, one flat network.

This changes the scope of the work. Migrating containers means updating IPs in NPM, Pi-hole, LLDAP, and anything else that references them by address. Not tonight.

where it stands

WAN   (em0)    β†’ 192.168.0.36/24   β€” router-facing
LAN   (vtnet0) β†’ 10.1.149.1/24     β€” vmbr1, currently empty
OPT1  (vtnet1) β†’ 192.168.1.1/24    β€” vmbr2, currently empty

pfSense is running. Three interfaces configured. Firewall rules in place for admin access. The actual segmentation β€” moving containers, updating references, writing proper firewall policies between segments β€” is a separate project.

Learning what breaks and why is the point. Tonight it broke twice. Both times recoverable. That's a good session.