Homelab Build — Part 3 — Networking with pfSense

What This Part Covers

Part 1 reserved four network segments — Management, Servers, Clients, and DMZ/Guest — as ranges in a planning file. Part 2 built the Proxmox host that everything in this series runs on. This part is where those two things meet: pfSense goes in as a VM on that same host, gets assigned a WAN and LAN interface, and then grows a VLAN sub-interface for each of the remaining segments, each with its own IP, DHCP scope, and firewall rules.

Think of pfSense as the wall and the door between segments. Before this part, “Servers” and “Clients” are just two rows in a table — nothing stops a device on one from reaching the other, because nothing is enforcing the split. After this part, they are VLANs with a firewall between them, and crossing from one to the other requires a rule that explicitly allows it.

Why a Dedicated Firewall Instead of the Home Router?

A consumer or ISP-supplied router can hand out one DHCP scope on one flat network and not much else. It has no concept of VLANs, no per-segment firewall rules, and usually no way to say “Clients can reach the Internet but not the Servers segment.” That is fine for a household network. It stops being fine the moment a lab has more than one trust zone that needs to be kept apart.

This is the same separation of concerns real network edges use: a router/firewall that owns the boundary between zones, a switch that carries tagged traffic, and servers that never have to enforce segmentation themselves because the network already does it for them.

Deploying pfSense on the Proxmox Host

Part 1’s plan assumes a single physical host, and Part 2 built that host as a Proxmox hypervisor — so pfSense runs as a VM on pve01 rather than on dedicated hardware. pfSense’s own minimum requirements are modest: a 64-bit CPU, 1 GB of RAM, and an 8 GB disk. This lab gives it 2 vCPUs, 2 GB RAM, and an 8 GB disk on the local directory storage from Part 2 — comfortable headroom without taking meaningfully away from the VMs later parts will create on the ZFS pool.

The VM needs two virtual NICs, and getting their bridge assignment right matters more than any other setting on the creation screen:

Configuring a Linux bridge on Proxmox as a VLAN-aware trunk — enabling bridge-vlan-aware, and getting a VM’s NIC to pass every tag through instead of just one — is covered in full in the existing Proxmox Networking: Bridges, VLANs, and Bonding post. This part does not repeat that mechanic; it picks up once net1 is attached to a trunk bridge and pfSense itself is ready to split that trunk into per-segment interfaces.

Assigning WAN and LAN

On first boot, the pfSense installer’s console prompts for interface assignment directly; the same assignment can be revisited later from the console menu’s option 1) Assign Interfaces, or from the GUI at Interfaces > Assignments. pfSense distinguishes WAN from LAN by one rule: an interface with a gateway selected is treated as WAN for NAT and related functions, and no LAN-side interface should have one.

Creating VLANs for the Remaining Segments

With LAN (vtnet1) assigned as the trunk-facing interface, the Servers, Clients, and DMZ/Guest segments from Part 1 become VLAN sub-interfaces on top of it. VLANs are created at Interfaces > Assignments, on the VLANs tab, via Add: choose a Parent Interface, a VLAN Tag (VID) from 1–4094, leave the VLAN Tag Type at its default of C-Tag (standard 802.1Q), and give it a Description.

Each saved VLAN appears in the Available Network Ports list as, for example, “VLAN 10 on vtnet1 (Servers)”. Back on the main Interfaces > Assignments tab, assign each one as a new interface (they land as OPT1, OPT2, OPT3), then open each and set it Enabled, rename it, and give it a static IPv4 address — the gateway address for that segment from Part 1’s plan:

DHCP Scopes Per Segment

pfSense’s DHCP daemon can only run on an interface that already has a static IP, which is why WAN never gets a tab here but LAN and the three new VLAN interfaces all do. Configuration lives at Services > DHCP Server, one tab per eligible interface: check Enable, then set the pool’s From and To addresses. Part 1’s plan already reserved the DHCP range as .50–.200 of each segment, leaving .1–.20 for static infrastructure like the gateway addresses just assigned above.

LAN (Management) intentionally gets no DHCP pool. Part 1 scoped that segment for fixed-address infrastructure — the Proxmox host, pfSense’s own management IP, and later a switch or iDRAC/IPMI interface — and every device on it should be assigned a static address deliberately rather than picking one up dynamically.

Firewall Rules Between Segments

A newly assigned interface in pfSense starts with no rules at all, which combined with the implicit default-deny at the bottom of every ruleset means a brand-new VLAN interface passes nothing until a rule explicitly allows it. Rules are created at Firewall > Rules, on the tab for the interface they apply to, and evaluated top to bottom — the first matching rule wins, and everything unmatched is silently dropped.

pfSense does not ship a built-in alias for the RFC 1918 private ranges — it has to be created once at Firewall > Aliases > Add: Name PRIVATE_NETWORKS, Type Network(s), with three entries — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — covering all of RFC 1918. That alias is what the DMZ rule below negates.

Every rule created this way should carry a short Description — the field exists specifically so a ruleset read six months from now still explains itself, the same discipline Part 1 applied to the planning file.

Verification Commands

Before creating the first domain controller in Part 4, confirm every interface pfSense created actually exists, the routing table looks right, and the ruleset just written is the one actually loaded. These run from the console’s 8) Shell option, over SSH, or from Diagnostics > Command Prompt in the GUI.

# Confirm every interface, including the three VLAN sub-interfaces, is present and up
ifconfig -a

# Confirm the default route points out through WAN's gateway
netstat -rn

# List the loaded firewall ruleset in evaluation order, with rule counters
pfctl -vvsr

Networking Setup Issues

Final Thoughts

None of the segments from Part 1’s plan meant anything to the network itself until this part. A subnet in a table is a reservation; a VLAN with an interface, a DHCP scope, and a firewall rule is an actual network boundary that a real device on real hardware has to respect.

What this part produces is deliberately unfinished in one direction: the SERVERS and CLIENTS rules are still broad “allow everything out” rules, because nothing has been built on those segments yet to narrow them against. That’s expected. Part 4 gives the Servers segment its first real occupant.

That domain controller is now live: Part 4 — Domain Controllers walks through creating the forest on dc01 and adding dc02 for redundancy, on top of the SERVERS segment this part built.