Firewall on Adur

OPNsense: Auditing, Automation, and Advanced Practices

Sat, 11 Apr 2026 00:00:00 +0000

Where We Stand

In the first two posts of the series, we set up OPNsense from scratch and took it to a configuration that is no longer trivial. Let’s do a quick recap before continuing.

Layer	What Was Configured	Post
Hardware	Mini PC with Intel N100/N200, Intel i226-V NICs	First
Connectivity	PPPoE on WAN, bridge on LAN, wireless interface	First
Detection	Suricata IDS/IPS with ET Open, Abuse.ch, Feodo rulesets	First
Shared Intelligence	CrowdSec with firewall bouncer and community collections	First
VPN	WireGuard with configured peers	First
Firewall Rules	Basic rules for LAN, WireGuard, and WAN	First
Offloading	Checksum, TSO, TCP buffer tuning	First
Users	Dedicated admin with OTP, restricted root, protected WebUI	First
Backups	AES-256-CBC encrypted, automatic, external storage	Second
DPI	Zenarmor with per-interface and category policies	Second
Segmentation	5 VLANs (Main, Guests, IoT, Servers, Management) with inter-VLAN rules	Second
SSH	ed25519 keys only, non-standard port, IP-restricted access	Second
DNS	Unbound with DNS over TLS to Quad9 and Cloudflare	Second
Logging	Remote syslog with TCP/TLS to Grafana+Loki or ELK	Second

It’s a solid configuration. But so far everything has been done manually, through the web interface, without a formal review process or a way to reproduce the configuration if something breaks beyond the XML backup. This post covers what’s missing: advanced practices, automation, a serious auditing framework, and a comparison with alternatives to make informed decisions.

Security Posture Review

Defense in Depth: What We Have

If we look at what we’ve configured as defense layers, the architecture has some depth:

Defense Layer	OPNsense Component	Current State
Perimeter	WAN deny-all rules + incoming WireGuard	Functional
Intrusion Detection	Suricata IPS with ET Open and Abuse.ch	Functional, default tuning
Log Analysis	CrowdSec bouncer + community intelligence	Functional
Application Inspection	Zenarmor DPI with per-VLAN policies	Functional
Segmentation	5 VLANs with deny-all inter-VLAN rules by default	Functional
Access Control	Dedicated admin, OTP, SSH with ed25519 keys	Functional
DNS Encryption	Unbound with DoT to Quad9/Cloudflare	Functional
Backups	Encrypted, automatic, external storage	Functional

Five layers of detection and prevention, real segmentation, and reasonable access control. For a homelab or small office, it’s more than most have. But there are gaps.

Remaining Gaps

Being honest, there are several things that haven’t been addressed that matter:

No geolocation filtering. The entire planet can try to connect to exposed ports on WAN. Most automated attacks come from IP ranges with which you have no legitimate relationship.
No reverse proxy. If self-hosted services are exposed (Nextcloud, Jellyfin), they go directly via NAT without TLS termination or application-level protection.
Suricata is at default configuration. Rules are enabled, but performance parameters haven’t been tuned and irrelevant categories haven’t been removed.
Everything has been configured manually. If tomorrow OPNsense needs to be rebuilt from scratch, the XML backup is the only option. There are no playbooks, no version control of the configuration, no way to review what changed and when without opening the web interface history.
No formal audit cadence. The second post mentioned a weekly/monthly/quarterly routine, but without a framework behind it, it’s easy for it to remain good intentions.
No automated threat feeds beyond Suricata rule updates. IP blocklists don’t update themselves.

The following sections cover these gaps.

Advanced Practices

GeoIP Blocking with MaxMind

The idea is simple: if there’s no legitimate reason for a connection to come from certain countries, blocking those IP ranges reduces noise. It’s not a real security measure, because any attacker with a VPN bypasses it, but it does eliminate a significant amount of automated scans and brute force attacks.

OPNsense uses MaxMind’s free GeoLite2 databases, which require an account.

Register a free account at MaxMind and generate a license key.
In Firewall > Aliases > GeoIP settings, enter the license key.
Create a GeoIP type alias in Firewall > Aliases:
- Name: GeoIP_Block
- Type: GeoIP
- Content: select the countries to block.
In Firewall > Rules > WAN, add a rule at the top:
- Action: Block
- Source: GeoIP_Block
- Destination: *
- Description: Geographic blocking

One warning: keep this list updated. MaxMind updates the databases weekly. Configure automatic update in the GeoIP settings so they don’t become obsolete.

Advanced Suricata Tuning

OPNSense 26.1 includes Suricata 8, which improves multi-thread performance and adds support for new protocols. But the default configuration is conservative. If the hardware has headroom, tuning these parameters makes a difference.

In Services > Intrusion Detection > Administration, the advanced section allows configuring parameters not in the standard interface. The most relevant:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# /usr/local/opnsense/service/conf/actions.d/conf.d/
# Adjust based on available RAM (these values are for 8 GB)

# Maximum memory for flow tracking
flow:
 memcap: 256mb
 hash-size: 65536

# Maximum memory for TCP stream reconstruction
stream:
 memcap: 512mb
 reassembly.memcap: 256mb

# Ring buffer size for af-packet
af-packet:
 - interface: igb0
 ring-size: 30000
 cluster-type: cluster_flow

Beyond memory tuning, review the active rule categories. If there are no SCADA servers, exposed databases, or SMTP services on the network, disable those categories. Each active rule consumes CPU on every inspected packet.

To identify the rules generating the most noise, analyze the EVE JSON log:

1
2
3
4


# Top 10 alerts by SID in the last 24 hours
cat /var/log/suricata/eve.json | \
 jq -r 'select(.event_type=="alert") | .alert.signature_id' | \
 sort | uniq -c | sort -rn | head -10

If a rule generates hundreds of daily alerts with none being true positives, disable it or adjust its threshold.

Reverse Proxy with HAProxy and ACME

If self-hosted services are exposed to the internet, doing it directly with port forwarding is functional but insecure. A reverse proxy allows terminating TLS with valid certificates, applying rate limiting, and having a centralized control point.

Install the os-haproxy and os-acme-client plugins from System > Firmware > Plugins.

Certificates with Let’s Encrypt (ACME):

In Services > ACME Client > Accounts, create an ACME account.
In Services > ACME Client > Challenge Types, configure a DNS-01 challenge. It’s preferred over HTTP-01 because it doesn’t require opening port 80 and supports wildcards.
In Services > ACME Client > Certificates, create certificates for each service.

