# 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.

- Canonical URL: https://update.dsesecurity.com/updates/route-firewall-originated-pfsense-services-separately-from-client-policy-rules/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:16:03+00:00
- Modified: 2026-10-20T18:34:34+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://docs.netgate.com/pfsense/en/latest/multiwan/considerations.html).

## 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](https://docs.netgate.com/pfsense/en/latest/multiwan/considerations.html). Reviewed October 20, 2026.

## Primary reference

- Name: Netgate — Multi-WAN Caveats and Considerations
- Authority: docs.netgate.com
- URL: https://docs.netgate.com/pfsense/en/latest/multiwan/considerations.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Route firewall-originated pfSense services separately from client policy rules,” DSE Security, https://update.dsesecurity.com/updates/route-firewall-originated-pfsense-services-separately-from-client-policy-rules/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.