Segmented SMB Network on OPNsense

TL;DR — Design for a fictional 40-person company with a head office and a branch: five security zones behind a default-deny OPNsense firewall, Suricata IPS, DNS filtering, a certificate-based IPsec tunnel between sites, remote access with TOTP, and hardened administration. The firewall policy is written once as code and drives both the documentation and an automated, harmless reachability checker. Deliverable: design, policy as code and tooling, ready to build; lab results not yet measured.

1. Problem

• Context: a fictional professional-services company, 40 staff in three departments, a head office and one branch, and a public website. Today everything sits on one flat network.
• Why it matters: on a flat network one infected laptop can reach every server, the backups and the firewall's own admin page. Guests on the Wi-Fi share that network too.
• Requirements:
  1. Staff reach the internet and only the internal services they need.
  2. Guests reach only the internet.
  3. The website is the only service published to the internet (VPN endpoints aside).
  4. A compromised workstation or web server can't reach management interfaces or other zones.
  5. The branch uses head-office services over an encrypted tunnel; remote staff connect with MFA.
  6. Administration happens only from a dedicated network, with MFA, and every decision is logged centrally.
• Constraints: free and open-source tooling; isolated lab; addresses from private and documentation ranges.
• Success criteria: every flow in the policy behaves as designed when tested from inside each zone, and the manual checks (tunnel encryption, MFA, IPS, DNS filtering) pass.

2. Architecture

The full IP plan and every tested flow with its justification are generated from the policy: docs/ip-plan.md and docs/rules.md.

3. Build

Step-by-step guides for OPNsense 26.7 in docs/opnsense/:

1. Install and interfaces — Proxmox bridges, VLANs, addressing.
2. Firewall rules — aliases and one rule per allowed flow, explicit block-and-log at the end of each zone.
3. NAT and egress — one published service; servers and MGMT have no direct internet access.
4. Suricata IPS — ET Open rules, drop only high-confidence signatures.
5. DNS filtering — Unbound blocklists; clients can't bypass the resolver.
6. Site-to-site IPsec — every parameter with its reason.
7. OpenVPN + TOTP — certificate + password + one-time code.
8. Admin hardening — MGMT-only GUI/SSH, MFA, logs to Wazuh, encrypted backups.

4. Validation plan

• Automated reachability check (docs/validation.md): from a probe host in each zone, python3 -m labtools.checker --zone <ZONE> tests all 56 flows in the policy with ordinary TCP connections, UDP echoes and DNS queries to the lab's own hosts (internet-facing flows at the firewall's WAN address), and reports each as PASS, FAIL (blocked) or FAIL (allowed).
• Manual checks (tests/test-plan.md): IPsec traffic is encrypted on the wire, VPN login fails without the TOTP code, the IPS raises an alert on a harmless test signature, blocked domains don't resolve, and a failed admin login reaches Wazuh.

5. Deliverables and measurement

Delivered in this repository:

• Architecture, zone design and IP plan for two sites.
• A policy matrix of 56 flows (including the full set of ports an Active Directory client needs), each with a written justification, validated in CI (unknown zones, same-zone flows, duplicates or missing justifications fail the build).
• Eight OPNsense configuration guides and a guide to publishing firewall configs without secrets.
• A reachability checker and target listener covered by an automated test suite (including real TCP/UDP probes), plus a CI check that the generated documentation matches the policy.

How results are measured:

6. Design lessons and roadmap

• Check licence limits before choosing a product. The FortiGate-VM trial looked like the obvious choice but couldn't hold even the basic zone design; checking first avoided building on a dead end.
• Write the policy once. Keeping zones and flows in one YAML file, with the docs and the checker generated from it, removes the usual drift between "what the diagram says" and "what the firewall does".
• Test the denies, not just the allows. A default-deny policy is only proven when blocked flows are tested from inside each zone; the policy lists them explicitly for that reason.
• Probes need something to answer. An allowed flow to a port with no service looks exactly like a blocked one, so the design includes a listener and marks hosts whose real services already answer.
• Designing for real clients changes the details. Domain-joined machines need the domain controller for DNS and Lab 01's agents need their own flows; both surfaced only when writing the step-by-step guides.

Roadmap: build both firewalls from the guides, run the checker from all six zones and the manual checks, publish the measured conformance here, and later compare with a licensed FortiGate on the same policy.

7. Reproduce it yourself

• Clone: git clone https://github.com/santorest/lab-02-segmented-network.git
• Download bundle: from the portfolio site (SHA-256 shown next to the download).
• Estimated time: 1–2 days.
• Teardown: delete the VMs and bridges; no cloud resources are used.

8. Mapping

All testing is performed in an isolated lab environment I own. No real organization's data, hostnames or configurations are included.