HAProxy Configuration:

In Services > HAProxy > Real Servers, create a backend for each internal service (Nextcloud at 192.168.40.10:443, Jellyfin at 192.168.40.11:8096, etc.).
In Services > HAProxy > Rules & Checks > Conditions, create conditions based on SNI or hostname.
In Services > HAProxy > Virtual Services > Public Services, create a frontend that listens on port 443, binds the ACME certificates, and routes to backends based on conditions.
Enable HSTS in HTTP headers to force HTTPS.
Configure rate limiting per IP to mitigate brute force attacks against login forms.

Threat Feeds and Scheduled Aliases

IP blocklists lose value if they aren’t updated. OPNsense allows creating URL Table type aliases that are downloaded automatically.

In Firewall > Aliases, create aliases with these sources:

Alias	URL	Frequency	Description
`Spamhaus_DROP`	`https://www.spamhaus.org/drop/drop.txt`	Daily	Hijacked ranges or used for spam
`Spamhaus_EDROP`	`https://www.spamhaus.org/drop/edrop.txt`	Daily	Extension of DROP
`Abusech_Feodo`	`https://feodotracker.abuse.ch/downloads/ipblocklist.txt`	Every 6h	Banking botnet IPs
`Abusech_SSLBL`	`https://sslbl.abuse.ch/blacklist/sslipblacklist.txt`	Every 6h	IPs with malicious certificates

Apply these aliases as source in blocking rules on WAN. URL Table type aliases update automatically according to the configured frequency.

ZFS Snapshots for Rollback

If ZFS was chosen as the filesystem during installation (instead of UFS), one of its best features can be used: instant snapshots with rollback.

Before any important change (firmware update, massive rule change, plugin installation), create a snapshot:

1
2
3
4
5
6
7
8


# Create a snapshot before updating
zfs snapshot zroot/ROOT/default@pre-update-$(date +%Y%m%d)

# List existing snapshots
zfs list -t snapshot

# If something goes wrong, rollback to the previous snapshot
zfs rollback zroot/ROOT/default@pre-update-20260413

This returns the entire filesystem to the snapshot state in seconds. It’s insurance against failed updates that complements XML configuration backups. The snapshot recovers everything; the XML backup only recovers the configuration.

Infrastructure as Code for OPNsense

Doing everything from the web interface works, but it has known problems: there’s no readable change history, there’s no way to review what was modified before applying it, and rebuilding the configuration requires following a step-by-step guide or restoring an opaque backup.

OPNsense REST API

OPNsense exposes a fairly complete REST API. The documentation is in /api/ and covers most web interface functionalities: aliases, firewall rules, interface configuration, IDS, CrowdSec, Unbound, HAProxy, and more.

To use the API, create a key/secret pair in System > Access > Users, select the administrator user, and generate an API key. OPNsense generates a file with the key and secret.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# Query firewall aliases
curl -k -u "API_KEY:API_SECRET" \
 https://192.168.1.1/api/firewall/alias/searchItem

# Create a new alias
curl -k -u "API_KEY:API_SECRET" \
 -X POST \
 -H "Content-Type: application/json" \
 -d '{"alias":{"name":"test_alias","type":"host","content":"10.0.0.1"}}' \
 https://192.168.1.1/api/firewall/alias/addItem

# Apply pending changes to the firewall
curl -k -u "API_KEY:API_SECRET" \
 -X POST \
 https://192.168.1.1/api/firewall/alias/reconfigure

The API doesn’t cover 100% of the web interface. Some plugin functions (like parts of Zenarmor) aren’t exposed. But for firewall management, aliases, rules, interfaces, and most core services, it’s sufficient.

Ansible: ansibleguy/collection_opnsense

The ansibleguy.opnsense collection is the most mature option for managing OPNsense as code in 2026. It wraps the REST API in idempotent Ansible modules.

1
2


# Install the collection
ansible-galaxy collection install ansibleguy.opnsense

An example playbook managing aliases and firewall rules:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


---
- name: Configure OPNsense firewall
 hosts: opnsense
 connection: httpapi
 vars:
 ansible_httpapi_port: 443
 ansible_httpapi_use_ssl: true
 ansible_httpapi_validate_certs: false
 tasks:
 - name: Create RFC1918 alias
 ansibleguy.opnsense.alias:
 name: RFC1918
 type: network
 content:
 - "10.0.0.0/8"
 - "172.16.0.0/12"
 - "192.168.0.0/16"
 description: "RFC1918 private networks"

 - name: Create admin alias
 ansibleguy.opnsense.alias:
 name: Admin_IPs
 type: host
 content:
 - "192.168.50.10"
 - "192.168.50.11"
 description: "Admin IPs"

 - name: Block IoT to internal networks
 ansibleguy.opnsense.rule:
 interface: "opt3" # VLAN 30 IoT
 action: block
 source_net: "IoT net"
 destination_net: "RFC1918"
 description: "IoT without access to internal networks"

Ansible supports check mode (--check) to see what would change without applying anything. This is especially useful for reviewing firewall changes before executing them, something the web interface doesn’t allow.

The main limitation is that not all OPNsense modules are covered by the collection. Services like Zenarmor, CrowdSec, or advanced Suricata configurations may require direct API calls using Ansible’s uri module.

Version Control of config.xml

The most straightforward approach to have configuration under version control: export the config.xml, encrypt it, and store it in a private Git repository. It’s what’s already done with the backups from the second post, but integrated into a Git workflow.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


#!/bin/bash
# export_config.sh - Run from cron or manually before changes
BACKUP_DIR="/root/config-backups"
REPO_DIR="/root/opnsense-config"
DATE=$(date +%Y%m%d_%H%M)

# Export current configuration
cp /conf/config.xml "${BACKUP_DIR}/config_${DATE}.xml"

# Encrypt with age (simpler than OpenSSL for this use)
age -r age1publickey... \
 -o "${REPO_DIR}/config_${DATE}.xml.age" \
 "${BACKUP_DIR}/config_${DATE}.xml"

# Clean up unencrypted file
rm "${BACKUP_DIR}/config_${DATE}.xml"

# Commit to repository
cd "${REPO_DIR}"
git add .
git commit -m "config: backup ${DATE}"
git push origin main

