Building a Secure Virtual OPNsense 26.1 Firewall with VLANs, DMZ, and CARP High Availability

 

Building a Secure Virtual OPNsense 26.1 Firewall with VLANs, DMZ, and CARP High Availability

In this guide, we’ll walk through setting up OPNsense 26.1 as a primary gateway in a virtualized environment using Hyper-V, with VLAN segmentation, a DMZ, staged VPN, and optional CARP failover for high availability.

This architecture ensures strong isolation, centralized traffic control, and enterprise-grade security — all without joining the firewall or hypervisor to Active Directory, reducing the attack surface.

1️⃣ Architecture Overview

Logical Design

                     Internet
                         │
                 [External vSwitch]
                         │
                     WAN (OPNsense)
                ┌──────────────────┐
                │    OPNsense       │
                │ VLAN Gateways + HA│
                └──────────────────┘
                         │
               [Internal vSwitch - Trunk]
                         │
      ┌───────────────┬───────────────┬───────────────┐
      │               │               │               │
  VLAN 10          VLAN 20          VLAN 30         VLAN 99
 Servers           Clients           DMZ           Management

Key Principles:

  • Hyper-V virtual switches = Layer 2 only

  • OPNsense = Layer 3 routing, VLAN gateways, firewalling, DHCP

  • DMZ isolated from LAN, only controlled access to internal systems

  • Management VLAN (99) restricted to admin workstations

  • VPN pre-staged but disabled for external access

VLAN Layout

VLANPurposeSubnetGateway
10Internal Servers192.168.10.0/24192.168.10.1
20Workstations192.168.20.0/24192.168.20.1
30DMZ192.168.30.0/24192.168.30.1
99Management192.168.99.0/24192.168.99.1

2️⃣ Deployment Steps

Step 1 — Hyper-V Virtual Switch Setup

  1. External vSwitch (WAN) — connected to physical NIC, only for OPNsense WAN.

  2. Internal vSwitch (LAN Trunk) — connects OPNsense LAN NIC + all internal VMs. VLAN-tagged traffic flows here.

  3. Private SYNC Switch — dedicated for CARP/pfsync/config sync (if using HA). No other VMs connected.

Step 2 — OPNsense VM Creation

  • OS: FreeBSD 64-bit

  • CPU: 2 cores

  • RAM: 4GB

  • Disk: 20GB

  • NIC1 → WAN (External vSwitch)

  • NIC2 → LAN (Internal Trunk vSwitch)

  • NIC3 → SYNC (if HA)

Step 3 — Install & Configure OPNsense

  • Boot from 26.1 DVD ISO

  • Guided ZFS partitioning

  • Root password set

  • Assign interfaces: WAN, LAN, optionally SYNC

Step 4 — VLAN Configuration

  1. Interfaces → Other Types → VLAN → Add VLANs on LAN trunk

  2. Assign static gateway IPs for each VLAN

  3. Configure DHCP per VLAN (optional)

  4. Firewall rules for inter-VLAN traffic and isolation

Step 5 — DMZ Setup

  • VLAN 30 isolated

  • Only required WAN port forwards

  • DMZ → LAN = blocked

  • LAN → DMZ = restricted (database or management ports only)

  • Enable IDS/IPS on DMZ + WAN

Step 6 — Staged VPN

  • Pre-configure OpenVPN or WireGuard

  • Create server and client certificates

  • Leave VPN disabled and no WAN rules exist

  • Optional internal rules pre-created but inactive

Step 7 — Admin Account Setup

  • Create mitigation admin user

  • Full GUI + CLI access

  • Restricted to Management VLAN (99)

  • Strong unique password + TOTP MFA

  • SSH key-based auth; password login disabled

  • Separate Hyper-V local admin account, no AD dependency

✅ PART 1 — Configuration Audit Checklist

Before going live:

πŸ” 1️⃣ Identity & Access Control

Firewall:

  • Default password changed

  • Root login restricted

  • Named admin account(s) (e.g., mitigation)

  • MFA (TOTP) enabled

  • SSH limited to Management VLAN + key-based only

  • GUI limited to VLAN 99

  • Logout timeout configured

Hyper-V Host:

  • Not domain joined

  • Built-in Administrator renamed

  • Separate admin account created

  • RDP restricted to Management VLAN

  • Windows Firewall enabled

  • Unused services disabled

🌐 2️⃣ Network Segmentation

  • VLANs configured & gateways verified

  • DHCP only where required

  • Explicit inter-VLAN rules

  • DMZ cannot initiate to LAN

  • Management VLAN isolated

🌍 3️⃣ WAN & NAT Security

  • No GUI/SSH from WAN

  • Only required port forwards (DMZ)

  • Outbound NAT verified

  • UPnP disabled

  • Bogon/private networks blocked

πŸ›‘ 4️⃣ Intrusion Detection / Protection

  • IDS/IPS enabled on WAN + DMZ

  • Rulesets updated

  • Logging enabled

πŸ”’ 5️⃣ Services Hardening

  • DNS Resolver (Unbound) hardened + DNSSEC

  • NTP restricted to internal

  • VPN configured but disabled

πŸ“Š 6️⃣ Logging & Monitoring

  • Firewall and auth logging enabled

  • Log retention configured

  • Time synchronized (NTP)

  • Config backup exported & automatic backups enabled

πŸ’Ύ 7️⃣ Backup & Recovery

  • OPNsense config exported

  • Hyper-V VM checkpoints removed

  • Offline copy stored securely

  • Restore procedure tested

🧠 8️⃣ Architecture Review

  • No AD dependency

  • Management VLAN access limited

  • DMZ cannot trust LAN

  • OPNsense = default gateway for all VLANs

