OPNsense · Self-assessment
Knowledge checks
Every knowledge check in this course, in curriculum order. Each link opens the page at its quiz. The questions are auto-graded in the browser and nothing is recorded — a wrong answer costs you only the explanation, which is the part worth reading.
- Knowledge checks
- 288
- Parts covered
- 48
- Of all lessons
- 100%
Part I
Networking Foundations for Firewall Administrators
6 checks
- Ethernet, MAC and ARP — the Layer 2 the firewall operator must readFrames, MAC addresses, ARP, broadcast domains and why a firewall operator must read Layer 2 evidence.→
- IPv4 and IPv6 addressing, CIDR and subnetsHow addresses, masks and subnets work; what a /24 means; how the firewall operator uses them every day.→
- TCP, UDP and ICMP — the protocols every firewall rule decides onWhat each transport protocol does; how a stateful firewall tracks connections; why ICMP is more than ping.→
- Gateways, default routes and asymmetric routingHow a host and a firewall decide which router to send to; how asymmetric routing breaks stateful filtering.→
- DNS for the firewall operatorHow DNS works at the resolution level the firewall cares about; what DNSSEC is and is not; split-horizon DNS.→
- DHCP for the firewall operatorHow DHCP works at the depth the firewall operator needs; lease behaviour; relay; reservations; DHCPv6.→
Part II
Routing Fundamentals
6 checks
- Routing tables and the control planeHow OPNsense builds its routing table — direct routes, static routes, dynamic protocols — and how that table differs from the forwarding table the kernel uses to move packets.→
- Connected, static and default routesThe three route types every OPNsense operator must understand: connected, static, default — how each is added, when each is used, and how to verify each is doing what you expect.→
- Longest prefix match and the routing decisionWhy the routing table is a longest-prefix-match lookup, not a "best route" decision; how FreeBSD walks the table; the edge cases that turn into incidents.→
- Asymmetric routing and PF stateWhy asymmetric routing silently breaks stateful filtering; how to detect it with PF state and traceroute; the OPNsense configuration changes that fix it.→
- Policy routing and source-based routingHow OPNsense routes traffic by source rather than destination; gateway groups and per-rule gateway selection; when policy routing is the right tool and when it is the wrong one.→
- Routing troubleshooting and evidenceA systematic approach to routing incidents on OPNsense — which commands to run, in which order, what each tells you, and how to read the evidence they produce.→
Part III
Stateful Firewalling and PF
6 checks
- Stateful vs stateless filteringWhat "stateful" means for a firewall, what it buys you, what it cannot do, and when stateless filtering is still the right answer.→
- PF rule evaluation orderHow PF walks the ruleset, what "first match wins" really means, and how to construct a ruleset whose order is deliberate.→
- State creation and tracking in PFHow PF creates state for TCP, UDP, ICMP and other protocols; the timeouts that apply; what the state entry actually contains; and how to read state for diagnostics.→
- Quick and non-quick rulesWhat the quick modifier really does, when to use last-match-wins, and how OPNsense exploits no-quick in specific places.→
- Tables, anchors, and include in PFHow PF tables let you match against large lists efficiently; how anchors load sub-rulesets; how include lets you organise a ruleset into files.→
- PF internals and the generated configurationHow OPNsense generates the PF ruleset from the GUI configuration; where the files live; how to read them; why you should still change configuration through the GUI.→
Part IV
OPNsense Architecture
6 checks
- OPNsense — history, design philosophy and current positionWhere OPNsense came from (m0n0wall, pfSense, the fork), the design philosophy that drives its releases, and the role it plays in 2026 networks.→
- FreeBSD as the base — services, rc.d, and what the operator noticesWhy OPNsense runs on FreeBSD (and HardenedBSD), what the rc.d service framework means in practice, and the kernel-level differences from Linux that affect day-to-day operations.→
- The configuration generation model — XML to FreeBSD to running servicesHow OPNsense stores configuration as XML, applies it to FreeBSD services on every change, and why hand-editing generated files is always wrong.→
- PF and the kernel interface — how packets actually moveHow PF interacts with the FreeBSD kernel on packet ingress and egress, what sysctl tunables affect the firewall, and where the firewall sits in the network stack.→
- The web UI and REST API surfaceHow OPNsense's web UI is built (PHP on FreeBSD, nginx, PHP-FPM), what the REST API exposes, and how authentication, authorisation and the audit trail fit together.→
- Firmware updates and the plugin modelHow OPNsense delivers firmware updates and plugins, what the ABI compatibility model means for plugin upgrades, and the operational discipline for safe upgrades.→
Part V
Installation and Initial Deployment
6 checks
- Hardware sizing and selection — CPU, RAM, NIC, throughputHow to size OPNsense hardware for small, medium and large deployments based on throughput, state count, VPN and IDS targets; reference architectures and anti-patterns.→
- Physical install on a dedicated appliance — BIOS, IPMI, consoleWhat an operator does in the BIOS, how to set up IPMI for out-of-band management, and the console-cable path for break-glass access during installation.→
- Virtual install on Proxmox — virtio, VLAN trunking, sizing the VMHow to install OPNsense as a VM on Proxmox VE, including NIC choice (virtio vs e1000), VLAN trunking on a single vNIC, CPU type, memory ballooning and the sizing decisions that follow.→
- Boot menu and console — single-user, reset, factory recoveryThe OPNsense boot menu, the FreeBSD boot loader, single-user mode, root password reset, factory reset, and the recovery flow when the firewall will not boot to a usable state.→
- The initial wizard — hostname, interfaces, WAN, LAN, admin passwordStep-by-step walk through the OPNsense initial wizard: hostname, domain, DNS, NTP, WAN type, LAN configuration, admin password. The right answers for production.→
- Management network isolation, NTP sources, DNS hardeningHow to design the OPNsense management plane: a dedicated management VLAN, source-restricted GUI/API access, redundant NTP and DNS, and the operational discipline that prevents lockout.→
Part VI
Hardware and Virtualisation Design
6 checks
- CPU, RAM sizing and throughput targetsHow to size an OPNsense firewall for a given throughput target; when one core is enough; AES-NI for IPsec; RAM and state-table sizing.→
- NIC selection — Intel vs Broadcom vs RealtekWhich NICs to choose for OPNsense, why Intel i210/i350/i211 are the safe default, where Broadcom and Realtek cause trouble, and what "drop-prone" actually means.→
- Offload — checksum, TSO, LRO, RSS — and what to disable for capture/IDSHow NIC offloads (checksum offload, TCP segmentation offload, large receive offload, RSS) work, why they are usually enabled, and which offloads must be disabled for packet capture and IDS workloads.→
- Virtualisation — virtio vs e1000 vs vmxnet3 on ProxmoxHow to choose the virtual NIC type for OPNsense on Proxmox VE; virtio-net with multi-queue for performance; the pitfalls of e1000 and vmxnet3; VLAN tagging on a single vNIC.→
- VLAN trunking on a single vNICHow to carry multiple 802.1Q-tagged VLANs across a single NIC or vNIC; parent interface selection, MTU concerns, and the pitfalls of asymmetric trunk configuration.→
- PCI passthrough and isolated NICsHow to give an OPNsense VM direct access to a physical NIC via PCI passthrough (VT-d); IOMMU groups; the security and performance benefits, and the configuration steps on Proxmox.→
Part VII
Interface Management
6 checks
- Interface assignments and rolesHow OPNsense assigns physical NICs and VLANs to logical interfaces; WAN/LAN/OPT role conventions; disabling unused interfaces to reduce attack surface.→
- Interface tracking and gateway failoverHow OPNsense monitors interface gateway health; how a gateway group triggers failover; when rules on the failed interface should be disabled and how to do it.→
- Static and DHCP interface configurationHow to configure an interface with a static IPv4 address, a DHCP-assigned address (when the upstream ISP uses DHCP), and IPv4 aliases for additional addresses on the same interface.→
- IPv6 on the interfaceHow to configure IPv6 on an OPNsense interface — SLAAC, static, track interface, and DHCPv6 — and the four addressing modes the operator chooses between.→
- Bridges, laggs, and bondingHow OPNsense combines interfaces — bridges (Layer 2), lagg/LACP (link aggregation), when to use each, and the operational pitfalls.→
- Wireless, loopback, and GIF tunnel interfacesHow OPNsense configures wireless interfaces (hostap), loopback interfaces for management and services, and GIF tunnel interfaces for IPv6-in-IPv4 and IPv4-in-IPv6.→
Part VIII
Management Plane Security
6 checks
- GUI exposure and source restrictionsWhy the OPNsense web GUI must never be exposed to the Internet, how to restrict it to a management network, and the firewall rules that enforce the boundary.→
- HTTPS and TLS certificates for the GUIWhy HTTP for the OPNsense GUI is never acceptable in production, how to use the built-in ACME client or an internal CA, and how to harden the TLS profile.→
- SSH administrationSecuring the OPNsense SSH service for administration: key-only authentication, restricted users, allowed ciphers, and the operational discipline of SSH as a management interface.→
- Administration networks and VLANsWhy the management plane must live on a dedicated VLAN, how to design the management network, and the source-IP restrictions that protect it.→
- MFA and TOTPAdding a second authentication factor to OPNsense administration using TOTP, integrating with freeRADIUS for centralised MFA, and managing recovery codes.→
- Accounts, groups, and role separationThe OPNsense built-in user and group model, the privilege separation it enables, and when to integrate an external identity provider for the firewall estate.→
Part IX
Firewall Rules
6 checks
- Interface rules and directionHow OPNsense applies rules on ingress to the interface, why the direction matters, and how to reason about packet flow when writing rules.→
- Rule processing orderHow PF walks the ruleset top-to-bottom, why first-match-wins matters, and how a broad rule above a specific rule shadows everything below.→
- Rule action: block, reject, passThe three core rule actions in OPNsense — pass, block, reject — when to use each, and how they affect client behaviour, diagnostics, and the firewall log.→
- Automatic rules and default allowThe auto-generated rules OPNsense produces by default, why a strict "block all" ruleset must always coexist with them, and how to disable the ones you do not need.→
- Rule scheduling and timeTime-based firewall rules in OPNsense, when scheduling is the right tool, when it is misleading, and the operational pitfalls of clock skew, DST, and timezones.→
- Rule logging and traceHow to enable and read firewall rule logs, when logging helps diagnose incidents, when it floods the log, and how the trace log works for packet-flow forensics.→
Part X
Aliases and Floating Rules
6 checks
- Host, network and port aliases — naming and when to useThe three alias types in OPNsense, naming conventions that survive team turnover, and when each alias type is the right tool.→
- Table aliases and URL feedsHow OPNsense URL Tables fetch large address lists from threat-intel and abuse feeds, the refresh cadence, and the failure modes that leave stale data blocking legitimate traffic.→
- Floating rules — purpose and multi-interface matchingWhat floating rules are for, when to use them instead of per-interface rules, and the multi-interface and direction-matching features that make them unique.→
- Floating rule direction and quick — order, shadowing and intentHow floating rules interact with direction, quick, and sequence; how the generated ruleset orders floating and per-interface rules; the shadowing traps that bite production firewalls.→
- Alias anti-patterns — overly broad tables, slow refresh, and silent failuresThe common mistakes that turn URL Tables and large aliases into operational liabilities — and how to recognise and recover from each.→
- Rule documentation and meta — why the description field is not optionalHow the OPNsense rule description, the no-action rule pattern, and disciplined metadata turn a ruleset from a wall of text into an auditable artefact.→
Part XI
Firewall States
6 checks
- State table anatomy — tuple, timeout, counters, packets, bytesWhat a PF state entry actually contains, how to read it, and how to interpret the timeout and counters that govern its lifetime.→
- State lifetimes and timeouts — TCP, UDP and ICMPHow long state entries live for each protocol, the timeout cascade through the TCP state machine, and the production tuning that keeps long-lived flows alive.→
- State inspection with pfctl — reading the state table for diagnosticsHow to use pfctl -s state, -s state -v and -si to read the state table, narrow the output with grep and the -i interface restriction, and query flows by address with pfctl -k.→
- Clearing states — pfctl -k vs pfctl -F state, and when each is rightHow to clear PF state entries with pfctl -k for targeted flows and pfctl -F state for bulk flush, and the operational discipline that picks the right tool for the change.→
- Rule changes do not affect existing state — the trap that wastes hoursWhy PF state caches the original rule decision, why existing connections continue to match the old rule, and the verification discipline that catches the trap.→
- State exhaustion and DoS — sizing, symptoms and recoveryHow PF state tables fill up under load, the symptoms of state exhaustion, tuning for capacity, and the DoS scenario where state-table pressure is the attack vector.→
Part XII
NAT Fundamentals and Outbound NAT
6 checks
- NAT fundamentals — SNAT, DNAT, and where in the packet flow each one happensHow source and destination NAT differ, where in the PF packet flow each translation occurs, and how the two combine in a stateful firewall.→
- Outbound NAT modes — automatic, hybrid, and manualHow the three outbound NAT modes in OPNsense work, what the generated PF rules look like in each mode, and when to override the automatic default.→
- Outbound NAT rule fields — interface, source, destination, translation targetHow to read every field of an outbound NAT rule, the three common misconfigurations, and how to write rules that pin specific sources to specific WANs.→
- Outbound NAT with multiple WANs — per-interface source selectionHow to pin specific subnets to specific WANs in a multi-WAN deployment, how the generated PF rules express the binding, and the return-path implications of source pinning.→
- 1:1 NAT and bidirectional NAT — when each is appropriateHow 1:1 NAT maps a public IP to a single internal host, when it is the right tool, and how BINAT (bidirectional NAT) handles bidirectional protocols and protocols without port numbers.→
- NAT anti-patterns — broad translations, ICMP breakage, MTU, and the auto-rule override trapThe most common NAT mistakes in production: overly broad source translations, NAT that breaks ICMP and traceroute, MTU black holes from translation, and unsafe edits to the auto outbound rules.→
Part XIII
Port Forwarding and NAT Reflection
6 checks
- Port forwarding packet path — Internet to internal server through OPNsenseThe complete packet path from an Internet client to an internal server through OPNsense, the DNAT and filter stages, the rdr-to clause, and why return traffic requires state.→
- Port forwarding and the associated firewall rule — automatic vs manualHow the auto-generated associated rule works, when to disable it and write a manual rule, and the security implications of each approach.→
- 1:1 NAT as destination — exposing an internal server on a public IPWhen 1:1 NAT is the right tool for inbound service exposure, how to configure it, the firewall rules it requires, and how it differs from port forwarding for the same use case.→
- NAT reflection and hairpin NAT — when it is needed and why split DNS is saferWhat NAT reflection (hairpin) is, the network loops it solves, when it is required, the security implications, and why split DNS is the preferred alternative in most production deployments.→
- Split DNS as an alternative to NAT reflection — Unbound host overridesHow to configure split-horizon DNS on OPNsense using Unbound host overrides, why split DNS is preferred over hairpin NAT, and the operational failure modes of split-horizon DNS in production.→
- Port forward troubleshooting — packet flow verification end-to-endA structured methodology for diagnosing failed port forwards — capturing on each interface, checking the rdr rule, checking the firewall rule, checking state, and identifying the five common failure points.→
Part XIV
VLANs and Segmentation
6 checks
- 802.1Q and VLAN trunking — what tagged frames actually areHow IEEE 802.1Q tagging inserts a 4-byte VLAN tag into an Ethernet frame; trunk and access ports; native VLAN; the difference between tagged and untagged traffic on a wire.→
- VLAN creation and parent interfaces — building the trunk in OPNsenseHow to create a VLAN on top of a parent interface in OPNsense; parent interface selection; assigning the VLAN to a logical interface; verifying the configuration at the kernel and PF level.→
- VLAN interface addressing and DHCP — IPs, scopes, and what listensHow to configure IPv4 and IPv6 addressing on a VLAN interface; how to run a DHCP scope per VLAN; how the firewall acts as the gateway for every subnet it carries.→
- Inter-VLAN routing basics — when the firewall is the routerHow inter-VLAN routing works in OPNsense; the firewall as the gateway for every directly attached VLAN; routing tables, automatic outbound NAT, and the rules that govern inter-VLAN traffic.→
- East-west firewalling — VLAN-to-VLAN rules and least privilegeHow to write rules for VLAN-to-VLAN traffic; the discipline of least privilege; how to enumerate service dependencies; how to keep rules narrow and auditable.→
- Default-deny segmentation — design templates for production estatesStandard VLAN design templates for production estates; how to allocate subnets, what each VLAN is for, and the default-deny rules that bind them together.→
Part XV
DMZ Architecture
6 checks
- DMZ architecture and purpose — the buffer zone between Internet and LANWhat a DMZ is, why it exists, the classic three-homed firewall topology, and the modern variants that replace it.→
- Public services in a DMZ — what to expose and what to keep privateWhich services belong in a DMZ (web, mail, DNS), which do not (databases, internal APIs, file shares), and how to design service-by-service.→
- Triple-homed firewall — WAN, DMZ, LAN interfaces and the routing decisionsHow the triple-homed firewall routes between WAN, DMZ, and LAN; the rules that govern each interface; the production patterns and traps of operating three interfaces on one firewall.→
- DMZ bastion and jump hosts — administrative access to the DMZWhy the bastion is itself a hardened host; how operators reach DMZ services through the bastion; the relationship between the bastion, the firewall, and the DMZ hosts.→
- DMZ isolated by firewall — what the DMZ can and cannot reachThe firewall rules that isolate the DMZ from the LAN; what the DMZ can reach (Internet, itself) and what it cannot reach (LAN, internal DBs); auditing the DMZ rule set.→
- DMZ monitoring and incident response — IDS, log forwarding, and what to do when a DMZ host is compromisedHow to monitor the DMZ for compromise; IDS in the DMZ; log forwarding to an immutable destination; the incident response playbook for a DMZ host compromise.→
Part XVI
IPv6
6 checks
- IPv6 address plan — /48 upstream, /64 per subnet, ULA for internalHow to lay out an IPv6 address plan for a production estate — the upstream /48, the /64 per subnet, the role of ULA, and the numbering rules an operator must follow.→
- SLAAC and Router Advertisements — how OPNsense announces the IPv6 prefixHow SLAAC builds host addresses, how Router Advertisements carry prefix information, the M/O/Prf flags, and how OPNsense acts as the IPv6 router source for a LAN.→
- DHCPv6 on OPNsense — stateful, stateless, and when each is rightDHCPv6 modes, when stateful beats SLAAC, how OPNsense configures DHCPv6 with prefix delegation, and the operational scenarios that call for each.→
- Prefix delegation from the ISP — how OPNsense receives and uses the prefixDHCPv6-PD, how the firewall requests a delegated prefix, how OPNsense tracks the upstream prefix on LAN interfaces, and the failure modes when the delegation drops.→
- IPv6 firewall rules — address families, ICMPv6, and why "block all IPv6" is dangerousIPv4 vs IPv6 firewall rules, the ICMPv6 types that must not be blocked, the address-family difference in OPNsense, and the production patterns for IPv6 rule sets.→
- IPv6 transition pitfalls — dual-stack, NAT64, AAAA records, and what breaksWhat actually breaks when IPv6 is half-implemented, dual-stack gotchas, DNS AAAA ordering, brief NAT64/DNS64, and the operational incidents that come from a partial IPv6 rollout.→
Part XVII
DHCP
6 checks
- DHCP scope and pool design — address range, gateway, DNS, lease timeHow to design a DHCP scope: address pool boundaries, gateway choice, DNS configuration, lease time tradeoffs, and the production discipline that keeps the scope correct.→
- DHCP reservations and static mappings — when to use, MAC format gotchasReservations vs static addresses, when each is right, MAC address format pitfalls, virtualisation randomisation, and the operational discipline for host inventory.→
- DHCP options 66, 67, 150, 43, and 82 — PXE, VoIP, vendor, and relayDHCP options for PXE boot (66/67), Cisco IP phones (150), vendor-specific (43), and relay agent information (82) — what they carry, how to configure, and the production scenarios that use each.→
- DHCP relay across VLANs — when the DHCP server is not on the same VLANDHCP relay fundamentals, how a relay forwards broadcasts as unicasts, OPNsense as a relay agent, the DHCP helper address pattern, and the failure modes of misconfigured relay.→
- DHCPv6 stateful vs stateless — when each is appropriate, OPNsense configDHCPv6 stateful vs stateless, when stateful beats SLAAC, OPNsense configuration for both modes, the RA flag coordination, and the production scenarios that pick one.→
- DHCP troubleshooting — common failure modes, log analysis, packet captureHow to debug DHCP failures: log analysis on the firewall, packet capture on the wire, common failure modes from missing service to firewall rules, and the diagnostic discipline that finds the cause fast.→
Part XVIII
DNS and Unbound
6 checks
- Unbound in resolver mode versus forwarder modeWhen to run OPNsense Unbound as a recursive resolver and when to run it as a forwarder — operational trade-offs, privacy, validation, and the implications for upstream DNS.→
- Unbound configuration — interfaces, ACLs, DNSSEC, prefetch, cache sizeHow to configure OPNsense Unbound for production: which interfaces to listen on, the access-list defaults, DNSSEC validation, message-cache size, prefetch, hardening options, and the operational discipline that prevents cache poisoning.→
- DNS over TLS and DNSSEC — confidentiality and validation togetherHow to configure DNS over TLS on OPNsense Unbound for upstream query confidentiality, what DoT does and does not protect against, the certificate verification discipline, and how DoT composes with DNSSEC.→
- Host overrides and split-horizon DNSHow to configure Unbound host overrides for split-horizon DNS in OPNsense — when LAN clients need different records than external resolvers, how to avoid NAT reflection, and the discipline of documenting every override.→
- DNS access lists — restricting which subnets can query the firewall resolverHow OPNsense Unbound access lists work, the action model (allow, deny, refuse, allow snoop, deny non-local), the auto-creation behaviour for listening interfaces, and the discipline of treating the ACL page as part of the change review.→
- DNS troubleshooting — unbound-control, drill, tcpdump, SERVFAIL patternsHow to diagnose DNS failures on OPNsense Unbound — the diagnostic command sequence, SERVFAIL pattern recognition, common upstream and DNSSEC failure modes, and the discipline of evidence-first diagnosis.→
Part XIX
Multi-WAN and Gateway Groups
6 checks
- Multi-WAN concepts — redundancy, capacity, segregationWhen and why multi-WAN — the three production reasons (redundancy, capacity, segregation), the failure modes each one addresses, the architectural patterns OPNsense supports, and the cost of each pattern in operational complexity.→
- Gateway monitoring and dpinger — the probe, the thresholds, the triggersHow OPNsense monitors gateway health with dpinger — the ICMP probe, the loss and latency thresholds, the trigger levels (member down, packet loss, high latency, or both), and the operational discipline of setting thresholds deliberately.→
- Gateway groups and tiers — Tier 1 primary, Tier 2 failover, Tier 3 load balanceHow OPNsense gateway groups compose failover and load balancing — tier numbering, the trigger-level decision, combining load balancing with failover across five tiers, and the policy-routing pattern that wires groups into firewall rules.→
- Policy routing with gateway groups — sending specific traffic over specific WANsHow to wire OPNsense gateway groups into firewall rules through policy routing, when policy routing overrides the system default, the reply-to mechanism that prevents asymmetric routing, and the discipline of explicit Gateway fields on every relevant rule.→
- Multi-WAN NAT rules — outbound NAT per WAN, source address translationHow OPNsense outbound NAT works in multi-WAN deployments — automatic NAT per interface, hybrid NAT, manual NAT rules per gateway, the relationship between NAT and policy routing, and the verification of effective source translation.→
- Multi-WAN troubleshooting — false failovers, asymmetric routing, monitoring target issuesDiagnosing the recurring multi-WAN failures — false failovers from a misconfigured monitor IP, asymmetric routing from policy routing, monitoring targets that lie, and the discipline of evidence-based diagnosis across gateway, NAT, and rule layers.→
Part XX
VPN Fundamentals
6 checks
- VPN concepts — tunnelling and encryption, and what a tunnel actually isWhat a VPN is at the packet level, how a tunnel wraps one packet inside another, what encryption protects and does not protect, and the difference between transport and tunnel mode that the firewall operator has to read.→
- VPN authentication and authorisation — who is on the other end, and what they can doHow VPNs authenticate the peer (pre-shared keys, certificates, public keys), how authorisation maps an authenticated identity to permitted traffic, and the failure modes of misaligned auth and authz on production firewalls.→
- VPN routing and tunnel interfaces — putting the tunnel inside the routing tableHow a VPN tunnel becomes a routing interface, how OPNsense installs routes for the tunnel subnet, how policy routing interacts with VPN traffic, and the production routing failures that break otherwise-valid tunnels.→
- Remote access vs site-to-site — the two shapes of VPN trafficThe architectural difference between remote-access VPNs (many clients to one network) and site-to-site VPNs (network to network), the design implications for routing, addressing, authentication, and the operational patterns that fit each.→
- VPN protocol comparison — IPsec, WireGuard and OpenVPN at the firewallHow IPsec, WireGuard and OpenVPN differ in architecture, performance, configuration, NAT traversal, firewall traversal, and the production scenarios that fit each protocol on OPNsense.→
- VPN design decisions — picking protocol, topology, addressing and authenticationThe architectural decisions every VPN deployment has to make — protocol, topology, addressing, authentication, routing policy — and the operational implications of each choice for an OPNsense production estate.→
Part XXI
WireGuard
6 checks
- WireGuard concepts and keys — the cryptographic identity of a peerWireGuard architecture, the cryptographic key model (Curve25519 key pairs), the concept of peers and endpoints, how a handshake produces session keys, and the operational discipline of managing WireGuard keys on OPNsense.→
- WireGuard AllowedIPs and routing — the most consequential line in the configurationHow WireGuard AllowedIPs authorises inner source IPs, how the list becomes the routing table, how overlapping AllowedIPs break routing, and the operational discipline for managing AllowedIPs at scale on OPNsense.→
- WireGuard firewall rules and NAT — the rules that let VPN traffic throughHow OPNsense firewall rules interact with WireGuard traffic, how to write rules that permit (and deny) tunnel traffic deliberately, how NAT applies to VPN flows, and the production patterns for split-tunnel and full-tunnel rule sets.→
- WireGuard site-to-site — building tunnels between networksHow to build a WireGuard site-to-site tunnel on OPNsense, from address planning through peer configuration, AllowedIPs, firewall rules, and verification of the bidirectional flow with packet capture.→
- WireGuard remote access — VPN for individual users, full-tunnel and split-tunnelHow to build a WireGuard remote-access deployment for individual users, the addressing plan for many peers, the choice between full-tunnel and split-tunnel routing, the firewall rules and NAT for full-tunnel, and the operational patterns for managing many peer entries.→
- WireGuard troubleshooting — diagnosing tunnels that do not come upThe diagnostic sequence for WireGuard failures — handshake, transport, AllowedIPs, firewall, routing — the evidence each layer produces, and the most common production failures with their fixes.→
Part XXII
IPsec
6 checks
- IPsec concepts — IKEv1 vs IKEv2, transports, and the tunnel building blocksIPsec fundamentals for firewall operators: the IPsec protocol suite, the difference between IKEv1 and IKEv2, transport vs tunnel mode, AH vs ESP, and the building blocks a Phase 1 / Phase 2 negotiation needs on OPNsense.→
- IPsec Phase 1 and Phase 2 — authentication, key exchange, and lifetimesHow IKE Phase 1 establishes the IKE SA, how Phase 2 establishes the ESP SAs, the fields each phase negotiates, how lifetime works, how OPNsense maps the GUI forms to the IKE messages, and the rekeying the operator has to understand.→
- IPsec proposals and ciphers — encryption, integrity, and DH group choicesIPsec cryptographic choices for production: AES-GCM and ChaCha20-Poly1305 AEAD modes, SHA-2 HMACs, DH groups 14/19/20/31, why 3DES and SHA-1 are unsafe, PFS, and how to build proposals that are both strong and interoperable on OPNsense.→
- IPsec route-based vs policy-based — how OPNsense wires the tunnel into the firewallThe two ways IPsec connects to the routing table on OPNsense: policy-based VPN, where traffic selectors drive encapsulation, and route-based VPN, where a virtual interface (VTI) is the next hop. The config models, the operational differences, and how to choose between them.→
- IPsec site-to-site on OPNsense — building, configuring and verifying a tunnelA site-to-site IPsec deployment on OPNsense: prerequisites, Phase 1 and Phase 2 configuration, certificate or PSK setup, VTI interface and routing, firewall rules, the certificate management cases, and the end-to-end verification that confirms the tunnel is actually carrying traffic.→
- IPsec NAT-Traversal and MTU — encapsulating through NAT, encapsulating within a wireHow IPsec tunnels survive a path that includes NAT (NAT-T, UDP 4500, the 4-byte ESP-in-UDP header), why IPsec MTU is lower than the underlying wire MTU, how to detect and fix path MTU problems, and the configuration knobs OPNsense exposes for both.→
Part XXIII
VPN Troubleshooting
6 checks
- VPN diagnostic methodology — the layered evidence-first approachA repeatable diagnostic methodology for VPN failures: the four layers (negotiation, authentication, routing, firewall/NAT/MTU), the evidence-first discipline that prevents diagnosis from destroying the cause, and the operational playbook for a non-working IPsec or WireGuard tunnel.→
- VPN negotiation failures — proposal mismatches, identifier errors, network reachabilityThe recurring IPsec negotiation failures — NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, identifier mismatch, IKE_AUTH failures, peer unreachability — the charon.log error patterns for each, and the operational playbook that finds and fixes the cause.→
- VPN authentication and certificate failures — diagnosing AUTHENTICATION_FAILED, expiry, and chain errorsA focused diagnostic playbook for VPN authentication failures: PSK mismatches, certificate expirations, certificate chain verification failures, identifier mismatches, the WireGuard public-key handshake, and the operational patterns that prevent each.→
- VPN routing failures — when the tunnel is up but traffic does not reach the remote subnetVPN routing failures for IPsec and WireGuard: VTI mis-wiring, Phase 2 selector mismatches, AllowedIPs routing gaps, multi-WAN interactions, asymmetric routing across the tunnel, and the diagnostic playbook that localises the failure.→
- VPN MTU and fragmentation — path MTU discovery, MSS clamping, and the ICMP that disappearsMTU and fragmentation failures on VPN tunnels: encapsulation overhead, ICMP black-holes, TCP MSS clamping vs interface MTU clamping, the difference between IPsec route-based and policy-based MTU, and the diagnostic that distinguishes MTU from routing failures.→
- VPN DNS after tunnel up — split-horizon DNS, resolver selection, and the surprisesDNS behaviour on a working VPN tunnel: name resolution across the tunnel, split-horizon DNS, resolver selection per subnet, the Unbound access list, the surprises when the DNS server on the remote side is not what the LAN was expecting, and the operational playbook for cross-tunnel DNS.→
Part XXIV
PKI and Certificates
6 checks
- PKI fundamentals — the cryptography the firewall operator must understandWhat a public key infrastructure actually is, how X.509 certificates chain, what a CA signs, and why every firewall operator must read a certificate before trusting it.→
- Running an internal CA on OPNsenseHow to operate an internal certificate authority on OPNsense — root and intermediate setup, certificate authority management, distribution of the trust anchor, and the production discipline that keeps it healthy.→
- Certificate signing requests — what a CSR really containsWhat a CSR is, what the fields mean, how to generate one for OPNsense services, how to decode and verify a CSR before sending it to a CA, and the production mistakes that lead to invalid certificates.→
- Importing certificates and distributing the trust anchorHow to import certificates and CA chains into OPNsense, how to assign certificates to services, how to distribute the CA certificate to verifiers, and how to diagnose the chain-not-trusted failure when it surfaces.→
- ACME and automated certificate renewalHow the ACME protocol works, how to use the OPNsense os-acme-client plugin, the difference between HTTP-01 and DNS-01 challenges, and the production discipline for short-lived automated certificates.→
- Certificate expiry monitoring — the alert that prevents the outageWhy certificates expire and why expiry monitoring is non-optional, how to monitor certificate expiry from OPNsense and from external probes, how to set thresholds and alert routing, and how to design an expiry monitoring system that catches failures before they cause outages.→
Part XXV
Authentication and Identity
6 checks
- Local users and groups — the firewall’s first identity storeHow to design local users and groups on OPNsense, how group membership grants permissions, how the local database compares with external identity stores, and the operational discipline for managing local accounts at scale.→
- Privilege separation and roles — least privilege on the firewallHow to design role-based access on OPNsense, how to grant page-level and API-level permissions, how to apply least privilege to operator workflows, and the production patterns for separating read, write and admin rights.→
- LDAP integration — central identity for the fleetHow to configure OPNsense to authenticate operators against an LDAP directory, how LDAP bind and search operations work, how to design the directory structure for firewall operators, and the operational discipline that keeps LDAP integration healthy.→
- RADIUS and TACACS+ — protocol-level authorisation for the fleetHow RADIUS and TACACS+ work, how to configure OPNsense to authenticate and authorise operators against RADIUS or TACACS+, how the two protocols differ in capability and security, and the operational patterns for protocol-level authorisation.→
- Two-factor authentication and TOTP — the second factor that mattersHow two-factor authentication works at the protocol level, how to enable TOTP on OPNsense, what a time-based one-time password is and how to recover from a lost token, and the operational discipline for rolling out 2FA across an operator fleet.→
- External identity failure implications — when the directory is downHow external identity stores fail, what happens to OPNsense authentication and authorisation when the directory is unreachable, how to design break-glass paths for external identity failures, and the operational runbooks that keep operators able to act when LDAP, RADIUS, or TACACS+ is down.→
Part XXVI
High Availability Fundamentals
6 checks
- Availability and redundancy — why a second firewall, what HA is actually solvingThe vocabulary of high availability — availability targets, MTBF and MTTR, recovery time versus recovery point, single points of failure, active versus passive roles, and the cost model that justifies a second firewall.→
- Active/passive versus active/active — the two HA topologies and when each is the right answerThe two ways to deploy two firewalls — active/passive with a hot standby, and active/active with both nodes carrying traffic. The cost, complexity, and risk trade-offs of each, and the deployment patterns OPNsense actually supports.→
- Shared IP and virtual IPs — the abstraction that lets two firewalls look like oneWhat a virtual IP actually is, why two firewalls sharing an address needs more than just assigning the same address to both, how VRRP/CARP solve the shared-IP problem with an arbitration protocol, and the IP alias layer underneath.→
- State synchronisation concepts — keeping the backup warm for failoverWhy state synchronisation matters, what the PF state table contains, the difference between connection tracking and NAT state, how OPNsense synchronises state to the backup via pfsync, and the cost of state sync on the inter-node link.→
- Configuration synchronisation concepts — keeping the two nodes in lockstepWhy configuration sync is separate from state sync, the OPNsense XMLRPC-based configuration sync model, what is and is not synchronised, the disciplines of staging configuration changes on one node first, and the failure modes of misconfigured sync.→
- HA prerequisites and design questions — what to confirm before the first failover testThe design questions that decide whether HA is the right answer — hardware symmetry, firmware parity, network topology, sync link, monitoring, and the documented failover procedure. The pre-flight checklist that catches the failures before they happen.→
Part XXVII
CARP
6 checks
- CARP concepts and VHIDs — the protocol that makes a shared IP workWhat CARP is, why two firewalls need a shared IP, what a Virtual Host ID is, and how base advertisement skew plus a one-second advertisement interval defines which node is the master.→
- CARP advertisements and skew — the maths of who is masterHow the CARP advertisement packet is structured, what the base skew and the demotion counter do, how preemption works, and how the master and backup settle on a single owner.→
- CARP virtual IP configuration on OPNsense — the GUI, the ifconfig, and the packet flowHow to configure a CARP virtual IP in OPNsense, what each field does, how the configuration maps to kernel state, and how a packet flows through the master inside the kernel.→
- CARP multicast and switches — what the Layer 2 must do for HA to workThe CARP multicast MAC and group, the role of IGMP, what switches must do and must not do to carry advertisements between peers on each VIP parent segment, and where the dedicated sync segment fits.→
- CARP failover triggers — what makes the backup take overThe events that flip the master/backup role — interface down, daemon down, a raised demotion counter, manual demotion, and the gratuitous ARP that re-points the LAN at the new master.→
- CARP troubleshooting — split-brain, flap, and the demotion that will not clearHow to diagnose the most common CARP failures in production — both nodes MASTER, frequent failover flap, a demotion that will not clear, and advertisements that are not reaching the peer.→
Part XXVIII
pfsync and Configuration Synchronisation
6 checks
- pfsync — state synchronisation between OPNsense peersHow pfsync replicates the PF state table so existing sessions survive a CARP failover.→
- pfsync configuration on OPNsenseConfiguring state synchronisation between two OPNsense nodes with the correct sync interface and peer settings.→
- pfsync interface and securityThe security model of pfsync, the interface it lives on, and the consequences of exposing it.→
- Configuration synchronisation — what does and does not syncThe OPNsense configuration sync mechanism, what it copies between nodes, and what it deliberately leaves alone.→
- Configuration synchronisation — versioning and conflictsHow config sync handles version drift, what happens when the two nodes disagree, and the recovery from split-config.→
- Configuration synchronisation — failure modesWhat breaks config sync in production, how to detect it, and how to recover.→
Part XXIX
HA Network Design, Failure Scenarios, Maintenance
6 checks
- HA reference topology — production-grade OPNsense pairA realistic production HA topology: two firewalls, two ISPs, multiple VLANs, dedicated sync, separate management.→
- HA sync interface and management planeWhy the sync interface and the management plane must be separate, and the operational discipline that keeps them so.→
- HA failure — node lossWhat happens when one firewall node fails, what failover covers, and the operator's response.→
- HA failure — interface lossWhat happens when one interface on a firewall fails, how CARP detects it, and the operator's response.→
- HA failure — split brainWhat split brain means for an HA pair, why it is dangerous, and how to detect and recover from it.→
- HA rolling maintenance — the canonical procedureThe procedure for safely upgrading, patching, or otherwise maintaining an HA pair with zero customer-visible downtime.→
Part XXX
Dynamic Routing
6 checks
- Static versus dynamic routing — when the operator manages routes and when the routers doWhat static and dynamic routing each do, the failure modes of each at production scale, the convergence model that justifies a routing protocol, and the deployment shapes where one or the other is the right answer.→
- FRR and Quagga on OPNsense — the routing daemons and how OPNsense exposes themWhat FRR is, how it descended from Quagga, what daemons FRR runs (zebra, ospfd, bgpd, ripd, isisd), how OPNsense exposes the FRR configuration through plugins, the cost of running FRR on a firewall, and the production discipline of running only the protocols the network needs.→
- OSPF concepts — areas, LSAs, neighbours, and the shortest-path treeWhat OSPF is, how it builds a link-state database from neighbour adjacencies, the role of areas in scaling OSPF, the LSA types the operator must recognise, the DR/BDR election on broadcast segments, and the SPF algorithm that produces the routing table.→
- OSPF on OPNsense — configuring FRR, advertising networks, and the production disciplineHow to configure OSPF on OPNsense through the FRR plugin — interface settings, network announcements, area assignment, authentication, and the production discipline of advertising only the prefixes the operator intends.→
- BGP concepts — autonomous systems, path vectors, and the policy that connects networksWhat BGP is, the autonomous-system model BGP implements, the eBGP/iBGP distinction, the path-vector algorithm and the attributes that drive path selection, route filtering and prefix lists, and the policy model BGP enables.→
- BGP on OPNsense — configuring FRR, peering with upstreams, and the production disciplineHow to configure BGP on OPNsense through the FRR plugin — peer setup, AS number, authentication, prefix lists and route maps, route filtering, and the production discipline of multihoming and route propagation.→
Part XXXI
Intrusion Detection and Suricata
6 checks
- IDS versus IPS — detection, prevention, and where the firewall fits in betweenWhat intrusion detection and intrusion prevention are, how they differ from a stateful firewall, the signature-based and anomaly-based detection models, the cost of each on a production firewall, and the deployment shapes where IDS or IPS is the right answer.→
- Suricata architecture — the engine, the threads, the packet flow, and the rule setHow Suricata is structured — the packet acquisition layer, the decoder, the stream engine, the detection engine, the output system, and the thread model. The architecture that determines what Suricata can inspect and how it scales.→
- Suricata installation on OPNsense — the plugin, the interfaces, the home net, and the rule setHow to install Suricata on OPNsense through the plugin, configure the interfaces to monitor, set the HOME_NET, enable the rule sets, configure IPS mode if appropriate, and verify the engine is running and inspecting traffic.→
- Suricata rule categories — what the Emerging Threats rulesets cover and how to chooseThe Emerging Threats rule categories, what each category detects, how to choose the right set for the network, the discipline of starting narrow and growing, the difference between ET Open (free) and ET Pro (paid), and the custom rule workflow.→
- Suricata IPS mode and blocking — inline detection, drop rules, and the cost of false positivesHow Suricata IPS mode works — the inline capture mechanism, the drop and reject actions, the trade-offs versus IDS mode, the false-positive cost in IPS, the discipline of promoting rules from IDS alerts to IPS drops, and the verification that IPS is actually blocking.→
- Suricata tuning and false positives — disabling rules, suppressing alerts, and the operational disciplineHow to tune Suricata for an acceptable false-positive rate — disabling rules, suppressions, thresholding, the difference between a noisy rule and a real threat, and the operational discipline of periodic rule review.→
Part XXXII
TLS Inspection and Content Filtering
6 checks
- TLS inspection concepts and risks — what MITM at the firewall meansWhat TLS interception actually does at the firewall, the trust relationship it breaks, the privacy and compliance consequences, and the operational risks that make it the most consequential single feature on the box.→
- Internal CA for TLS intercept — issuing the certificate the proxy will forgeHow to create and operate a dedicated CA for TLS interception, the certificate lifetime and key size that match production, the trust anchor distribution to client devices, and the certificate lifecycle that prevents the intercept CA from becoming a single point of failure.→
- TLS intercept deployment — putting the proxy between the client and the InternetHow to enable TLS interception on OPNsense, the certificate assignment, the exemption list for pinned and regulated destinations, the route the intercepted traffic takes through the proxy, and the production checks that confirm interception is working end to end.→
- Web filtering plugins — URL categories, content types, and application controlThe web filtering capabilities layered on top of TLS interception — URL category databases, content-type matching, application protocol detection, and the plugin model that turns the firewall into a content-control gateway.→
- Threat intelligence and blocklists — feeding the firewall from external sourcesHow to consume external threat intelligence — IP blocklists, domain blocklists, file hash feeds, and the protocols that deliver them. The discipline that turns a feed subscription into enforcement, not just data.→
- Content filtering policy and ethics — what the operator is allowed to doThe policy framework that should exist before TLS interception is enabled — legal boundaries, employee notice, exemption categories, retention limits, and the human review required when content filtering produces evidence used in employment decisions.→
Part XXXIII
Logging and Remote Logging
6 checks
- Logging architecture on OPNsense — where the logs come from and where they goThe components that produce logs on OPNsense, the syslog-ng pipeline that routes them, the daily files on disk, the GUI pages that read them, and the integration points where logs leave the firewall for a remote destination.→
- Firewall log reading — what each filterlog line tells youHow to read an OPNsense filterlog line — the comma-separated fields, the reason and action, the interface and rule id, the protocol details, and the aggregation pattern that turns a flood of log lines into an incident timeline.→
- System and service logs — what lives outside the filter logThe system, audit, DHCP, DNS, VPN, IDS, and proxy log directories on OPNsense — what each contains, what each looks like on disk, and the diagnostic patterns that turn a service outage into a log entry the operator can find.→
- Syslog protocol and format — the wire format every log forwarder speaksThe syslog wire format — RFC 3164 (BSD) and RFC 5424 (structured), the priority value, the facility and severity, the transport choices (UDP, TCP, TLS), and the production considerations that determine which format and transport to choose.→
- Remote syslog to observability — forwarding OPNsense logs to a SIEM or log serverHow to forward OPNsense logs to a remote destination — the GUI configuration, the certificate setup for TLS, the per-facility routing that splits logs across multiple destinations, and the production checks that confirm forwarding is working end to end.→
- Log retention and rotation — keeping what you need, deleting what you do notThe retention model on OPNsense — the daily files and the housekeeping job that trims them, the two settings that bound them, the remote retention that the SIEM owns, and the legal and operational discipline that defines how long logs are kept and when they are deleted.→
Part XXXIV
Monitoring and Observability Integration
6 checks
- Monitoring the firewall itself — what to instrument before anything elseThe metrics that describe the health of the firewall as a system — CPU, memory, state table, disk, temperature — and the discipline of distinguishing firewall-health from network-health when an incident lands.→
- Prometheus exporter on OPNsense — getting the firewall into a time-series databaseThe opnsense-exporter plugin, the metrics it exposes, the Prometheus scrape configuration, and the discipline of label cardinality and metric naming when a firewall becomes a monitored target.→
- Grafana dashboards for OPNsense — from raw metrics to operator insightGrafana as the visual layer on top of Prometheus, the OPNsense community dashboards, the panels that matter, alert rules that trigger on the right thresholds, and the discipline of dashboards that survive an incident.→
- SNMP and traditional monitoring — the protocol that pre-dates Prometheus and still earns its placeSNMP as a monitoring protocol on OPNsense, the net-snmp daemon configuration, v2c versus v3, MIBs and OIDs, the SNMP traps OPNsense emits, and where SNMP fits in a modern monitoring stack alongside Prometheus.→
- Health checks and Monit — local self-healing and the discipline of a daemon that restarts servicesThe Monit service manager on OPNsense, the health checks it performs, the recovery actions it can take, and the discipline of an automated-restart system that does not become a denial-of-service against its own services.→
- Observability of the firewall architecture — the discipline of seeing the whole stack, not just the deviceThe observability model that surrounds the firewall — metrics, logs, and traces across the firewall, the switches, the upstream, and the applications — and the discipline of correlating events across systems when an incident demands an answer.→
Part XXXV
Performance and State Table
6 checks
- Throughput and packets per second — the two numbers that define firewall capacityThe two dimensions of firewall performance — bits per second and packets per second — the limits each one imposes, where the limits come from in a FreeBSD/OPNsense deployment, and the discipline of measuring capacity before the user reports a slowdown.→
- State table sizing and defaults — the limits that determine whether new flows are acceptedThe PF state table on OPNsense — its default size, the consequences of hitting the limit, the tuning parameters that raise the limit, and the discipline of sizing the table for the workload before the table fills.→
- State table exhaustion symptoms — recognising the failures before the user doesThe symptoms of PF state table exhaustion in production — partial failures, asymmetric symptoms, log signatures — and the discipline of distinguishing state-table exhaustion from rule mistakes, link saturation, and CPU bottlenecks.→
- CPU and interrupt saturation — when the packet path becomes the bottleneckThe packet path on FreeBSD/OPNsense, the role of interrupts versus softirqs versus process context, the symptoms of interrupt saturation, and the discipline of distributing interrupts across CPU cores.→
- VPN performance and crypto offload — what determines how fast the tunnel goesThe performance characteristics of IPsec and WireGuard on OPNsense — CPU cost of encryption, the role of AES-NI and QAT crypto offload, MTU and overhead, and the discipline of measuring VPN throughput before depending on it.→
- IDS performance impact — what Suricata costs and how to keep it from breaking the firewallThe CPU and packet-rate cost of running Suricata IDS on OPNsense, the modes of operation (legacy netmap, IPS mode, hyperscan), the ruleset tuning that determines performance, and the discipline of running IDS without breaking throughput.→
Part XXXVI
Packet Capture and Diagnostics
6 checks
- Packet capture fundamentals — what tcpdump actually shows and what it leaves outHow packet capture works on FreeBSD/OPNsense, the difference between a copy and the live packet, the role of libpcap and BPF, and the discipline of using capture as evidence rather than as a debugging tool in itself.→
- tcpdump on the firewall — the operator's primary capture toolUsing tcpdump on OPNsense from the CLI: the common flags, the canonical command forms, rotating captures, and the discipline of capturing the smallest useful slice of traffic.→
- GUI live capture — when to use the web interface and when to drop to the shellOPNsense GUI live capture tool: what it can do, what it cannot do, the rotating pcap it saves, and the discipline of using it for quick checks while reserving the shell for sustained or precise captures.→
- BPF filters for firewall traffic — writing precise capture expressionsWriting BPF filter expressions for firewall traffic: host, net, port, proto, direction, TCP flags, byte offsets, and combining expressions. The discipline of writing the smallest filter that captures the relevant traffic.→
- Capture on VLANs and tunnels — seeing traffic that lives on the wrong interfaceCapturing traffic on VLAN interfaces, bridge members, WireGuard tunnels, IPsec tunnels, and OpenVPN tunnels. The discipline of choosing the right capture interface when the traffic has crossed a tag or an encapsulation.→
- Capture-driven troubleshooting — using packet captures to close firewall incidentsThe methodology of capture-driven troubleshooting: forming a hypothesis, designing a capture to test it, gathering supporting evidence from PF logs and state, and closing the incident on the evidence rather than the guess.→
Part XXXVII
Packet Flow Methodology
6 checks
- Packet flow overview — the journey of a packet through OPNsenseThe end-to-end path of a packet through OPNsense: NIC, kernel, PF, routing, NAT, and the egress NIC. The role of each subsystem and why the operator must understand the whole path to diagnose any part.→
- Source to ingress interface — what happens before PF sees the packetThe path from the source host to the firewall ingress interface: Layer 2 forwarding, VLAN tagging, ARP resolution, and the role of the switch. The discipline of verifying what arrived at the firewall before assuming PF involvement.→
- Firewall rule evaluation — how PF decides to pass or blockHow PF evaluates a packet against the ruleset: rule order, the first-match-wins principle, the difference between pass, block, and reject, the role of quick rules, and the discipline of reading PF log entries to verify decisions.→
- State creation and match — how PF tracks flows and passes return trafficHow PF creates state on the first packet of a flow, how subsequent packets match state, the structure of a state entry, the state timeouts, and the discipline of reading the state table to diagnose flow-level problems.→
- Routing decision and egress — from PF pass to packet on the wireHow the kernel decides the egress interface and next hop for a passed packet, the role of the routing table, the longest-prefix-match rule, and the path from routing decision to frame on the egress wire.→
- NAT in the packet flow — where translation happens and why it surprises operatorsWhere NAT fits in the packet flow: outbound NAT (source translation) applied after routing, inbound NAT (port-forwarding) applied before PF. The discipline of reading NAT translations in captures and the rules that drive them.→
Part XXXVIII
Troubleshooting Methodology
6 checks
- Troubleshooting mindset — the discipline that prevents incidents from becoming outagesThe operator mindset that turns a firewall incident from a panic into a structured investigation: no change without evidence, slow is fast, the symptom is not the cause, and the cost of speculation.→
- Symptom, cause and contributing factor — separating what the user sees from what the firewall didThe three layers of an incident — the user-observed symptom, the firewall-observed symptom, and the cause — and the discipline of distinguishing contributing factors from the actual root cause.→
- Evidence-first diagnosis — commands, outputs and the discipline of reading themThe commands OPNsense provides for evidence collection — pfctl, tcpdump, netstat, route, the log search — and how to read each output to distinguish hypothesis-supporting from hypothesis-refuting evidence.→
- Firewall rule troubleshooting — finding the rule that drops the packetA structured methodology for diagnosing firewall-rule failures — state table, ruleset position, first-match-wins, log lines, and the most common rule mistakes in production estates.→
- NAT troubleshooting — finding the translation that did not happenA structured methodology for diagnosing NAT failures — outbound NAT, port forwards, 1:1 NAT, NAT reflection — the evidence each layer produces, and the most common NAT mistakes in production.→
- Routing troubleshooting — finding the missing route, the wrong gateway, and the asymmetric returnA structured methodology for diagnosing routing failures on OPNsense — Layer 2 evidence, the FIB, policy routing, gateway groups, return-path symmetry, and the most common routing mistakes in production.→
Part XXXIX
Lockout Prevention and Console Recovery
6 checks
- Lockout risks and prevention — every way an operator can lock themselves outThe lockout modes OPNsense operators encounter — GUI lockout, SSH lockout, source-restriction lockout, 2FA lockout, certificate lockout — and the prevention patterns that keep an operator in control of their firewall.→
- Anti-lockout rule and defaults — the safety net that lets you change other rulesThe anti-lockout rule in detail — what it allows, where it sits in the ruleset, when to disable it, and the production patterns for source-restricted management and explicit allow rules on management VLANs.→
- Safe rule change procedure — the discipline that prevents lockoutsThe procedure for applying a firewall rule change safely — backup, peer review, second-session test, verification, and rollback — the patterns that turn a risky change into a reversible one.→
- Physical console recovery — the hard path that always worksThe physical console path — serial console, BMC/KVM over IP, IPMI — how to connect to the OPNsense console, the boot menu options, single-user mode, and the operator actions that recover from a hard lockout.→
- Virtual console and serial — recovering OPNsense on Proxmox, VMware, and KVMThe virtual console path for OPNsense running on virtualisation platforms — Proxmox noVNC, VMware VMRC, KVM virt-manager, the serial console settings, and the operator actions that work in a virtual environment.→
- Factory reset and configuration restore — the last-resort recovery pathsFactory reset via the boot menu, the configuration-restore procedure from backup, the boot-environment rollback, and the discipline of choosing between reset and restore — when each is appropriate and what each loses.→
Part XL
Backup, Restore, Disaster Recovery
6 checks
- Config backup strategy — what to back up, when, and why cadence mattersThe backup cadence decision, the three types of OPNsense configuration snapshots (full, filtered, encrypted), and the operational policy that separates a working DR plan from a folder of stale XML files.→
- Config backup content — what is in the XML, what is not, and what to redactA line-by-line walk through what OPNsense's config.xml actually contains, the items that look like configuration but live outside it (cert store, RRD databases, leases, logs), and the discipline of selective redaction before sharing a backup with a vendor.→
- Secure storage and versioning of configuration backupsWhere to keep backups off-host, how to version them so a known-good snapshot can be identified after a bad change, how to encrypt at rest, and how to integrate with git for change correlation.→
- Restore from backup — the procedure, the verification, and the rollback planThe three restore methods (GUI, API, shell), the verification checklist that follows every restore, the partial-restore techniques for fixing a single broken section without overwriting everything, and the rollback plan when the restore itself fails.→
- Interface mapping considerations across hardware revisionsWhy a backup from one appliance does not necessarily restore cleanly to another, the NIC ordering trap, MAC address drift, interface renumbering during a restore, and the test procedure that catches the mismatch before production.→
- Full appliance disaster recovery — the runbook when the box is goneThe full-appliance DR runbook from site loss to traffic restored: provisioning identical hardware, restoring the configuration, the offline test plan, the rekeying discipline, and the lessons-learned cycle that closes the loop.→
Part XLI
Upgrades and Plugin Management
6 checks
- Upgrade process and cadence — when to upgrade, how often, and what to read firstThe OPNsense release cadence, the security vs feature distinction, the production-safe upgrade window, the staged rollout pattern, and the reading the operator must do before clicking the upgrade button.→
- Pre-upgrade validation — the checklist before the rebootThe validation checklist the operator runs immediately before the upgrade: backup verification, plugin compatibility, hardware headroom, dependency review, and the boot-environment confirmation that proves the rollback path exists.→
- Major version upgrades — the 25.x to 26.x leap and what it carriesWhat changes between major OPNsense releases, the FreeBSD base bump, the PHP upgrade, the plugin API breakage pattern, the long-form migration plan, and the post-upgrade verification that catches regressions.→
- Plugin management lifecycle — install, configure, update, retireThe plugin lifecycle from discovery through retirement: where plugins come from, how to vet them, the install-update-retire cadence, the configuration migration between plugin versions, and the dependency graph that catches the operator when a plugin depends on another.→
- Plugin abandonment and alternatives — when the maintainer walks awayHow to recognise plugin abandonment, the risk profile of an unmaintained plugin, the migration paths when a plugin is deprecated or replaced by a built-in feature, the fork-or-replace decision, and the runbook for retiring an abandoned plugin safely.→
- Rollback strategy — when the upgrade fails, the firmware is broken, or the plugin is incompatibleThe rollback decision tree, the boot-environment rollback procedure, the configuration restore path, the partial-rollback technique for fixing one bad change without unwinding everything, and the post-rollback verification that confirms the firewall is back to a known-good state.→
Part XLII
API and Automation
6 checks
- API authentication and tokens — key/secret pairs, Basic auth, and least privilege for the automation tierHow OPNsense authenticates API clients with a key/secret pair over HTTP Basic; how to generate a least-privilege pair from the GUI; key rotation and revocation; and the operational discipline of separating automation credentials from operator credentials.→
- API endpoints overview — the taxonomy, the namespaces, and where to find what you needThe OPNsense REST API surface as a URL taxonomy; the module conventions for core, auth, firewall, interfaces, trust and diagnostics; the searchRule/addRule/setRule command naming and the separate apply step; and how to discover endpoints without reading every PHP controller.→
- API safety and rate limiting — staged writes, idempotency, and the operational guardrailsHow to make an API call that is safe to retry; the save-then-apply model and what each half changes; how reads compete with writes; recording the configuration revision to roll back to; the timeout and retry rules; and the four call modes.→
- API firewall rule automation — building rules safely from a scriptThe full lifecycle of an API-driven firewall rule change against the automation rule set: searchRule to discover, addRule with a flat payload, the separate apply step, verification against pf by rule UUID, rollback on failure, and the audit trail that proves who changed what.→
- API alias automation — hosts, networks, ports, URL-tables, and nested tablesHow to add and manage aliases via the API: hosts, networks, ports, URL tables for dynamic address lists, network groups that compose other aliases, and the silent failure modes — replaced content, stale feeds, renames — a script must avoid.→
- API monitoring and webhooks — driving observability from firewall eventsHow to monitor OPNsense via the API rather than scraping the GUI; the metrics and state endpoints a monitor should consume; how to trigger external workflows (ticket creation, chat notifications) via outbound webhook-style integrations; the limits of what the API exposes and where it falls back to Prometheus or syslog.→
Part XLIII
Ansible-Driven Firewall Configuration
6 checks
- Ansible for firewalls — concepts, trade-offs, and blast-radius disciplineWhy Ansible (and not raw scripts) is the right tool for firewall configuration at fleet scale; the push-vs-pull model; idempotency and its operational meaning; the blast-radius discipline that turns a fleet-wide automation into a governed change; and the trade-offs between Ansible and direct API scripts.→
- OPNsense Ansible collection — ansibleguy.opnsense modules, installation, and version pinningThe ansibleguy.opnsense Ansible collection — its scope, its modules, how to install it from Galaxy or from source, why pinning matters for production change safety, and how to validate it against the running firmware when no compatibility table exists.→
- Ansible inventory for firewalls — static hosts, group_vars, host_vars, and dynamic discoveryHow to structure an Ansible inventory for OPNsense firewalls — host naming, group structure for environment and role, host_vars and group_vars for per-firewall overrides, dynamic inventory via the OPNsense API, and the trap of letting inventory become configuration trivia.→
- Ansible playbook shape — pre-flight, change, post-flight, and the anti-lockout gatesThe four-shape playbook: pre-flight checks, anti-lockout gating, the change tasks, post-flight verification. Handlers for service reloads. Roles and task files for reuse. A worked playbook that adds a rule safely to a single firewall then across a serial fleet.→
- Drift detection with Ansible — comparing desired state to actual state across the estateHow to detect, report, and remediate configuration drift with Ansible; the difference between idempotency-based and explicit drift detection; the patterns for a daily cron-equivalent scan; what counts as drift and what does not; how to handle intentional manual changes without losing the playbook's authority.→
- Ansible failure modes — partial fleet, lockouts, idempotency breakage, and recoveryThe failure modes specific to running Ansible against OPNsense firewalls — partial fleet failure, lockouts from rule changes, idempotency breakage from API schema changes, transient API failures, and the recovery playbook for each. The discipline of post-incident review.→
Part XLIV
Change Management and Rule Review
6 checks
- Pre-change checklist — the discipline that turns a risky change into a reversible oneThe pre-change checklist: identify the change, take a backup, peer-review, verify a tested recovery path, confirm the change window. The seven checkpoints the operator walks through before any firewall modification.→
- Change documentation and tickets — the audit trail that survives the operatorThe change ticket as the unit of change documentation: required fields, peer-review sign-off, before/after evidence, rollback plan. Why change documentation is the audit trail, and what happens to a firewall without it.→
- Rollback strategies — how to reverse a change that turned out to be wrongRollback as a planned procedure, not an improvisation: in-place rollback, backup restore, boot-environment rollback, and vendor recovery. The decision tree for choosing the right rollback, and the rollback drill that proves it works.→
- Rule review cadence — the schedule that keeps the ruleset honestThe rule review cadence: weekly operational review, monthly hygiene review, quarterly security review, annual compliance review. What each review looks for, who attends, what evidence is produced, and why a firewall without a review cadence accumulates rot.→
- Shadowed and redundant rules — finding the rules that are doing nothingHow to identify shadowed rules (never reached because an earlier rule matches first), redundant rules (match the same traffic as another rule), and dead rules (have not matched in months). The PF evaluation order that makes shadowing possible, and the discipline of removing rules that are not earning their place.→
- Rule cleanup and hygiene — the discipline that keeps the ruleset maintainableRule cleanup as a recurring operation: dead-rule removal, alias cleanup, group cleanup, schedule cleanup. The cleanup procedure that turns a ruleset that has accumulated rot into a maintainable asset, and the trap of cleanup that turns into feature work.→
Part XLV
Production Hardening and Zero-Trust Concepts
6 checks
- Hardening checklist overview — frameworks, scope, and the discipline of defence in depthA production hardening framework for OPNsense: the management, control, and data planes; the CIS and NIST baselines; what hardening is and is not. The discipline of defence in depth and the trap of hardening that turns into theatre.→
- Management plane hardening — securing the GUI, SSH, API, and console pathsThe management plane hardening checklist: source-restricted GUI, key-only SSH, API key rotation, console-only break-glass, MFA on the GUI, audit logging. The threats each control addresses and the evidence each control produces.→
- Network plane hardening — anti-spoofing, bogon blocking, ICMP rate-limiting, and the perimeterNetwork plane hardening: anti-spoofing rules on the WAN, bogon and private-range blocking, ICMP rate-limiting, and the perimeter posture. The threats each control addresses (spoofed sources, scanning, DoS, reconnaissance) and the evidence each control produces.→
- Data plane hardening — defaults, IDS/IPS posture, TLS inspection, and the rulesetData plane hardening: default-deny posture, Suricata IDS/IPS tuning, TLS inspection trade-offs, state-table protection. The threats each control addresses (unauthorised flows, malicious payloads, encrypted exfiltration, state exhaustion) and the evidence each control produces.→
- Zero-trust principles — the model that replaces the perimeterZero-trust as a security model: never trust, always verify, least privilege, assume breach. The principles, the threat model, and the difference between zero-trust and perimeter security. How zero-trust changes what the firewall operator builds.→
- Zero-trust segmentation on OPNsense — turning the principles into rulesApplying zero-trust on OPNsense: microsegmentation with VLANs, identity-based rules via authentication backends, session-based controls, east-west firewalling. The patterns that turn zero-trust principles into operational rules, and the limits of what the firewall alone can enforce.→
Part XLVI
Remote Access and Site-to-Site Architecture
6 checks
- Admin remote access and the bastion pattern — keeping the keys off the perimeterThe patterns for administrative access to OPNsense and the network it protects — direct HTTPS/SSH on the firewall, bastion hosts, jump hosts, session recording, MFA, and the discipline of separating admin access from user VPN.→
- User VPN architectures — split tunnel, full tunnel, always-on and the choices that matterThe architectural choices for user VPN: split tunnel versus full tunnel, always-on versus on-demand, per-app routing, the DNS and routing implications of each, the security trade-offs, and the operational patterns that fit each deployment.→
- Site-to-site VPN architecture — hub-and-spoke, full-mesh and the topology that fitsThe topologies for site-to-site VPN — point-to-point, hub-and-spoke, full-mesh, partial-mesh, and the routing and operational trade-offs of each. How to choose the topology that fits the network, the addressing plan that supports it, and the failure modes of each.→
- Multi-site fabric — combining VPN, dynamic routing and addressing into one networkHow a multi-site deployment combines site-to-site VPN with dynamic routing (OSPF, BGP) to form a single routing fabric. The addressing plan, the route summarisation, the failover behaviour, the operational patterns, and the discipline of treating the VPN as a transport for the routing protocol.→
- Cloud connectivity from OPNsense — IPsec and WireGuard to AWS, Azure and GCPPatterns for connecting OPNsense to cloud providers — AWS VPN, Azure VPN Gateway, GCP Cloud VPN, the IPsec and WireGuard configurations on OPNsense, the routing on the cloud side, the high-availability patterns, and the discipline of treating the cloud as another site in the fabric.→
- VPN fabric monitoring — knowing whether the tunnels are up, slow or silently brokenHow to monitor a VPN fabric — tunnel state, handshake age, packet counters, MTU black holes, throughput, BGP session state, and the metrics, alerts and dashboards that surface a VPN problem before the user reports it.→
Part XLVII
Capacity Planning
6 checks
- Throughput sizing — how much traffic the firewall can actually moveThroughput sizing for OPNsense — the difference between wire-rate, packet-rate, and application throughput; the CPU cost of forwarding, NAT, and rule evaluation; the role of NIC offloads; and the discipline of measuring throughput with iperf3 before depending on it.→
- State table sizing — how many flows the firewall can track before it breaksState table sizing for production — where the state limit lives and how OPNsense derives its default, the memory cost per entry, the arrival-rate-times-lifetime relationship between flow rate, state lifetime and table occupancy, and the tuning discipline for firewalls that approach the limit.→
- VPN throughput budget — accounting for the encryption cost in the firewall sizingVPN throughput budgeting — the encryption CPU cost for IPsec and WireGuard, the role of AES-NI and QAT, the overhead per packet, the effective throughput calculation, and the discipline of sizing the firewall for the actual VPN workload, not the unencrypted workload.→
- IDS/IPS throughput budget — what Suricata costs and how to budget for itIDS/IPS throughput budgeting — the CPU cost of Suricata in IDS and IPS modes, the ruleset factors that determine performance, the threading model, the canary metrics, and the discipline of sizing the firewall for the actual workload with IDS enabled.→
- Log volume budget — planning disk, network and observability capacity for logsLog volume budgeting for OPNsense — the sources of log volume (firewall log, system log, IDS log, VPN log, DNS log), the bytes per event for each, the disk and network capacity needed to retain and forward the logs, and the discipline of budgeting before the disk fills.→
- Growth planning and headroom — sizing the firewall for next year, not this weekGrowth planning for OPNsense — the patterns of growth (user count, traffic volume, feature additions, new sites), the headroom calculation, the trigger points for capacity expansion, and the discipline of treating capacity planning as a continuous process, not a one-time exercise.→
Part XLVIII
Production Reference Architecture
6 checks
- Reference architecture — Internet edgeThe edge-facing OPNsense pair: ISP connections, public services, edge IDS, and the topology that ties them together.→
- Reference architecture — Multi-WAN, gateway groups, and policy routingHow the reference edge architecture handles dual uplinks with health-based failover and traffic steering.→
- Reference architecture — Segmentation and DMZThe VLAN and DMZ plan that the reference architecture assumes, with the firewall rules that enforce it.→
- Reference architecture — VPN and remote accessWireGuard site-to-site and remote access patterns that fit the reference architecture, plus IPsec where required.→
- Reference architecture — Monitoring, logging, and backupHow the reference architecture sends telemetry to the central observability stack and backs up configuration safely.→
- Reference architecture — Operating the estateDay-2 operations for the reference architecture: change windows, upgrades, incident response, and the runbook set.→