pfSense and OPNsense Hardening Guide: Admin Access, Keys and Logging

pfSense and OPNsense firewalls often guard small businesses, branch offices and labs with factory administrator accounts, a web interface reachable from too many networks and logs that never leave the box. Both are open source, FreeBSD-based firewalls with a web configurator, SSH, VPN services and package ecosystems, so the hardening problems are the same: who can administer the device, how they authenticate, what machine credentials exist, and whether anyone would notice a change. This guide gives a side-by-side hardening baseline for pfSense (Community Edition and Plus) and OPNsense, covering accounts and privileges, management plane exposure, API keys, VPN user authentication, remote logging and patching. It is for network and security engineers in SMB and mid-size environments, and for anyone building a benchmark-aligned configuration. Settings below were checked against the Netgate and OPNsense documentation on 27 October 2026. CIS publishes a CIS pfSense Firewall Benchmark (v1.1.1) and a CIS OPNsense Benchmark (v1.0.0); use those for audit-grade control text.

Key takeaways

• Change the factory account first. pfSense ships with admin / pfsense and OPNsense with root / opnsense. Netgate's own documentation says not to keep the default even in a lab; pfSense Plus 24.03 and later force a change at first login.
• The management plane belongs on one network. Bind the web GUI and SSH to a dedicated management interface, never WAN, and use firewall rules rather than relying on the anti-lockout rule.
• Use named accounts with group privileges. Both platforms support LDAP or RADIUS for authentication, but a local user is still required to carry privileges; build groups, not per-user grants.
• Treat API keys and SSH keys as non-human identities. OPNsense API key and secret pairs inherit the owning user's privileges; one key per application, a dedicated low-privilege user, and revocation when the integration ends.
• Logs must leave the firewall. pfSense's built-in remote syslog is UDP and cleartext, so send it over a management network or VPN, or use syslog-ng for TCP and TLS; OPNsense supports TLS destinations natively.

How identity and access work in pfSense and OPNsense

Both products use a local user manager as the link between an identity and its privileges. External directories answer "is this password valid", but the firewall's access control list still needs a matching local user or group for GUI and SSH access.

Users who reach the firewall for services, not administration

VPN users (OpenVPN, IPsec), captive portal users and proxy users authenticate against the same user manager or authentication servers. These accounts are the bigger population and the bigger risk: a dormant VPN account without MFA was the way in for the Colonial Pipeline ransomware attack. Require MFA for every remote access account (OPNsense TOTP, or RADIUS with MFA on pfSense), set the OPNsense Expiration date field for contractors, and disable accounts as part of offboarding. See the VPN Security Guide.

Admin roles and privileged access

Neither platform has a fine-grained "read-only administrator" role that is safe by default. Every privilege maps to GUI pages, and some pages are equivalent to full administrator access.

• Factory account handling: after creating named administrator accounts, set a long random password on admin or root (OPNsense offers Scrambled Password for accounts that should not log in), keep it in a vault as break-glass, and alert on its use. See the Break-Glass Account Guide.
• SSH: pfSense SSHd Key Only defaults to "Password or Public Key"; set "Public Key Only". In OPNsense disable Permit Root Login and Permit password login and add keys under each user's Authorized Keys. Keep agent forwarding off (the pfSense default). See the SSH Key Management Guide.
• Brute-force protection: pfSense Login Protection (sshguard) defaults to a threshold of 30, block time of 120 seconds and detection time of 1,800 seconds. Keep it on, and avoid adding broad subnets to the pass list.

Integrations, API tokens and service accounts

Firewalls accumulate machine credentials quietly: monitoring, configuration backup, automation, high availability sync, VPN certificates and package integrations.

• API hygiene: OPNsense recommends a unique key for every application. Record the owner and purpose against each key, review quarterly, and delete keys for retired tools. Always verify the firewall certificate from API clients; do not disable TLS verification in scripts. See the API Key Management Guide.
• Packages: each package (proxy, IDS, DNS filtering, VPN clients) adds code running on the firewall and sometimes its own credentials. Install only what is needed and remove unused packages.

Logging and detection

Both firewalls keep logs locally with limited retention, and an attacker with administrator access can clear them. Forward them off-box.

What to alert on

• Administrator logins: GUI and SSH logins by the factory account, logins from outside the management subnet, and repeated failures. pfSense logs successful GUI logins at emergency level by default, which makes them easy to forward.
• Configuration changes: pfSense and OPNsense record a configuration history with the user and description of each change; alert on changes outside change windows, new users or privileges, new API keys and rule changes allowing WAN access to management ports.
• Firewall defence impairment: rule deletions, disabled logging or a remote syslog target removed map to ATT&CK T1686 Disable or Modify System Firewall.
• Remote access abuse: VPN logins at unusual hours or from new countries, and accounts that log in after a long gap, map to T1133 External Remote Services and T1078.001 Default Accounts.
• Exploitation: GUI errors and unexpected processes after a published advisory, mapped to T1190 Exploit Public-Facing Application.

