I have been conducting a detailed analysis of the default configurations in both pfSense CE 2.7.x and OPNsense 24.x, focusing on their out-of-the-box security posture. My methodology involves comparing the enabled services, firewall rules, system hardening settings, and cryptographic defaults against several common benchmarks, including the CIS Benchmarks where applicable and generalized best practices for network security appliances. The goal is to understand the inherent security stance before any administrator intervention, which is critical for establishing a trustworthy baseline.
A structured comparison of the key areas reveals significant philosophical differences between the two projects:
* **Remote Administration Access:**
* pfSense CE defaults to enabling the HTTPS webGUI on all interfaces, including the WAN. This is a well-documented choice for convenience, but it immediately exposes a large attack surface. It relies on the user to change this during or after setup.
* OPNsense, since at least version 19.x, has defaulted to disabling webGUI access on the WAN interface. Administrative access must be explicitly enabled on a per-interface basis, representing a more cautious default position.
* **Firewall Rule Baseline:**
* Both platforms install a default "anti-lockout rule" to prevent administrators from locking themselves out when modifying firewall rules.
* pfSense includes a default "allow all" rule on the LAN interface, permitting any traffic from the LAN subnet to any destination. This is permissive and assumes the internal network is trusted.
* OPNsense, conversely, has a default "deny all" rule on the LAN interface, with an explicit "allow LAN to any" rule placed above it. This creates a more explicit policy that is easier to modify and audit, as the default deny is always present.
* **Services and Daemons:**
* pfSense historically enabled the unencrypted Telnet daemon for the console menu by default, though this has been changing in recent versions. The SSH server is also typically enabled by default.
* OPNsense disables both SSH and the Serial Console menu by default, requiring manual enablement. Fewer running services inherently reduce the attack surface.
* **Cryptographic and Protocol Defaults:**
* Both have moved towards disabling older, insecure protocols (e.g., SSLv3, TLS 1.0) in their webGUI and associated services over time.
* Analysis of the webGUI's TLS configuration and the defaults for IPsec/IKEv2 or OpenVPN instances shows OPNsense often enforces more modern algorithms and key lengths in its setup wizards, whereas pfSense may offer a wider range of legacy options selected by default for compatibility.
My preliminary conclusion is that OPNsense consistently adopts a more restrictive and "secure-by-default" philosophy across multiple configuration axes. pfSense prioritizes accessibility and backward compatibility, which places the responsibility for hardening on the administrator immediately after installation. This has profound implications for configuration drift, as a forgotten or unmodified default in pfSense is more likely to remain a vulnerability.
I am seeking community input on a few specific points to supplement my audit:
* Has anyone performed or encountered formal audit reports, such as those aligned with ISO 27001 or NIST 800-53, that specifically assess these default states?
* Are there documented instances of vulnerabilities directly attributable to these default configurations (excluding post-installation misconfiguration)?
* How do the auto-update mechanisms compare from a security perspective? For instance, the method of signature verification and the default update channels.
Interesting that you're focusing on the WAN GUI access first. That's the glaring red flag everyone sees, but it's also the one everyone immediately changes. The more subtle defaults are what worry me, the stuff people assume is safe.
For instance, what's the default crypto policy for the IPsec or OpenVPN services if you turn them on? And does either platform default to blocking outbound traffic on LAN, or is it the classic "allow any" that becomes a permanent part of the config? That's the baseline security posture that actually persists in most deployments.
You can measure the audit quality by how many default choices require a user to opt into security, versus having to opt out of convenience.
Data over dogma.
You've nailed the real test: the defaults that stick around after the first five minutes of setup. That LAN outbound rule is a perfect example. It's the "allow any" that becomes the skeleton of the network, and it's almost never revisited.
I ran a quick check on a fresh OPNsense 24.1 install the other day. The default LAN rule is indeed "allow all" for IPv4 and IPv6. The auto-generated rule description even says "Default allow rule," which feels a bit too honest. pfSense is the same story. You have to consciously build a restrictive policy.
And on the VPN crypto point - last I looked, if you just click "enable" on IPsec without touching the phase settings, you're getting SHA1 and 3DES in the mix. It's not *weak* weak, but it's that legacy-compat mindset. The secure defaults (AES-GCM, SHA2) are there, but you have to choose them. Opt-in security, exactly as you said.
Makes you wonder how many "secure" tunnels are running on those 2006-era defaults because someone just clicked through.
That WAN GUI default is the first thing I check, and it honestly colors my perception of a project's security priorities. It's a litmus test.
You're right about the philosophical difference, and I think it extends beyond just administration. OPNsense choosing to disable it sends a message: security first, convenience second. It forces an explicit decision. I'd be curious to see how that philosophy carries over to other service defaults, like DNS resolver or the NTP daemon. Are they bound to all interfaces by default, or just LAN?
It makes me wonder if the target user base influences this more than anything. A more novice user might find the locked-down default frustrating, while a seasoned admin sees it as the correct starting point.