A commercial UTM appliance and a Windows-only VPN concentrator are the default answer most vendors sell for perimeter security. On a real production network, we replaced that default with a stack built entirely from open-source components — and it has been carrying real traffic, real remote users, and real intrusion-detection load ever since. This is the architecture, what it replaced, and the mistakes that got caught along the way.
The Architecture
The Stack, Piece By Piece
Four components, each replacing a commercial equivalent, each chosen for a specific reason — not just "because it's free."
OPNsense replaced the legacy commercial UTM as the perimeter firewall and router for the whole site. It's the FreeBSD-based fork with a genuinely usable web UI, a real plugin ecosystem (Suricata and Unbound both ship as first-class plugins, not bolt-ons), and no per-appliance or per-seat licensing — the cost curve for growing a network doesn't bend upward the way it does with a commercial box.
WireGuard road-warrior VPN gave a distributed workforce — dozens of remote users across the country, no central office network to fall back on — a fast, modern alternative to the old concentrator. It was rolled out user by user, verified individually rather than pushed as one big-bang cutover.
Suricata runs inline on the WAN interface with 7,700+ live rules, inspecting real traffic rather than just logging a mirrored copy of it. See the full breakdown of what that actually means — and a real mistake worth learning from — on the Security page's IDS section.
DNS-based content filtering was a genuine build-vs-buy decision. A dedicated appliance like Pi-hole or AdGuard Home was the obvious first answer, but neither has a real high-availability or role-based-access-control story for multiple admins. OPNsense's own Unbound resolver with Extended Blocklists solved the same problem without adding a new single point of failure — sometimes the right architecture call is the boring one.
A Real Root-Cause: NAT/Firewall-State Desync
A recurring reachability problem across a double VPN tunnel hop looked, on the surface, like a routing bug. It wasn't — it was a live firewall alias whose in-kernel state table had silently desynced from its own saved configuration. Re-applying the identical config fixed it immediately. The lesson that now applies to every engagement: verify the running state of a firewall or routing rule, never just the saved config on disk. The two can drift apart without any error, alert, or log entry to say so.
What Else We Can Build — An Offering, Not a Delivered Project
Everything above — the OPNsense edge, the WireGuard mesh, the inline Suricata IDS, the native DNS filtering — is real, running infrastructure with real traffic on it. One piece of the open-source stack we have not shipped in production yet is directory services: every real Active Directory domain controller in our project history has been proprietary Windows Server, not open-source.
What we can do, as a capability available on request: architect and deploy directory services — user accounts, group policy equivalents, Kerberos authentication — on fully open-source infrastructure using Samba4 AD DC or FreeIPA, for organizations that want to break the Windows Server licensing dependency across the whole stack, not just the network layer. This is a sellable capability built on the same open-source engineering discipline shown above — honestly framed as available-on-request, not a case study we're claiming already shipped.
Want this architecture on your network?
See the full offering — firewall, VPN, IDS, and optional open-source directory services — on the Services page, or read how the same investigate-before-you-fix discipline hardened this very site.