If every box is checked — you are production-ready.

πŸ” PART 2 — High Availability with CARP Failover

HA Architecture Overview

  • Two OPNsense nodes (A/B)

  • WAN NIC + LAN trunk NIC + dedicated SYNC NIC

  • Hyper-V switches: vSwitch-WAN, vSwitch-LAN-Trunk, vSwitch-SYNC

Step 1 — Initial Setup

  • Same version (26.1)

  • Same VLAN layout & interface names

  • Unique static IPs

  • Do NOT configure CARP yet

Step 2 — XMLRPC Config Sync

  • Enable sync from primary → secondary

  • Include: firewall rules, NAT, VIPs, DHCP, VPN

  • Use dedicated “ha-sync” account

Step 3 — CARP Virtual IPs

  • Create VIP per interface on primary

  • Unique VHID + strong shared secret

  • Secondary syncs automatically via XMLRPC

Step 4 — Enable pfsync (State Sync)

  • Assign SYNC interface

  • Enable pfsync

  • Ensures active firewall failover preserves sessions

Step 5 — Test Failover

  • Power off primary → verify secondary assumes VIPs

  • Internet and inter-VLAN routing continue

  • Restore primary → resumes backup role

Hyper-V Notes:

  • MAC spoofing enabled on firewall VMs

  • SYNC network isolated

  • Both nodes patched simultaneously

πŸ” CARP High-Availability Hardening Checklist

1️⃣ Dedicated SYNC network

  • Private switch, only firewalls connected

  • Firewall rules allow pfsync/XMLRPC/CARP only

2️⃣ CARP VIP Protection

  • Strong unique VHID secrets

  • Preemption controlled

3️⃣ Hyper-V Hardening

  • MAC spoofing only for firewall VMs

  • Promiscuous mode disabled

  • Management access restricted

4️⃣ pfsync Hardening

  • Bound to SYNC only

  • Not exposed to LAN/WAN

5️⃣ XMLRPC Security

  • Dedicated admin

  • Restricted to SYNC

  • Not accessible from other VLANs

6️⃣ Management Plane Isolation

  • GUI & SSH → VLAN 99 only

  • MFA enabled

7️⃣ Split-brain Prevention

  • Reliable low-latency SYNC

  • Demotion monitoring enabled

8️⃣ WAN Failover Controls

  • Gateway monitoring enabled

  • Logs monitored

9️⃣ Logging & Alerting

  • CARP state changes logged

  • Alerts for failover & demotion

πŸ”Ÿ Patch & Version Control

  • Both nodes identical

  • IDS rules synced

  • Upgrade procedure tested

1️⃣1️⃣ VLAN Policy Verification

  • DMZ → LAN blocked

  • Management VLAN isolated

1️⃣2️⃣ Backup & Recovery Strategy

  • Export configs

  • Document VIPs, VHIDs, secrets

  • Test restore

1️⃣3️⃣ Failover Testing Matrix

ScenarioExpected Result
Primary powered offSecondary takes over
SYNC disconnectedAlert + no split brain
WAN link downFailover
High CPU load primaryStable
Manual CARP demotionClean transition

Avoid: Reusing VHIDs, exposing SYNC, forgetting MAC spoofing, WAN GUI on secondary, untested failover.

 Final Result

  • VLAN segmentation 

  • DMZ isolated 

  • VPN staged but disabled 

  • No AD dependency 

  • Management isolation 

  • Enterprise-grade HA with CARP 

  • Stateful failover 

  • Configuration sync 

This is a professional Tier-0 virtual firewall deployment suitable for high-security virtual environments.

Location: Orangeburg, SC 29115, USA

Comments

Post a Comment

Got something to say? Drop a comment below — let’s chat!

Popular posts from this blog

Proxmox VE + full Kubernetes (kubeadm) step-by-step

  Production-ready guide: Proxmox VE + full Kubernetes (kubeadm) step-by-step A practical, end-to-end walkthrough to deploy a hardened Proxmox VE environment and run a production-grade Kubernetes control plane and worker nodes (kubeadm). Includes HA control-plane, etcd considerations, load-balancing, networking (Calico), storage (Longhorn + option for Ceph), security hardening, backups, and monitoring. This blog assumes you have basic Linux + virtualization familiarity and a small cluster of physical servers for Proxmox (3+ nodes recommended for HA). Where choices exist I explain trade-offs and give concrete commands and config snippets you can copy. Outline Goals & prerequisites Logical architecture (ASCII diagram) Prepare Proxmox VE hosts (install & base hardening) Proxmox networking and storage planning Create cloud-init VM template for Kubernetes nodes Deploy VMs for Kubernetes control plane and workers Provision HA load balancer for kube-api (H...
Read more

Monitoring Virtualized Environments with Graylog: A Complete Guide

  Monitoring Virtualized Environments with Graylog: A Complete Guide Virtualization has become the backbone of modern datacenters, but as environments grow, so does the challenge of monitoring them effectively. Whether you’re running VMware vSphere, Hyper-V, Proxmox, KVM, Xen, or Nutanix , log visibility is essential for performance, capacity planning, and security. Graylog , with its flexible pipelines, dashboards, and alerting capabilities, provides a powerful centralized logging solution for virtualized infrastructures of all sizes. This guide walks through everything you need to know to monitor your virtual environment using Graylog—from collecting hypervisor logs to building dashboards and alerts that actually matter. Why Graylog for Virtualization Monitoring? Virtualization platforms all generate significant amounts of structured and unstructured log data: Host health VM lifecycle changes Storage access Virtual network changes Failovers and migrations ...
Read more