← Main Guide Verification ↗ ← → nav F fullscreen
Capstone Server+ · Week 2

Network Topology

Three zones · one firewall · defense-in-depth, by design.

3
Network zones
6
VMs in inventory
9
LAN firewall rules

Verified live build · 2026-05-05 · ML350p Gen8 · Proxmox VE 8.2.2

What we're covering

Walkthrough roadmap

🎯 What you'll see

  • The full topology — one diagram, every component
  • Zone by zone — School LAN, DMZ, LAN
  • The firewall doing four jobs at once
  • The hardened LAN ruleset (Week 3 evidence)
  • A real packet's journey through the network
  • Where we are today & what's next

🧠 What you'll be able to answer

  • Why three subnets, not one?
  • What's the difference between DMZ and LAN here?
  • Where does NAT happen — host or pfSense?
  • Why does ping 1.1.1.1 fail from LAN but curl works?
  • How would a packet get from LinuxServer to Google?
The big picture

One diagram, every node

☁️ School LAN 10.10.0.0/16 🛡️ pfSense2 (VM 103) DNS · DHCP · Firewall · NAT WAN 10.10.110.10 DMZ 172.16.0.1/24 LAN 192.168.0.1/24 vmbr0 vmbr1 vmbr2 🖥️ Proxmox Host tctmachine · PVE 8.2.2 10.10.10.10 💻 Jumpbox (VM 101) Ubuntu 26.04 · UFW 172.16.0.100 🪟 WinSrv (102) Win Srv 2025 Eval 192.168.0.15 🐧 LinuxServer (105) Ubuntu 26.04 srv 192.168.0.20 🖱️ Linux-Ubuntu (104) Ubuntu 24.04 Desktop 192.168.0.25 📦 Also in inventory VM 100 PFsense — template, clone source for VM 103 Dashed border on VM 104 = install pending (LAN client workstation)
Zone 1 · The outside

School LAN — where the lab connects to the world

☁️

10.10.0.0/16

The school's classroom network. Provides DHCP for our pfSense WAN, hands us internet, and gives us the management path to https://10.10.10.10:8006.

What's on this side

DeviceIP
School gateway10.10.10.1
Proxmox host (mgmt)10.10.10.10
pfSense WAN10.10.110.10

Both 10.10.10.10 and 10.10.110.10 live in the same /16, so they can talk directly.

The brain of the network

pfSense2 — one box, four jobs

🛡️

VM 103 · pfSense Community Edition 2.8.1

Three NICs spanning all three subnets. Every internal packet goes through here.

WAN 10.10.110.10 DMZ 172.16.0.1 LAN 192.168.0.1

The four jobs

  • Router — moves packets between school LAN, DMZ, and LAN
  • NAT gateway — Automatic outbound mode · masquerades both internal subnets out the WAN IP
  • DHCP server — leases .100–.200 on each internal subnet
  • DNS resolver — Unbound · DNSSEC validation on · forwards to 1.1.1.1

If pfSense2 goes down, nothing on the internal subnets can reach the internet, get an IP, or look up a name.

Three logical zones

The three virtual bridges

🔵

vmbr0

School LAN / mgmt

10.10.0.0/16

Bridges eno1 physical NIC. Where we manage Proxmox from.

🟠

vmbr1

DMZ — Demilitarized Zone

172.16.0.0/24

No physical port. Hosts the jumpbox. Cannot reach LAN by default.

🟢

vmbr2

LAN — Internal

192.168.0.0/24

No physical port. Hosts the WinSrv and LinuxServer. Hardened.

Each bridge is a virtual switch inside Proxmox — VMs plug their virtual NICs into a bridge and can talk to other VMs on the same bridge.

Zone · Management

vmbr0 → the Proxmox host

🖥️

Proxmox Host

10.10.10.10

tctmachine · Proxmox VE 8.2.2

Why this zone exists

  • This is the management plane — where you SSH or hit the web UI to control everything
  • Proxmox host has its own IP on vmbr0 so the school network can reach it directly
  • pfSense's WAN side also lives here (different IP .110.10) — that's how outbound traffic exits the lab
  • If you lock yourself out of the lab, this is the entry point — through the school network to https://10.10.10.10:8006
Zone · DMZ

vmbr1 → the Jumpbox

💻

Jumpbox · VM 101

172.16.0.100

Ubuntu Server 26.04 LTS

SSH active UFW on

