|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "AD DFIR Lab — Part 3: Beyond the Wall — pfSense, VLANs and Network Segmentation" |
| 4 | +date: 2026-04-12 15:00:00 +0100 |
| 5 | +category: cases |
| 6 | +lang: en |
| 7 | +ref: case-ad-dfir-lab-part3 |
| 8 | +tags: [dfir, pfsense, vlan, network, lab, proxmox] |
| 9 | +description: "Deploying pfSense as router/firewall between the corporate network (VLAN 10) and the attack network (VLAN 20). Kali has to pivot through pfSense to reach the domain — exactly like a real attacker." |
| 10 | +comments: true |
| 11 | +--- |
| 12 | + |
| 13 | +*This is Part 3 of the [AD DFIR Lab]({% post_url en/2026-04-12-ad-dfir-lab-intro %}) series. We configure pfSense to separate the attack network from the corporate network, forcing Kali to pivot like an external attacker.* |
| 14 | + |
| 15 | +## Why pfSense |
| 16 | + |
| 17 | +In [Part 2]({% post_url en/2026-04-12-ad-dfir-lab-part2-windows-vms %}) we created VMs split across two VLANs: |
| 18 | +- **VLAN 10** (192.168.10.0/24) — Corporate network with all DCs, servers and workstations |
| 19 | +- **VLAN 20** (192.168.20.0/24) — Isolated network with Kali |
| 20 | + |
| 21 | +But VLANs alone do nothing useful — they need a router that decides what traffic can pass between them. That's pfSense's job. |
| 22 | + |
| 23 | +Why pfSense and not just `iptables` on Proxmox? Three reasons: |
| 24 | + |
| 25 | +1. **Realism**: in a real corporate environment there's a dedicated firewall between segments. Reproducing this in the lab gives more representative forensic artifacts |
| 26 | +2. **Traceability**: pfSense logs every blocked/allowed connection, just like an enterprise firewall |
| 27 | +3. **Visual rules**: the web UI lets you craft pivoting scenarios without touching `iptables` |
| 28 | + |
| 29 | +## Why pfSense install is manual |
| 30 | + |
| 31 | +Unlike Windows (autounattend), Ubuntu (cloud-init) or Kali (preseed in initrd), **pfSense has no reliable unattended installation mechanism**. Projects like `mfsBSD` allow some automation but for a one-shot install they're more trouble than the manual process. |
| 32 | + |
| 33 | +The install takes about 5 minutes via VNC. Here's the full walkthrough. |
| 34 | + |
| 35 | +## Step-by-step installation |
| 36 | + |
| 37 | +### 1. Accept copyright |
| 38 | + |
| 39 | +Boot from the pfSense ISO (`pfSense-CE-2.7.2-RELEASE-amd64.iso`): |
| 40 | + |
| 41 | + |
| 42 | + |
| 43 | +Enter to Accept. |
| 44 | + |
| 45 | +### 2. ZFS partitioning |
| 46 | + |
| 47 | +Go through the install menu: Install → default keymap → **Auto (ZFS)** → Install → Stripe → select disk: |
| 48 | + |
| 49 | + |
| 50 | + |
| 51 | +Space to mark `da0`, Tab to OK, Enter. |
| 52 | + |
| 53 | +### 3. Confirm wipe |
| 54 | + |
| 55 | + |
| 56 | + |
| 57 | +YES. Disk is empty, no risk. |
| 58 | + |
| 59 | +### 4. Remove ISO before first boot |
| 60 | + |
| 61 | +**Important gotcha**: when pfSense finishes installing and reboots, it boots from the ISO again. Remove it from Proxmox: |
| 62 | + |
| 63 | +```bash |
| 64 | +qm stop 100 --timeout 5 |
| 65 | +qm set 100 --delete ide2 |
| 66 | +qm set 100 --boot order=scsi0 |
| 67 | +qm start 100 |
| 68 | +``` |
| 69 | + |
| 70 | +Without this, pfSense asks to reinstall on every boot. Same problem we hit with Kali in Part 2. |
| 71 | + |
| 72 | +### 5. Initial interface setup |
| 73 | + |
| 74 | +After first boot of the installed system, pfSense asks about interface configuration: |
| 75 | + |
| 76 | + |
| 77 | + |
| 78 | +- "Should VLANs be set up now?" → **n** (no, VLANs are handled by Proxmox at the bridge level) |
| 79 | +- "Enter the WAN interface name" → **vtnet0** (our `--net0` with `tag=10`) |
| 80 | + |
| 81 | + |
| 82 | + |
| 83 | +- "Enter the LAN interface name" → **vtnet1** (our `--net1` with `tag=20`) |
| 84 | +- Confirm → **y** |
| 85 | + |
| 86 | +### 6. The console menu |
| 87 | + |
| 88 | +We arrive at the pfSense main menu: |
| 89 | + |
| 90 | + |
| 91 | + |
| 92 | +By default pfSense grabbed DHCP on WAN (`192.168.10.50` from Proxmox's temporary dnsmasq) and LAN is at `192.168.1.1`. Both need to change to the lab IPs. |
| 93 | + |
| 94 | +### 7. Configure static WAN IP |
| 95 | + |
| 96 | +Option **2** (Set interface IP) → **1** (WAN) → **n** (no DHCP): |
| 97 | + |
| 98 | + |
| 99 | + |
| 100 | +- IP: `192.168.10.2` |
| 101 | +- Subnet: `24` |
| 102 | +- Gateway: `192.168.10.1` (Proxmox host, doing NAT to internet) |
| 103 | +- Default gateway: `y` |
| 104 | +- IPv6: `n` |
| 105 | +- DHCP server on WAN: `n` (Windows VMs have static IPs) |
| 106 | + |
| 107 | + |
| 108 | + |
| 109 | +### 8. Configure static LAN IP |
| 110 | + |
| 111 | +Option **2** again → **2** (LAN) → **n**: |
| 112 | +- IP: `192.168.20.1` |
| 113 | +- Subnet: `24` |
| 114 | +- Gateway: ENTER (LAN doesn't need a gateway) |
| 115 | +- IPv6: `n` |
| 116 | +- DHCP server on LAN: `y` |
| 117 | +- Range: `192.168.20.50` to `192.168.20.99` |
| 118 | +- Revert HTTP: `n` |
| 119 | + |
| 120 | +### 9. Final state |
| 121 | + |
| 122 | + |
| 123 | + |
| 124 | +``` |
| 125 | +WAN (vtnet0) → 192.168.10.2/24 |
| 126 | +LAN (vtnet1) → 192.168.20.1/24 |
| 127 | +``` |
| 128 | + |
| 129 | +### 10. Enable SSH |
| 130 | + |
| 131 | +Option **14** (Enable Secure Shell sshd). Default user: `admin` / `pfsense`. |
| 132 | + |
| 133 | +## Reconfigure Kali to use pfSense |
| 134 | + |
| 135 | +Until now Kali used the Proxmox host (192.168.20.1 before) as its gateway. Now pfSense owns that IP. Since Kali's static config was set with gateway 192.168.20.1, **it automatically points to pfSense**. Just verify: |
| 136 | + |
| 137 | +```bash |
| 138 | +qm guest exec 108 -- bash -c "ip route show; ping -c 2 192.168.20.1" |
| 139 | +``` |
| 140 | + |
| 141 | +And make sure the Proxmox host no longer holds `.20.1`: |
| 142 | + |
| 143 | +```bash |
| 144 | +ip addr del 192.168.20.1/24 dev vmbr0.20 |
| 145 | +# Add management IP for SSH to pfSense from the host |
| 146 | +ip addr add 192.168.20.254/24 dev vmbr0.20 |
| 147 | +``` |
| 148 | + |
| 149 | +## Verification |
| 150 | + |
| 151 | +```bash |
| 152 | +# Kali → internet via pfSense |
| 153 | +ssh root@PROXMOX 'qm guest exec 108 -- curl -s -o /dev/null -w "HTTP %{http_code}" https://google.com' |
| 154 | +# HTTP 200 |
| 155 | + |
| 156 | +# Kali → pfSense LAN |
| 157 | +ssh root@PROXMOX 'qm guest exec 108 -- ping -c 2 192.168.20.1' |
| 158 | +# 0% packet loss |
| 159 | + |
| 160 | +# SSH to pfSense from Proxmox |
| 161 | +ssh root@PROXMOX 'sshpass -p pfsense ssh admin@192.168.20.1 "ifconfig vtnet0 | grep inet"' |
| 162 | +# inet 192.168.10.2 netmask 0xffffff00 |
| 163 | +``` |
| 164 | + |
| 165 | +And confirm NAT is active on pfSense: |
| 166 | + |
| 167 | +```bash |
| 168 | +sshpass -p pfsense ssh admin@192.168.20.1 'pfctl -sn | grep -i nat' |
| 169 | +# nat on vtnet0 inet from 192.168.20.0/24 to any -> 192.168.10.2 port 1024:65535 |
| 170 | +``` |
| 171 | + |
| 172 | +Kali appears as `192.168.10.2` when connecting to Windows VMs. **This is important for attacks** — the attacker doesn't show up with their real IP (192.168.20.100) but with the firewall's, exactly like what happens when an external attacker pivots through a perimeter device. |
| 173 | + |
| 174 | +## Default security posture |
| 175 | + |
| 176 | +By default pfSense **blocks all WAN→LAN traffic**. This means: |
| 177 | +- ✅ Kali can initiate connections to Windows VMs (LAN→WAN allowed) |
| 178 | +- ❌ Windows VMs **cannot** initiate connections to Kali (WAN→LAN blocked) |
| 179 | + |
| 180 | +This reproduces the realistic scenario: an attacker on Kali has gained access, and must **pivot** from Kali into the domain without the domain being able to scan back. |
| 181 | + |
| 182 | +For more complex attack scenarios (meterpreter callbacks, reverse connections), we'll add specific rules in pfSense later. |
| 183 | + |
| 184 | +## Internet exposure |
| 185 | + |
| 186 | +Is pfSense exposed to the internet? **No.** Layers of protection: |
| 187 | + |
| 188 | +1. **Private IP**: pfSense WAN (192.168.10.2) is RFC1918, not routable |
| 189 | +2. **No port forwarding**: the Proxmox host doesn't forward any port to the lab |
| 190 | +3. **pfSense firewall**: blocks all inbound WAN traffic |
| 191 | + |
| 192 | +Only the Proxmox host (95.217.226.229) is exposed, and only via SSH key + authenticated Web UI. |
| 193 | + |
| 194 | +--- |
| 195 | + |
| 196 | +*Next: Part 4 — Crowning the Domain Controllers: AD, Forests and Trusts with GOAD* |
| 197 | + |
| 198 | +*Previous: [Part 2 — The Seven Kingdoms: Deploying Windows VMs]({% post_url en/2026-04-12-ad-dfir-lab-part2-windows-vms %})* |
0 commit comments