With this, you have a change history of the configuration with timestamps and the ability to do git diff between encrypted versions (or decrypt two versions and compare them with diff). It’s not as clean as the VyOS model where configuration is plain text, but it works.

CI/CD Pipeline for Validation

Taking automation one step further: validate configuration changes before applying them. A lightweight pipeline in GitLab CI or GitHub Actions that:

Decrypts the config.xml in an ephemeral environment.
Validates the XML structure with xmllint.
Checks anti-patterns with custom rules (rules with source=any destination=any action=pass, users without OTP, unnecessary services enabled).
Runs the Ansible playbook in check mode against a staging environment (if it exists) or just validates the syntax.

This doesn’t replace manual testing, but it catches obvious errors before they reach production.

In terms of IaC maturity, OPNsense is at an intermediate point:

Aspect	OPNsense	VyOS	OpenWrt
REST API	Complete	Complete	Limited (ubus/JSON-RPC)
Terraform	No mature provider	Official provider (Foltik/vyos)	No provider
Ansible	ansibleguy.opnsense	vyos.vyos (official)	Community roles
Config format	XML (config.xml)	Plain text CLI	UCI (plain text)
Git workflow	Manual or scripted export	Native (text config)	Manual export

VyOS wins at IaC by design: its configuration is plain text from day one, with atomic commits and native rollback. OPNsense compensates with a solid REST API and the Ansible collection, but requires more effort to reach the same level of automation.

Auditing Framework: ISO 27001 and ENS

Why It Matters Even for a Homelab

It’s tempting to think that a formal auditing framework is only for companies. But the reality is more pragmatic: an auditing framework is a checklist that people with more experience than you have already validated. Following it avoids the “I forgot to review X” problem that appears when the security routine depends only on memory.

There’s an additional reason if you’re in Spain: the National Security Scheme (ENS, Real Decreto 311/2022) is mandatory for the public sector and its technology providers¹. This increasingly includes freelancers and small companies providing services to public administrations. Having the infrastructure aligned with the ENS, even at a basic level, isn’t just good practice—it’s a potential requirement.

Relevant ISO 27001:2022 Controls

ISO 27001:2022 organizes security controls in Annex A². The ones that apply directly to what was configured in this series:

Control	Description	OPNsense Implementation
A.8.20	Networks security	WAN deny-all firewall, IPS, CrowdSec, GeoIP
A.8.22	Networks segregation	5 VLANs with restrictive inter-VLAN rules
A.8.23	Web filtering	Zenarmor DPI with per-category policies
A.8.15	Logging	Remote syslog with TLS, Suricata EVE JSON
A.8.16	Monitoring activities	Suricata alerts, CrowdSec dashboards, Zenarmor
A.8.17	Clock synchronization	NTP configured in System > General (essential for log correlation)
A.5.15	Access control	Least-privilege policy, dedicated admin
A.5.17	Authentication information	16+ character passwords, OTP enabled
A.5.18	Access rights	Periodic review of users and permissions
A.8.2	Privileged access	Restricted root, separate admin, SSH keys only

The standard doesn’t prescribe exact review frequencies, but auditors expect: firewall rule review at least quarterly, privileged access review quarterly, and continuous log monitoring with weekly manual review.

Applicable ENS Measures

The ENS (RD 311/2022) classifies systems into three levels: basic, medium, and high. The relevant measures for a firewall:

ENS Measure	Description	Minimum Level	Implementation
mp.com.1	Secure perimeter	Medium	WAN firewall, GeoIP, deny-all by default
mp.com.2	Confidentiality protection	Medium	WireGuard VPN, DoT for DNS
mp.com.4	Networks segregation	Medium	VLANs with inter-VLAN rules
op.exp.2	Security configuration	Basic	SSH hardening, disabled services
op.exp.8	Activity logging	Basic	Remote syslog (2-year retention for medium/high)
op.acc.1	Identification	Basic	Unique users, no shared accounts
op.acc.5	Authentication mechanism	Basic	Strong passwords; OTP for medium/high
op.acc.7	Remote access	Basic	WireGuard VPN mandatory for remote admin
op.mon.1	Intrusion detection	Medium	Suricata IPS + CrowdSec

The CCN-STIC guides from the National Cryptology Center provide detailed implementation instructions. Specifically, CCN-STIC-811 for system interconnection and CCN-STIC-408 for perimeter security are the most relevant for this context³.

An important ENS detail: log retention for medium and high levels is a minimum of two years. If the remote syslog doesn’t have capacity for that, it needs to be planned. With Loki and compression, firewall logs from a homelab don’t take up much space, but it needs to be considered from the design phase.

Audit Calendar

Combining ISO 27001 and ENS recommendations with what’s realistic for a small environment:

Frequency	Task	Type
Daily	Automated review of IDS/IPS alerts and CrowdSec decisions	Automated
Weekly	Manual log review: blocked events, failed login attempts, anomalous traffic	Manual
Monthly	Firewall rule review and alias update. Verify threat feeds are updating	Manual
Quarterly	Complete rule review: identify rules with no hits, overly permissive rules, forgotten temporary rules	Manual
Quarterly	Access review: active users, permissions, valid SSH keys, API tokens	Manual
Semi-annual	Basic exposure test: `nmap` from outside the network against the public IP	Manual
Annual	Complete security posture review. Compare with previous year’s state	Manual

For automated daily review, a basic script that runs with cron:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


#!/bin/bash
# /root/scripts/daily_audit.sh
# Run with: crontab -e -> 0 7 * * * /root/scripts/daily_audit.sh

LOG="/var/log/daily_audit_$(date +%Y%m%d).log"

echo "=== Daily audit $(date) ===" > "$LOG"

# Critical Suricata alerts in the last 24h
echo -e "\n--- Suricata alerts (severity 1) ---" >> "$LOG"
cat /var/log/suricata/eve.json | \
 jq -r 'select(.event_type=="alert" and .alert.severity==1) | 
 "\(.timestamp) \(.alert.signature) src=\(.src_ip) dst=\(.dest_ip)"' | \
 tail -50 >> "$LOG"

# Active CrowdSec decisions
echo -e "\n--- CrowdSec active decisions ---" >> "$LOG"
cscli decisions list -o raw 2>/dev/null | wc -l >> "$LOG"