For detection content on these sources, see the VPN and Firewall Log Detection Guide and the Network Device Syslog and Configuration Change Detection Guide.

Metrics

• Management exposure: firewalls with GUI or SSH reachable from WAN or user networks (target 0).
• Factory account use: logins as admin or root outside break-glass tests (target 0).
• Remote access MFA coverage: share of VPN users with a second factor (target 100 percent).
• Patch lag: days from a pfSense-SA or OPNsense security release to deployment.
• Log continuity: firewalls with no syslog received in the last 24 hours (target 0).
• Key inventory: API and SSH keys with a recorded owner (target 100 percent).

Hardening baseline

Apply in this order. Keep console access available and tested before touching listen interfaces or anti-lockout behaviour; both vendors warn that mistakes here lock you out of the GUI and SSH.

1. Back up and record: export an encrypted configuration backup and confirm console (VGA or serial) access works.
2. Accounts: create named administrator accounts in an administrators group, connect LDAP or RADIUS if used, randomise and vault the factory account password.
3. Management interface: create or select a management interface, set the GUI and SSH listen interfaces to it (OPNsense Listen interfaces), add explicit allow rules from the administration subnet, then disable the anti-lockout rule so access is governed by rules you control. Never allow GUI or SSH on WAN; for remote administration use a VPN into the management network.
4. Web GUI: HTTPS only with a certificate from your internal CA instead of the self-signed default, HSTS on, DNS rebind check and HTTP_REFERER enforcement left on, session timeout set (for example 15 to 30 minutes), login autocomplete disabled, and on OPNsense Strict security enabled where your packages allow.
5. SSH: disabled unless needed; if enabled, key only, no root login, listen on management only.
6. Console: password protect the console menu, and physically secure the device.
7. Remote access users: MFA for all VPN and captive portal accounts, expiry dates for temporary users, certificate-based VPN where possible.
8. Logging and time: configure NTP, remote syslog over a protected path, and on OPNsense consider disabling local logging on flash-based devices once remote logging works.
9. Updates: subscribe to Netgate advisories (named pfSense-SA-YY_NN.component) and OPNsense release notes; run the OPNsense firmware security audit, which checks installed packages against known vulnerabilities. Take a configuration backup (and a boot environment snapshot where supported) before each upgrade so you can roll back.
10. Review: compare against the CIS Benchmark for the product quarterly and after upgrades. See the Firewall Rule Review Checklist.

Small office or larger estate

• Single site: one management VLAN, two named administrators plus a vaulted factory account, OPNsense TOTP or RADIUS MFA, remote syslog to a small collector or managed SIEM.
• Many sites: central authentication through LDAP or RADIUS with MFA, configuration management through API or backups pulled by a dedicated low-privilege identity, standard images per site, and a central log pipeline with configuration change alerts. At this scale, the identity that pulls backups is the most sensitive credential, because the backups contain every secret.

Common misconfigurations

• GUI on WAN "temporarily": a rule opened for remote support that is never removed, exposing the web configurator, which receives regular webgui security advisories, to the internet.
• Factory account as the daily login: no attribution in the configuration history and a known username for brute force.
• Helpdesk with diagnostics privileges: a "limited" account that can run commands or restore a configuration is an administrator.
• VPN users without MFA and without expiry: local accounts created for a project years ago that still work.
• Cleartext syslog across the internet: pfSense's built-in syslog is UDP and unencrypted; sending it across a WAN leaks network and authentication details.
• Unencrypted config.xml backups on shared drives or in tickets, containing password hashes, VPN keys and directory bind credentials.

Framework mapping

Practitioner checklist

• Change and vault the factory admin or root password and alert on its use.
• Create named administrator accounts in a group pinned to the management network.
• Bind the GUI and SSH to a management interface only and replace the anti-lockout rule with explicit rules.
• Use HTTPS with an internal CA certificate, HSTS, DNS rebind and HTTP_REFERER checks, and a session timeout.
• Set SSH to key only with root login and password login disabled, or turn SSH off.
• Remove diagnostics, command and restore privileges from every non-administrator role.
• Require MFA and expiry dates for all VPN and captive portal users.
• Issue one API key per integration to a dedicated low-privilege user and review keys quarterly.
• Forward logs to a SIEM over a protected path and alert on configuration and user changes.
• Track pfSense-SA advisories and OPNsense releases, back up before upgrades, and audit against the CIS Benchmark.

Standards and references

• Netgate: pfSense Advanced Configuration, Admin Access Tab
• Netgate: pfSense Default Username and Password
• Netgate: pfSense Remote Logging
• Netgate: Security Advisories
• OPNsense: Settings (Administration, Secure Shell, Logging)
• OPNsense: Access and User Management
• OPNsense: Use the API
• CIS: pfSense Firewall Benchmark

Related NHI Mgmt Group resources: Firewall Management Guide · SOHO and SMB Router Hardening Guide · Edge Device Security Guide · VPN and Firewall Log Detection Guide