What is the LAN-A / LAN-B topology used in this lab?

pfSense holds a WAN uplink plus two internal segments: LAN-A ("trusted"), which holds the attacker/analyst VM, and LAN-B ("targets"), which holds the deliberately vulnerable machines. The rules are asymmetric: LAN-A can reach LAN-B for testing, but LAN-B cannot initiate connections into LAN-A, mirroring how untrusted systems are isolated in production.

How do you verify the pfSense segmentation rules actually work?

With nmap run against your own hosts. From the LAN-A analyst VM, scan a LAN-B target to confirm the allowed direction works, then run the reverse scan from LAN-B toward LAN-A, which should time out or return nothing. If the reverse scan succeeds, the rule order or interface assignment is wrong and needs to be fixed and re-tested.

What causes pfSense segmentation to behave unexpectedly?

Three things account for almost every problem: network adapters mapped to the wrong segment in the hypervisor, rule order mistakes (pfSense evaluates rules top to bottom and stops at the first match, so a broad allow above a block rule silently defeats it), and stale connection states left over from before a rule change, which can be cleared under Diagnostics → States → Reset.

LAB · SERIES

Lab 04 — put a firewall in the middle.

Q: Why add pfSense to a home lab that already has attacker, target, and SIEM VMs?

By Lab 03 the lab sits on one flat network where every VM can reach every other VM. Segmentation is one of the most effective security controls there is: it is what stops one compromised machine from becoming every machine. pfSense, a free open-source firewall, is added as the router in the middle so that isolation can be practised, not just described.

A flat lab where every VM can reach every other VM teaches bad habits. Add pfSense, split the network, and prove the walls hold with nmap.

June 20, 202610 min read

By Lab 03 your lab has attacker, target and monitoring — but they all sit on one flat network where everything can reach everything. Real networks are not built that way, and neither should your lab be. In this lab you add pfSense, a free open-source firewall, as the router in the middle, then carve the lab into isolated segments and prove the isolation actually works.

This matters beyond tidiness. Segmentation is one of the most effective controls there is: it is what stops one compromised machine from becoming every machine. Practising it in a lab is how the concept stops being an abstraction.

The topology you are building

You will end up with pfSense holding two internal segments plus an uplink:

Segment	Role
WAN	pfSense's uplink to the outside (a NAT adapter), so lab VMs can fetch updates without being exposed.
LAN-A ("trusted")	Your attacker/analyst VM (e.g. a Kali or analysis box).
LAN-B ("targets")	The deliberately vulnerable machines from Lab 02, walled off from anything you care about.

The whole point is that LAN-B cannot initiate connections into LAN-A, while LAN-A can reach LAN-B for testing. That asymmetry mirrors how you would isolate untrusted systems in production.

Install and place pfSense

Create a new VM from the pfSense installer ISO. Give it two or three network adapters: one NAT (WAN) and one or two internal/host-only adapters (the LAN segments).
Run the installer — it is a guided, text-based process. When it boots, pfSense assigns WAN and LAN automatically; you confirm which adapter is which by MAC address.
From a VM on the LAN side, browse to the pfSense web UI (default https://192.168.1.1) and finish the setup wizard. Change the default admin password immediately — habit, even in a lab.

Write the minimum rules

pfSense defaults to "block everything inbound" on WAN and "allow everything" on LAN. You are going to tighten the internal side. On the LAN-B (targets) interface, replace the default allow-all with rules that:

Allow LAN-B to reach the WAN (so targets can be updated) — but not the LAN-A subnet.
Explicitly block LAN-B → LAN-A. This is the wall: a compromised target cannot pivot into your analyst box.
On LAN-A, allow LAN-A → LAN-B so you can still run your tests against the targets.

Order matters in pfSense: rules are evaluated top to bottom, first match wins. Put the block rule above any broad allow. This tiny rule set is the entire lesson — least privilege expressed as firewall policy.

Verify with nmap — against your own hosts

Rules you have not tested are just hopes. From your LAN-A analyst VM, scan a target on LAN-B to confirm you can reach it:

# from LAN-A, scanning YOUR OWN target on LAN-B
nmap -sV 10.10.20.10

Then do the reverse: from a LAN-B target, try to scan the analyst box on LAN-A. It should time out or return nothing — the pfSense block rule is doing its job. If the reverse scan succeeds, your rule order or interface assignment is wrong; fix it and re-test. That round trip — change a rule, verify with a scan — is exactly the loop a network defender runs, and now you own both ends of it.

Common mistakes to check first

If the segmentation behaves unexpectedly, three things cause almost every problem:

Adapters mapped to the wrong segment. In the hypervisor, double-check which virtual adapter is WAN, which is LAN-A and which is LAN-B. A mislabelled adapter makes correct-looking rules apply to the wrong traffic. pfSense identifies interfaces by MAC — match them carefully.
Rule order. pfSense stops at the first matching rule. A broad "allow LAN to any" sitting above your block rule silently defeats it. Keep the specific block above the general allow.
Stale states. pfSense keeps a state table of existing connections. After changing a rule, reset states (Diagnostics → States → Reset) so an already-open connection is not what you are measuring.

Work through those in order and the isolation behaves. The habit of trusting a verification scan over a rule you "know" is correct is worth more than the pfSense knowledge itself — it is the mindset that catches real misconfigurations in real networks.

Legal & scope. Every scan in this lab targets machines you built, on a private segmented network you control. nmap against hosts or networks you do not own — or lack explicit written permission to scan — can be unlawful regardless of intent. Keep it inside the lab.