Why a Jumpbox?

  • Single entry point for SSH admin into the lab — one box to harden, one box to monitor
  • Lives in DMZ so even if it's compromised, the LAN's services aren't directly exposed
  • UFW restricts inbound SSH to lab subnets only (10.10.10/24, 172.16.0/24, 192.168.0/24)
  • From here you SSH to LinuxServer, RDP to WinSrv, and pivot through the DMZ → LAN firewall rule

Real-world parallel: bastion / jump host pattern in cloud architectures (AWS, Azure, GCP all do this).

Zone · LAN (where the services live)

vmbr2 → WinSrv + LinuxServer + Linux-Ubuntu Desktop

🪟

WinSrv · VM 102

192.168.0.15

Windows Server 2025 Eval · 24H2

Future: AD · DNS · DHCP · IIS

🐧

LinuxServer · VM 105

192.168.0.20

Ubuntu Server 26.04 LTS

Future: NGINX · MariaDB · NTP

🖱️

Linux-Ubuntu · VM 104

192.168.0.25

Ubuntu 24.04 Desktop · GUI

Role: Client tester · Firefox

All three static IPs (.15 · .20 · .25) — outside pfSense's DHCP pool (.100–.200) — so leases never clash. Dashed card = install pending.

Defense in depth

The hardened LAN ruleset

9 rules on vmbr2's firewall — order matters (top down, first match wins). This is what separates "default allow LAN to any" from real production posture.

#ActionSource → DestDescription
1PASSLAN → pfSense (ICMP echoreq)Ping the gateway only
2PASSLAN → pfSense (UDP/123)NTP to local server
3PASSLAN → pfSense (UDP/53)DNS to local resolver
4BLOCKLAN → pfSense (any other)No web GUI / SSH access from LAN VMs
5BLOCKLAN → DMZ_NETNo lateral move into DMZ
6BLOCKLAN → RFC1918No reach to other private subnets
7PASSLAN → OUTBOUND_WEB alias (TCP/UDP)Internet-bound · ports 80, 443, 53, 123 only
8PASSLAN → port 5985–5986WinRM / Windows Update
9PASSLAN → port 445SMB

Default-deny catches everything else. ping 1.1.1.1 from LAN fails — by design, ICMP only allowed to gateway. Anti-fingerprinting + anti-data-exfiltration posture.

Real packet, real path

What happens when LinuxServer runs curl https://www.google.com

1
LinuxServer (192.168.0.20) wants to reach www.google.com. First, DNS lookup: queries 192.168.0.1 (its DNS server, which is pfSense Unbound).
2
pfSense LAN firewall · rule 3 matches: PASS UDP/53 to "This Firewall". Unbound resolves recursively → returns 142.251.x.x.
3
LinuxServer sends a TCP SYN to 142.251.x.x:443. Default route via 192.168.0.1 → packet arrives at pfSense LAN interface.
4
pfSense LAN firewall · rule 7 matches: TCP to OUTBOUND_WEB alias (port 443 ✓). Forward chain: PASS.
5
NAT (Automatic Outbound) rewrites the source from 192.168.0.20 to pfSense's WAN IP 10.10.110.10, picks a random source port, records the translation in the state table.
6
Packet egresses out vmbr0 through eno1, hits the school LAN, goes to the school gateway 10.10.10.1, and out to the internet.
7
Google's response comes back to 10.10.110.10, pfSense looks up the state, rewrites destination back to 192.168.0.20, returns it to LinuxServer. TLS handshake completes, HTML returned, browser/curl is happy.
Build status · 2026-05-05

Where we are today

✅ Done

  • Hardware verified · RAID 5 · Proxmox VE 8.2.2 installed
  • 3 bridges (vmbr0/1/2) created and active
  • 6 VMs in inventory · 4 running · 1 install pending · 1 template
  • pfSense2 routing all traffic · DHCP + DNS + auto-NAT live
  • Jumpbox UFW configured · internet reachable
  • WinSrv at static .15 · LinuxServer at static .20
  • LAN firewall hardened — 9-rule defense-in-depth

📋 Coming up

  • WinSrv: timezone fix · Windows Updates · Active Directory + DNS install
  • LinuxServer: NGINX · MariaDB · NTP · UFW
  • VM 104: install Ubuntu Desktop · static .25 · Firefox-based client testing
  • pfSense: change admin password (currently default) · rename interface labels
  • Jumpbox: SSH hardening (port, key auth, root disable)

Critical: change pfSense admin password before next class.

That's the network

Questions?

Three zones · one firewall · 5 VMs · 9 hardened rules — all built, all verified, all documented.

10.10.0.0/16 172.16.0.0/24 192.168.0.0/24

Full verification doc: week2-verification.html · Service install playbook: week2.html

1 / 13