# Age of last backup
echo -e "\n--- Last backup ---" >> "$LOG"
LAST_BACKUP=$(ls -t /conf/backup/*.xml 2>/dev/null | head -1)
if [ -n "$LAST_BACKUP" ]; then
 stat -f "%Sm" "$LAST_BACKUP" >> "$LOG"
else
 echo "No backups found" >> "$LOG"
fi

# System status
echo -e "\n--- System resources ---" >> "$LOG"
echo "CPU: $(sysctl -n dev.cpu.0.temperature 2>/dev/null || echo 'N/A')" >> "$LOG"
echo "RAM: $(sysctl -n vm.stats.vm.v_free_count)" >> "$LOG"
echo "States: $(pfctl -si 2>/dev/null | grep 'current entries')" >> "$LOG"

# Send via email or copy to syslog
logger -t daily_audit "Audit completed. See $LOG"

This script isn’t meant to be a SIEM. It’s a first line of automated review that flags if there’s something requiring attention. For serious log analysis, the Grafana + Loki combination or a dedicated Wazuh is appropriate.

OPNsense vs. Alternatives

Before continuing to invest time in OPNsense, it’s worth comparing with the other serious open source firewall/router options. Not to migrate now, but to know what’s out there and make informed decisions if needs change.

VyOS

VyOS is a network operating system based on Debian with a CLI configuration model inspired by JunOS. It has no web interface.

What it does better than OPNsense:

Plain text configuration. VyOS config is a readable text file, with atomic commits and native rollback. It’s the IaC dream: git diff works directly on the configuration.
Official Terraform provider (Foltik/vyos). Real declarative network infrastructure.
Advanced routing. BGP, OSPF, IS-IS at scale. Supports routing tables with more than one million BGP prefixes.
Performance. The VPP dataplane enables 10 Gbps+ throughput with appropriate hardware.
Cloud-native. Direct deployment on AWS, Azure, and GCP with official support.

What it does worse:

No GUI. Everything is CLI or API. The learning curve is steep if you don’t come from enterprise networking.
Limited integrated security. There’s no equivalent to Suricata with GUI, no DPI like Zenarmor, no integrated CrowdSec. Suricata can be installed manually, but without the integration OPNsense offers.
Paid LTS. Since 2024, stable LTS images require a subscription. Rolling releases are free but without stability guarantee.

OpenWrt

OpenWrt is a Linux-based router operating system. Its strength is embedded hardware support.

What it does better than OPNsense:

Massive hardware support. Runs on more than 500 commercial router models, plus x86.
Native WiFi. Directly manages wireless interfaces, with excellent driver support and advanced AP configuration.
Lightweight. Can run on 128 MB RAM and 16 MB flash on embedded hardware.
Package ecosystem. More than 27,000 packages available.

What it does worse:

Basic security. nftables firewall without integrated IDS/IPS. Suricata and Snort packages are community-maintained, poorly maintained, and have performance problems on limited hardware.
No DPI. There’s no equivalent to Zenarmor.
Limited IaC. UCI is scriptable but there’s no Terraform provider or mature REST API.
Complicated updates. On x86, updating OpenWrt means reinstalling and restoring configuration. OPNsense updates with one click.

When to Choose Each

Criterion	OPNsense	VyOS	OpenWrt
Integrated security	Excellent (Suricata, CrowdSec, Zenarmor)	Basic	Minimal
IaC and automation	Good (API + Ansible)	Excellent (Terraform + text config)	Limited (UCI)
10G+ performance	Moderate	Excellent (VPP)	Not applicable
Learning curve	Moderate (GUI)	Steep (CLI)	Moderate
Cost	Free	Paid LTS, free rolling	Free
Ideal use case	Perimeter firewall/UTM	Enterprise or cloud edge router	WiFi AP, lightweight gateway

For a homelab or small office where security is the priority, OPNsense remains the best option. The combination of Suricata, CrowdSec, and Zenarmor with a usable web interface has no equivalent among the alternatives.

VyOS makes sense if the environment grows toward complex routing (multiple uplinks with BGP, SD-WAN) or if infrastructure is managed exclusively with Terraform.

OpenWrt makes sense as a complement: a WiFi AP running OpenWrt behind an OPNsense is a solid combination. But as a perimeter firewall for security, it falls short.

Conclusions and Next Steps

In three posts we’ve gone from a mini PC without an operating system to a segmented network with five VLANs, three detection layers (Suricata, CrowdSec, Zenarmor), VPN with WireGuard, encrypted DNS, automatic backups, automation with Ansible, and an auditing framework based on real standards.

It’s not perfect. OPNsense’s IaC doesn’t reach VyOS’s level. Zenarmor has a licensing model that limits advanced features in the free version. And maintaining an audit routine requires discipline that’s easy to set aside when everything seems to work well.

But it’s a solid foundation to keep building on. There are topics that were deliberately left out of this series because they deserve their own depth:

Wazuh SIEM integration: correlation of Suricata, CrowdSec, and system logs in one place, with centralized alerts and dashboards. It’s the natural step for anyone wanting real security monitoring.
Multi-WAN and failover: configure two internet connections with load balancing and automatic failover. Relevant when availability matters.
Advanced HAProxy: mutual TLS (mTLS) with client certificates, certificate authentication for internal services, OAuth2 as an authentication layer against self-hosted applications.
Network monitoring with NetFlow/Insight: detailed traffic analysis by protocol, host, and port to detect anomalies that IDS doesn’t catch.
Complete automation with Terraform: if OPNsense gets a mature Terraform provider (or if there’s a partial migration to VyOS for routing), declarative management of the entire network.

If there’s interest, a fourth post can cover Wazuh integration and advanced monitoring. That’s where the jump from “secure homelab” to “infrastructure with real visibility” becomes most evident.

Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. BOE-A-2022-7191. ↩︎
ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ↩︎
The CCN-STIC guides from the National Cryptology Center provide detailed instructions for ENS implementation. Specifically, CCN-STIC-811 covers system interconnection and CCN-STIC-408 covers perimeter security. ↩︎

OPNsense: network segmentation, VLANs and hardening

Fri, 03 Apr 2026 00:00:00 +0000

Native encrypted backups

Losing the OPNsense configuration after hours of tweaking is the kind of disaster that only happens once. After that incident, automatic backups are configured.

OPNsense has a native backup system that exports all configuration to an XML file. Since version 24.1, these backups can be encrypted directly from the web interface.

Encrypted backup configuration

In System > Configuration > Backups:

Go to the Google Drive / Nextcloud section if you want remote backup, or stick with local backup.
Check the Encrypt backup box and enter an encryption password. This password is independent of system credentials. Store it in a password manager, because without it the backup is unrecoverable.
In the automatic backup section (Scheduled), configure the frequency. A daily backup is reasonable for most environments.

Manual backup from the interface

In System > Configuration > Backups, the Download configuration button generates an XML with the current configuration. If encryption was selected, the downloaded file will be encrypted with AES-256-CBC.

Backup from the console

To automate backups from the command line:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Export the configuration
cp /conf/config.xml /root/backup_$(date +%Y%m%d).xml

# Encrypt with OpenSSL
openssl enc -aes-256-cbc -salt -pbkdf2 \
 -in /root/backup_$(date +%Y%m%d).xml \
 -out /root/backup_$(date +%Y%m%d).xml.enc

# Remove the unencrypted file
rm /root/backup_$(date +%Y%m%d).xml

It is recommended to copy encrypted backups to external storage: a NAS, an S3 bucket, or even a private Git repository (the encrypted XML is small, a few hundred KB).

Restoration

To restore, go to System > Configuration > Backups, upload the file and, if encrypted, enter the password. OPNsense applies the configuration and restarts the affected services.

Static IP assignment

There are devices that need to always have the same IP: servers, NAS, printers, surveillance cameras. This can be done in two ways: configuring a static IP on the device itself or, which is cleaner, assigning DHCP reservations in OPNsense.

DHCP reservations (the recommended way)

In Services > DHCPv4 > [interface]:

Go to the DHCP Static Mappings section.
Add a new entry with:
- MAC Address: the MAC address of the device.
- IP Address: the IP you want to always assign.
- Hostname: a descriptive name.

The advantage of doing it this way is that management is centralized in OPNsense. If you change routers tomorrow, devices don’t need to be reconfigured.

Range convention

A convention that works well for organizing the network:

Range	Usage
.1	Gateway (OPNsense)
.2 - .19	Infrastructure (switches, APs, NAS)
.20 - .49	Servers and services
.50 - .99	Fixed IP devices (printers, cameras)
.100 - .254	Dynamic DHCP pool

This means that just by seeing a device’s IP, you already know which category it falls into.

Zenarmor (Sensei)

Zenarmor is a deep packet inspection (DPI) plugin for OPNsense. It goes beyond what Suricata or CrowdSec do because it inspects traffic at the application level: it can distinguish between Netflix and YouTube, between Telegram and WhatsApp, between legitimate traffic and potentially dangerous applications.

What it does exactly

Application-based traffic classification: identifies more than 300 applications and protocols.
Content filtering by categories: allows blocking entire categories (gambling, malware, adult content) without needing to maintain lists manually.
Encrypted traffic analysis (TLS): Zenarmor can classify HTTPS traffic without decrypting it, using metadata like SNI, JA3 fingerprints, and connection patterns.
Detailed reporting: dashboards with consumption by device, application, and category.

Installation

In System > Firmware > Plugins, search for os-sunnyvalley and install. After installation, Zenarmor appears in the main menu.

When starting Zenarmor for the first time, a configuration wizard runs:

Deployment mode: choose Routed Mode to inspect all traffic passing through OPNsense. Bridge mode is for specific cases.
Database engine: Zenarmor uses a local database for logs. For modest hardware (N100), select SQLite. For more powerful hardware, Elasticsearch gives better query performance.
Interfaces to protect: select the LAN interfaces you want to inspect.
Default policy: start with a permissive policy (monitor only) and adjust after seeing actual traffic.

Policy configuration

In Zenarmor > Policies:

Policies are applied by interface or by device group. A reasonable configuration:

General policy (main LAN):

Block categories: Malware, Phishing, Cryptomining, C2 (Command & Control).
Monitor but allow: Streaming, Social Media, Gaming.
Allow everything else.

Policy for IoT (we’ll create this with VLANs later):

Block everything except the necessary domains for each device.
IoT devices should not be able to access the internet freely.

Policy for guests:

Block: P2P, Tor, VPN (to avoid filter bypass).
Limit bandwidth per device.

Difference with Suricata and CrowdSec

Feature	Suricata (IDS/IPS)	CrowdSec	Zenarmor
Inspection	Packets and signatures	Logs and patterns	Application (DPI)
What it detects	Exploits, malware, C2	Brute force, scans	Applications, categories
Blocking	By signature/rule	By IP (temp ban)	By application/category
Main resource	CPU (high)	CPU (low)	CPU (medium) + RAM
Complementary	Yes	Yes	Yes

All three complement each other. Suricata looks for known threats in traffic. CrowdSec detects malicious behavior in logs and shares intelligence. Zenarmor classifies and filters at the application level. Using them together gives security coverage that is hard to beat on home equipment.

Disable insecure SSH

SSH is the usual way to access the OPNsense console remotely. But the default configuration has aspects that should be changed.

Secure SSH configuration

In System > Settings > Administration, SSH section:

Disable root login via SSH. Create a specific user with SSH access and sudo permissions.
Change the default port. Port 22 is the first one bots scan. Change to a high port (for example, 2222 or something less predictable).
Disable password authentication. Use exclusively SSH keys:

1
2
3
4
5


# On your local machine, generate a key pair if you don't have one
ssh-keygen -t ed25519 -C "opnsense-admin"

# Copy the public key
cat ~/.ssh/id_ed25519.pub

Paste the public key in the user’s profile at System > Access > Users > [user] > Authorized Keys.
In the SSH configuration, uncheck Permit Password Login.

SSH access restriction by firewall

Create a firewall rule that only allows SSH from specific IPs:

In Firewall > Rules > LAN, create a rule:

Action: Pass
Protocol: TCP
Source: alias with admin IPs
Destination: This Firewall
Destination port: the configured SSH port

And another rule that blocks SSH from any other source.

VLANs: network segmentation

Segmentation with VLANs is probably the most important change you can make to home network security. Without segmentation, a compromised WiFi bulb has direct access to the NAS with family photos. With VLANs, each type of device lives in its own isolated segment.

VLAN design

VLAN ID	Name	Subnet	Purpose
10	Main	192.168.10.0/24	Trusted devices: laptops, desktops, personal mobiles
20	Guests	192.168.20.0/24	Guest devices, no access to internal network
30	IoT	192.168.30.0/24	IoT devices: cameras, sensors, bulbs, vacuums
40	Servers	192.168.40.0/24	Servers, NAS, self-hosted services
50	Management	192.168.50.0/24	Infrastructure management: switches, APs, OPNsense itself

Creating VLANs in OPNsense

For each VLAN:

Go to Interfaces > Other Types > VLAN.
Create a new VLAN:
- Parent interface: the physical interface connected to the managed switch (for example, igb1).
- VLAN tag: the ID from the table above (10, 20, 30, 40, 50).
- Description: the name of the VLAN.
Go to Interfaces > Assignments and assign each VLAN as a new interface.
Configure each interface:
- Enable the interface.
- Assign a static IP: the gateway IP for that subnet (for example, 192.168.10.1/24 for VLAN 10).
Configure DHCP in Services > DHCPv4 for each VLAN with its corresponding range.

Switch configuration

The managed switch needs to be configured to understand VLANs:

The trunk port going to OPNsense must be tagged for all VLANs (10, 20, 30, 40, 50).
Access ports are configured as untagged in the corresponding VLAN. For example, the port where a guest AP is connected is set to untagged on VLAN 20.
If the AP supports multiple SSIDs with VLANs (like Ubiquiti or TP-Link Omada), you can create one SSID per VLAN and the AP handles tagging the traffic.

Firewall rules between VLANs

This is the point where segmentation is really defined. Without firewall rules, VLANs share the same router and can communicate with each other. Explicit rules need to be created.

General principle: deny everything between VLANs by default and allow only what’s necessary.

VLAN 10 (Main):

Action	Source	Destination	Port	Description
Pass	Main net	*	*	Full internet access
Pass	Main net	Servers net	*	Access to internal services
Block	Main net	Management net	*	No direct access to management
Block	Main net	IoT net	*	IoT isolation

VLAN 20 (Guests):

Action	Source	Destination	Port	Description
Pass	Guests net	*	80, 443, 53	Only web browsing and DNS
Block	Guests net	RFC1918	*	No access to internal networks

VLAN 30 (IoT):

Action	Source	Destination	Port	Description
Pass	IoT net	*	443, 8883	Only HTTPS and MQTT for cloud
Pass	IoT net	IoT gateway	53	DNS
Block	IoT net	RFC1918	*	No access to internal networks

VLAN 40 (Servers):

Action	Source	Destination	Port	Description
Pass	Servers net	*	80, 443, 53	Internet access for updates
Pass	Servers net	Servers net	*	Inter-service communication
Block	Servers net	Main net	*	Servers don’t initiate connections to Main

VLAN 50 (Management):

Action	Source	Destination	Port	Description
Pass	Management net	*	*	Full access (admins only)

To implement the RFC1918 network blocking rule (which covers all private subnets), create an alias in Firewall > Aliases:

Name: RFC1918
Type: Network
Content: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

This alias is used as the destination in blocking rules to prevent VLANs like Guests or IoT from accessing any internal network.

Hardening and best practices

Updates

The first and most basic thing: keep OPNsense updated. Security updates are published regularly and patches are applied quickly.

Configure email update notifications.
Apply updates during low-usage times.
Before updating, make a backup (it’s already automated if you followed the first section).

DNS over TLS (DoT)

Configure Unbound (OPNsense’s DNS resolver) to use DNS over TLS:

In Services > Unbound DNS > General:

Enable DNS over TLS.
In Custom forwarding, add DNS servers that support DoT:

1
2
3
4
5
6
7


# Quad9 (includes malware filtering)
9.9.9.9@853#dns.quad9.net
149.112.112.112@853#dns.quad9.net

# Cloudflare
1.1.1.1@853#cloudflare-dns.com
1.0.0.1@853#cloudflare-dns.com

This encrypts DNS queries between OPNsense and the resolver, preventing the ISP from seeing which domains each device queries.

Disable unnecessary services

In System > Settings > Administration:

Disable UPnP unless strictly necessary (and even then, limit it to specific interfaces).
Disable SNMP if it’s not used for monitoring.
Review installed plugins and uninstall those not in use.

Centralized logging

OPNsense can send logs to an external syslog server. If you have a monitoring stack (Grafana + Loki, or ELK), configure sending in System > Settings > Logging > Remote:

Server: the syslog server IP.
Protocol: TCP with TLS if possible.
Facility: select which logs to send (firewall, system, IDS).

Regular audit

Establish a review routine:

Weekly: review IDS/IPS and CrowdSec logs. Look for recurring patterns.
Monthly: review firewall rules. Are there rules that no longer make sense? Has any new device been added that needs specific rules?
Quarterly: review users and permissions. Is each user still necessary? Are SSH keys still valid?

In the third and final post of the series, we’ll review everything configured, check the overall security posture, and look at advanced practices.

OPNsense: from hardware to a working firewall

Wed, 01 Apr 2026 00:00:00 +0000

What hardware OPNsense needs

Before opening the installer, it’s worth knowing what OPNsense requires and what makes sense to buy. The official documentation distinguishes between minimum and recommended, but in practice there are nuances that matter quite a bit.

Official minimum requirements

Resource	Minimum	Recommended
CPU	64-bit x86-64, 1 GHz	Recent multi-core with AES-NI
RAM	2 GB	8 GB
Storage	40 GB SSD	120 GB SSD
NICs	2 network interfaces	2+ Intel interfaces

AES-NI has been mandatory since OPNsense 24.1. Without this instruction the installer won’t even boot. Any Intel processor from sixth generation onward includes it, and it’s been present in AMD since Ryzen.

Budget options that work

The cheapest option I’ve had good experience with is a mini PC with an Intel N100 or N200 processor. They’re designed for low power consumption and have AES-NI, which covers the main requirement. They can be found with four Intel i226-V Ethernet ports for under 150 euros.

Some specific models that work:

Topton N100/N200 with 4x i226-V: between 120 and 170 euros depending on configuration. They come without RAM or SSD, which are purchased separately. An 8 GB DDR5 module and a 128 GB SSD add about 30 euros more.
Protectli VP2420 or VP2410: more expensive (around 300 euros), but with official support and an aluminum case that dissipates heat well. A good option if you prefer something with serious warranty.
Recycled hardware with two NICs: a Dell OptiPlex or Lenovo ThinkCentre with a dual-port Intel PCIe card works perfectly. They can be found for 50-80 euros in second-hand markets.

What really matters: make sure the network interfaces are Intel. Realtek works, but they cause problems with offloading and performance under load. It’s worth paying the difference.

Installation

Installing OPNsense is straightforward. Download the ISO image from the official website, write it to a USB with dd or Rufus on Windows, and boot from the USB.

1
2


# Write the image to a USB (be careful to select the correct device)
dd if=OPNsense-24.7-dvd-amd64.iso of=/dev/sdX bs=4M status=progress

On boot, a live environment appears with the option to try before installing. The default user is installer with password opnsense.

During installation:

Select the destination disk for installation (the internal SSD, not the USB).
Choose the filesystem. UFS is the simple and stable option. ZFS has advantages (snapshots, compression), but for a firewall with a single disk, UFS is sufficient.
Define the root password.
Remove the USB and reboot.

After reboot, OPNsense boots directly and presents a text console with a basic menu. From there you can assign interfaces and configure the LAN IP address to access the web interface.

PPPoE configuration on WAN

If your ISP uses PPPoE (as is the case with many fiber connections in Spain and Latin America), it needs to be configured on the WAN interface.

In Interfaces > WAN:

Change the IPv4 configuration type to PPPoE.
Enter the username and password provided by the ISP.
With most providers you don’t need to touch the MTU, but if you notice fragmentation issues, adjust it to 1492 (the standard for PPPoE over Ethernet with MTU 1500).
Save and apply.

If the connection doesn’t come up, verify that the ONT cable goes directly to the port assigned as WAN. Some ISP ONTs need to be in bridge mode for OPNsense to negotiate the PPPoE session directly.

LAN in bridge mode

There are situations where it’s useful to group multiple physical ports into the same network segment, for example when the mini PC has four ports and we want three of them to work as a switch without additional hardware.

To configure a bridge in OPNsense:

Go to Interfaces > Other Types > Bridge.
Create a new bridge and add the interfaces you want to group (for example, igb1, igb2, igb3).
Go to Interfaces > Assignments and assign the newly created bridge as the LAN interface.
Configure the static LAN IP on the bridge interface (for example, 192.168.1.1/24).
Enable the DHCP server in Services > DHCPv4 pointing to the bridge interface.

With this, all three ports share the same network segment and DHCP serves addresses for all of them.

Wireless interface and firmware

OPNsense supports some WiFi cards, but the support is limited compared to Linux. Atheros cards work best, but many need additional firmware that isn’t included by default.

To install the required firmware:

1
2
3
4


# From the OPNsense console (option 8 from the menu for shell)
pkg install wifi-firmware-atheros
# Or for Intel cards:
pkg install wifi-firmware-intel

After installing the firmware, restart the system. The wireless interface should appear in Interfaces > Assignments.

To configure the access point:

Go to Interfaces > Wireless and create a new device in Access Point mode.
Select the standard (802.11ac/ax if the card supports it).
Configure the SSID and WPA2/WPA3 security.
Assign the wireless interface and give it an IP in a different range from the wired LAN, or add it to the existing bridge if you want it on the same segment.

An honest warning: integrated WiFi in OPNsense works, but don’t expect the performance or stability of a dedicated access point. For serious use, it’s better to use an external AP (Ubiquiti, TP-Link Omada) and let OPNsense handle only routing and firewall.

IDS and IPS: intrusion detection and prevention

OPNsense includes Suricata as the IDS/IPS engine. The difference between the two modes is simple: IDS detects and logs, IPS detects and blocks.

Initial configuration

In Services > Intrusion Detection:

Enable IDS: check the activation box.
IPS mode: if you want it to block traffic, change the mode to IPS. This requires Suricata to run in inline mode, which is the default behavior in OPNsense.
Interfaces: select WAN at minimum. If you want to inspect internal traffic as well, add LAN, but this consumes quite a bit more CPU.
Pattern matcher: select Hyperscan if the hardware supports it (processors with SSSE3). It’s significantly faster than the default matcher.

Recommended rule sets in 2026

It’s not about activating all available rules. That consumes resources and generates false positives. A reasonable selection:

Rule set	What it’s for	Recommendation
ET Open (Emerging Threats)	Known threats, malware, C2	Activate. It’s the foundation
Abuse.ch SSL Blacklist	Certificates associated with malware	Activate
Abuse.ch URLhaus	Malware distribution URLs	Activate
ET Open Compromised	Known compromised IPs	Activate
Feodo Tracker	Banking botnets	Activate
ET Open Tor	Tor traffic	Only if you want to block Tor
Snort VRT	Snort commercial rules	Requires subscription, not essential

Best practices for IDS/IPS in 2026

Don’t activate all rules. Select the ones that make sense for your environment. A home network doesn’t need SCADA or SQL server rules.
Automatic rule updates: configure scheduled rule downloads. In Schedule within IDS, set a daily update.
Review logs before switching to IPS mode. Leave the system in IDS mode for at least a week to identify false positives. If something legitimate triggers alerts, create an exception before starting to block.
Monitor CPU usage. Suricata can consume a lot on modest hardware. If the processor stays above 80% usage with IPS active, reduce the number of rules or limit inspection to the WAN interface.
Use EVE JSON logging to export events to a SIEM or analysis tool. The JSON format facilitates integration with Elasticsearch, Grafana, or Wazuh.
Don’t rely solely on IDS/IPS. It’s one more layer of defense. It doesn’t replace good firewall rules, network segmentation, or regular updates.

CrowdSec

CrowdSec complements Suricata with a different approach: log analysis and shared decisions with the community. While Suricata inspects packets in real time, CrowdSec analyzes service logs and applies bans based on behavior patterns.

Installation

CrowdSec has an official plugin for OPNsense:

Go to System > Firmware > Plugins.
Search for os-crowdsec and install it.
After installation, it appears in Services > CrowdSec.

Recommended configuration and collections

(Optional) After installation, register the instance in the CrowdSec central console:

1
2


# From the OPNsense shell
cscli console enroll <your-enrollment-key>

The collections define what attack patterns CrowdSec detects. Recommended for a home or small office firewall:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# Base collection for firewalls (usually already installed)
cscli collections install crowdsecurity/freebsd

# Detection of port scanning and SSH brute force
cscli collections install crowdsecurity/sshd
cscli collections install crowdsecurity/iptables

# HTTP protection if you expose web services
cscli collections install crowdsecurity/nginx
cscli collections install crowdsecurity/base-http-scenarios

# Aggressive scan detection
cscli collections install crowdsecurity/http-cve

# Community blocklists (known malicious IPs)
cscli collections install crowdsecurity/whitelist-good-actors

Enable the firewall bouncer so CrowdSec can create blocking rules directly in the OPNsense firewall:

1

cscli bouncers add opnsense-firewall

The generated token is entered in the plugin configuration in the web interface, in Services > CrowdSec > Bouncer.

The real advantage of CrowdSec is shared intelligence. When a community member detects an attacking IP, that information is distributed to everyone else. It’s like having a collaborative IP reputation system.

WireGuard

WireGuard is the cleanest option for VPN in 2026. Faster, simpler, and with better cryptography than OpenVPN or IPsec.

Server configuration

In VPN > WireGuard:

Create an instance: go to the Instances tab (or Local in earlier versions) and add a new one.
- Generate a key pair (done automatically when creating the instance).
- Listen port: 51820 (or whatever you prefer).
- Tunnel address: 10.10.10.1/24.
Add a peer: in the Peers tab, create a new pair.
- Client’s public key (generated on the client device).
- Allowed IPs: 10.10.10.2/32 (the IP the client will have inside the tunnel).
Assign the interface: go to Interfaces > Assignments, assign the WireGuard interface (wg0 or wg1), enable it, and don’t touch the IP configuration (it’s already defined in WireGuard).

Client configuration

On the client (mobile, laptop), the configuration is a simple file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[Interface]
PrivateKey = <client-private-key>
Address = 10.10.10.2/24
DNS = 10.10.10.1

[Peer]
PublicKey = <server-public-key>
Endpoint = <public-ip-or-ddns>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

With AllowedIPs = 0.0.0.0/0, all client traffic goes through the tunnel. If you only want to access the local network, change to AllowedIPs = 192.168.1.0/24, 10.10.10.0/24.

Firewall rules

It’s no use configuring services if the firewall rules don’t allow the correct traffic. OPNsense blocks everything by default on WAN, which is correct. The work is in allowing what’s necessary on LAN and WireGuard.

Rules for LAN

In Firewall > Rules > LAN:

Action	Protocol	Source	Destination	Destination Port	Description
Pass	IPv4+6	LAN net	*	*	Allow LAN outbound
Pass	IPv4	LAN net	LAN address	53	DNS to firewall
Pass	IPv4	LAN net	LAN address	443	WebUI access

The first rule is the most permissive and allows LAN to go out to the internet. In the second post of the series we’ll see how to restrict this with VLANs.

Rules for WireGuard

In Firewall > Rules > WireGuard (or the assigned interface):

Action	Protocol	Source	Destination	Destination Port	Description
Pass	IPv4	WireGuard net	LAN net	*	LAN access from VPN
Pass	IPv4	WireGuard net	*	*	Internet outbound from VPN

Rule on WAN for WireGuard

In Firewall > Rules > WAN, add a rule to allow incoming connection to the WireGuard port:

Action	Protocol	Source	Destination	Destination Port	Description
Pass	UDP	*	WAN address	51820	Incoming WireGuard

Offloading and hardware tuning

When everything is working, it’s time to squeeze out the performance. OPNsense runs on FreeBSD, and it has several offloading options that can make a noticeable difference.

What offloading is

Offloading means delegating certain network operations to the network card hardware instead of processing them in software on the CPU. This frees up CPU cycles for other tasks (like Suricata or CrowdSec) and reduces latency.

Available options

In Interfaces > Settings:

Hardware CRC (Checksum Offloading): delegates TCP/UDP/IP checksum calculation to the network card. Enable if the NIC supports it (Intel i210/i225/i226 do). Measurably reduces CPU load.
Hardware TSO (TCP Segmentation Offloading): the network card handles splitting large TCP packets into smaller segments. Improves throughput in large transfers. Can cause problems with some IPS configurations, so test and verify.
Hardware LRO (Large Receive Offloading): groups small incoming packets into larger blocks before passing them to the CPU. Reduces interrupts. Do not enable if using IPS in inline mode, as it interferes with packet inspection.
VLAN Hardware Filtering: if VLANs are used (we’ll cover this in the second post), let the NIC filter by VLAN ID in hardware.

Additional system tuning

In System > Settings > Tunables, some useful adjustments:

1
2
3
4
5
6
7
8
9


# Increase network buffers
net.inet.tcp.recvspace=65536
net.inet.tcp.sendspace=65536

# Enable RACK and BBR if hardware supports it (FreeBSD 14+)
net.inet.tcp.functions_default=bbr

# Adjust the number of NIC queues
hw.igb.num_queues=4

Don’t obsess over tuning. On most home connections (up to 1 Gbps symmetric), an N100 with the default settings already gives maximum performance. Tuning starts to matter when you want to squeeze 2.5 Gbps connections or more, or when Suricata consumes too much CPU.

User management and web interface security

Using root for day-to-day web interface access is bad practice. If someone compromises those credentials, they have full control.

Create a new administrator user

In System > Access > Users:

Create a new user with a descriptive name (not admin, something less predictable).
Assign a strong password. Minimum 16 characters, generated with a password manager.
In Effective Privileges, assign the admins group.
Enable OTP authentication if possible. OPNsense supports native TOTP, so it can be used with any authenticator app.

Change the root password

In System > Access > Users, select root and change the password to something long and random. Store this password in a safe place (password manager) and don’t use it for daily access.

A more radical option: disable root login on the web interface. This can be done by removing web access privileges from the root user, leaving only physical console access as a last resort.

Restrict web interface access

By default, the web interface is accessible from the entire LAN. This can be restricted:

Change the HTTPS port: in System > Settings > Administration, change the port from 443 to another non-standard one (for example, 8443).
Restrict by source IP: create an alias in Firewall > Aliases with the IPs from which web interface access is allowed. Then, in the LAN firewall rules, create a rule that allows access to the WebUI port only from that alias, and a blocking rule for everything else.
Enable HTTPS with your own certificate: in System > Trust > Certificates, generate a self-signed certificate or import one from Let’s Encrypt. This eliminates browser warnings and ensures the connection is properly encrypted.
Brute force protection: in System > Settings > Administration, configure the maximum number of failed attempts and the lockout time.
Disable HTTP: make sure only HTTPS is enabled. Unencrypted HTTP access to a firewall’s admin interface makes no sense.

In the next post in the series, we’ll take security further with encrypted backups, VLANs, Zenarmor, and system hardening.