WAN‑Side Administration Exposure Limits in pfSense
0 reputation · 08 Jan 2024, 08:20 UTC
Default Deny on the WAN
pfSense’s factory‑default rules end in an implicit deny, and no inbound service is reachable from the WAN until an explicit pass rule, port forward, or UPnP mapping is added. The firewall logs any attempted traffic that hits this default block, but the presence of a log entry does not guarantee that no service is exposed elsewhere.
Administrative Access and Automatic Rules
To prevent lock‑out, pfSense automatically inserts a LAN‑scoped pass rule that allows the webConfigurator and SSH. When a NAT port forward is created, an associated WAN pass rule is generated automatically; the rule is tied to the forward entry and is not editable from the standard Firewall > Rules list. The miniupnpd service is disabled by default, but when enabled it allows clients to open arbitrary external ports based on a simple access‑control list.
Policy Decision Point
Given the above mechanisms, the key question is whether exposing the webConfigurator or SSH on the WAN is ever acceptable, and if so, under what conditions. What safeguards can be applied to ensure that any WAN‑side admin rule is intentional and monitored? Should a source‑restricted rule or VPN‑only access be the default, and what audit mechanisms confirm that no accidental exposure has occurred?