Route firewall-originated pfSense services separately from client policy rules

A working client failover rule does not establish the path used by the firewall’s own daemons.

Source facts

Netgate states that traffic initiated by the firewall itself follows its routing table, rather than policy-routing rules on internal interfaces. Services bound to non-default WANs can have additional state-policy considerations. The documentation recommends reviewing default-gateway switching and, where needed, static routes for local services in a Multi-WAN design.

Source: Netgate — Multi-WAN Caveats and Considerations.

Applicability

This concerns pfSense-originated traffic such as DNS or service connections.

DSE recommendation

DSE recommends listing the firewall’s own external dependencies alongside the client traffic matrix. For each service, record the listener or source binding, destination, expected route, and behavior when the preferred circuit fails. Include DNS, monitoring, updates, and VPN initiation where present. Do not assume a successful workstation test proves those local dependencies survived the same event. Keep route exceptions narrowly tied to the actual service requirement. Assign a distinct acceptance result to each firewall-originated dependency. Ask the owner to nominate one request made by the firewall and one made by a workstation, then preserve both outcomes for the same outage interval rather than inferring one from the other.

Verification

During an approved failover rehearsal, test the required service from the firewall context and compare it with a client-generated request. Inspect the routing table and chosen source address. Repeat on restoration and note whether a daemon needs a supported reconnection action before declaring local-service recovery complete.

Official reference

Netgate — Multi-WAN Caveats and Considerations. Reviewed October 20, 2026.