GUI exposure and source restrictions

The web GUI is the part of OPNsense that holds the keys to every firewall rule, every NAT entry, every user account, every VPN tunnel, and every certificate on the firewall. It is the most sensitive service the appliance runs. Yet the default install binds it to every interface on the firewall — including the WAN. That default is a production anti-pattern. Every week, Internet facing scans find tens of thousands of OPNsense, pfSense and similar appliances that have been left reachable on port 443.

This lesson covers why GUI exposure to the Internet is dangerous, how to bind the GUI to a trusted management network, the firewall rules that enforce the boundary, and the operational signals that tell you an exposed GUI is being touched.

Why exposing the GUI is dangerous

OPNsense ships a hardened PHP application, but it is still a web application listening on a port with full administrative authority. Exposing it on the WAN creates three categories of risk:

1. Authentication attacks. The login form accepts credentials. Password reuse, weak passwords, and credential stuffing attacks turn an exposed GUI into a takeover path. Even with the built-in SSH lockout, a slow-and-low brute force spread across many source IPs can succeed without tripping per-source counters.
2. Application vulnerabilities. Every web application has bugs. OPNsense ships security patches in its release branch, but between a vulnerability becoming public and an operator applying the patch, an exposed GUI is a known target. This is the same threat model that makes any Internet-facing web app risky — the difference is that the payload is the entire firewall.
3. Configuration leakage. The login page itself reveals the product name and version. That alone tells an attacker which CVEs to try. Combined with banner disclosure (login screen text, error messages), the GUI is reconnaissance gold for an attacker planning a deeper attack.

The fix is not “use a strong password” or “enable MFA and call it done”. The fix is “do not let the Internet reach the GUI in the first place”. Defence in depth says: bind to a management network, restrict by source, require a VPN to reach the management network from outside, and require key-based or MFA authentication when the GUI is reachable.

Listen interfaces: where the GUI binds

OPNsense binds the GUI to the interfaces you select under System → Settings → Administration. The default is “All interfaces”, which includes the WAN. The correct setting for production is to pick one or more specific interfaces — typically the LAN and a dedicated management VLAN, and never the WAN.

When the GUI is bound to specific interfaces, the web server (nginx with PHP-FPM under FreeBSD) only accepts connections on those interfaces. A connection attempt to the WAN IP on port 443 is refused by the kernel before it reaches the application.

$ sockstat -l -P tcp | grep -E ':(80|443) '

root     nginx      1234  7  tcp4   192.0.2.1:443      *:*
root     nginx      1234  8  tcp4   10.10.10.1:443     *:*
root     nginx      1234  9  tcp6   2001:db8::1:443     *:*

The verification step is the production discipline: after every change to System → Settings → Administration, run sockstat -l and confirm the GUI binds only on the expected interfaces. If the WAN IP is in the listening list and the firewall is in production, treat that as a P0 incident and remediate immediately.

Firewall rules for management access

Even with the GUI bound to specific interfaces, the firewall rule on the WAN should explicitly block access to the GUI port. This is the second layer of the defence and it catches the case where the GUI binding is misconfigured or changed in haste.

The minimum WAN rule set for a production firewall:

If you need a single rule that says “block GUI access from the WAN”, the rule is:

• Action: block
• Interface: WAN
• Direction: in
• Source: any
• Destination: WAN address
• Destination port: 443 (and 80 if HTTP is enabled)

The verification sequence after configuring management access:

1. Confirm GUI bind via sockstat -l on the firewall console.
2. Confirm PF rule via pfctl -s rules | grep -E ':443|:80'.
3. Attempt GUI access from the management VLAN — should succeed.
4. Attempt GUI access from the WAN — connection should be refused at TCP level (RST) if the bind is correct, or timed out if the PF rule is the only protection.

Source restrictions

Source restrictions are the third layer. Even within the management VLAN, source restrictions limit which IPs can reach the GUI. The pattern is to create an alias of the management hosts (operator workstations, jump hosts) and use that alias as the source on the management-to-firewall rule.

The implementation:

• Create an alias management_hosts with the IPs of the operator workstations and jump hosts.
• Add a rule on the management VLAN interface: allow management_hosts to the firewall IP, ports 80/443.
• Add a rule below it: block any to the firewall IP on 80/443 from the rest of the management VLAN.

This means a compromised host on the management VLAN cannot reach the GUI — only the specific operator workstations can.

Operational signals of exposure

Three signals tell you the GUI is exposed when it should not be:

1. Listening sockets include the WAN IP. Run sockstat -l on the console or via SSH. If the WAN IP appears in the list of addresses bound to ports 80/443, the GUI is exposed.
2. PF state table shows inbound 443 to the WAN IP. A connection from the Internet to the WAN IP on 443 that appears in pfctl -s state is an active probe or attack. Even if the application-level rule (sockstat bind) refuses the connection, the state entry tells you the packet reached the firewall.
3. Authentication log shows attempts from non-management sources. Under System → Access → Logs, repeated login failures from source IPs outside the management network are the smoking gun. The built-in SSH lockout will eventually block the source, but slow-and-low attacks spread across many IPs may not trip the threshold.

The response to any of these signals is the same: review the listen interfaces, the WAN rules, and the source restrictions. Treat the firewall as compromised if a successful login from a non-management source appears in the log.

Production patterns

Three patterns cover the common cases.

Single-site, management on the LAN

Bind the GUI to the LAN only. Add an alias management_hosts with operator workstations. Add a rule allowing management_hosts to the LAN IP on 443. Add a default block on the LAN for the firewall IP on 443.

Single-site, dedicated management VLAN

Bind the GUI to the management VLAN. Add a rule on the management VLAN allowing the management_hosts alias to the firewall IP on 443. Add a default block on every other interface for the firewall IP on 80/443. Do not rely on binding alone — add the PF rules too.

Multi-site, management over VPN

Bind the GUI to a management VLAN on each site. Add a site-to-site VPN between management VLANs. Restrict GUI access by source to the management VLAN at each site. Operators connect to the VPN first, then to the GUI.

Summary

• Bind the GUI to specific interfaces. Never to all interfaces.
• The WAN should never have a route to the GUI. Block port 443 to the WAN IP in PF, even if the bind excludes the WAN.
• Source restrictions limit GUI access within the management network. Use an alias of operator hosts.
• The anti-lockout rule covers the LAN. Add explicit rules for every management VLAN.
• Verify with sockstat -l and pfctl -s rules after every configuration change.