pfSense Policy Routing - Rule-Based Traffic Steering

Policy-based routing (PBR) in pfSense directs traffic through a specific gateway based on criteria beyond the destination address. Unlike conventional routing, where a packet’s path is determined solely by the routing table and destination address, PBR considers the source address, destination port, protocol, and other parameters defined in firewall rules.

pfSense implements PBR through the Gateway field in firewall rules. Any rule with an explicitly assigned gateway overrides the standard routing table for matched traffic. This provides granular control over packet paths without modifying the global route configuration.

How It Works

When a packet arrives, pfSense processes firewall rules on the ingress interface in top-down order. If the packet matches a rule with a specific gateway, pfSense routes the packet through that gateway, bypassing the standard routing table. If no gateway is specified (the Default value in the Gateway field), the packet follows normal routing.

Processing order:

1. A packet arrives on a pfSense interface.
2. NAT translation is applied (if applicable).
3. The packet is matched against firewall rules from top to bottom.
4. If the matching rule contains an explicit gateway, the packet is forwarded through that gateway.
5. If the matching rule has no explicit gateway or no rule matches, the standard routing table is used.

Warning:

Policy routing applies only to traffic passing through pfSense (forwarded traffic). Traffic generated by pfSense itself (DNS queries, package updates, NTP synchronization) always uses the standard routing table and the default gateway. To control the firewall’s own outbound traffic, change the default gateway under System > Routing > Gateways.

The Gateway Field in Firewall Rules

The Gateway field is located in the advanced settings of a firewall rule (the Advanced Options section when creating or editing a rule). It defaults to Default, which means the standard routing table is used.

Available options:

When a specific gateway or Gateway Group is selected, pfSense creates a pf (packet filter) rule with a route-to directive that forces the packet through the designated interface and gateway.

Use Cases

Routing Specific Hosts Through a Designated WAN

Objective: route all accounting department traffic (subnet 10.0.1.0/24) through WAN1, and developer traffic (subnet 10.0.2.0/24) through WAN2.

This configuration requires two WAN interfaces with configured gateways (WAN1_GW and WAN2_GW).

Rule 1 (on the LAN interface):

Rule 2 (on the LAN interface):

Rule order matters: rules with an explicit gateway must be placed above the general pass-any rule. Otherwise, traffic matches the general rule and follows the default gateway.

Steering VoIP Over a Low-Latency Link

Objective: route SIP and RTP traffic through a low-latency WAN link (WAN2) while all other traffic uses the primary link (WAN1).

SIP rule (on the LAN interface):

RTP rule (on the LAN interface):

For easier administration, create an alias named VoIP_Phones containing the IP addresses or subnet of VoIP equipment.

Forcing Guest Network Traffic Through a Dedicated ISP

Objective: route all guest network traffic (interface OPT1, subnet 10.0.100.0/24) through a separate ISP (WAN2), isolating it from the primary link.

Rule (on the OPT1 interface):

Additionally, create rules that block guest network access to internal subnets (LAN, server VLANs).

Routing by Protocol and Destination Port

Objective: route all HTTPS traffic (port 443) through an unlimited-bandwidth WAN link while other traffic uses the primary metered link.

HTTPS rule (on the LAN interface):

Creating a Policy Route Step by Step

A step-by-step procedure for creating a policy route that directs traffic from a specific subnet through a designated gateway.

Step 1: Verify Gateways

Open System > Routing > Gateways and confirm that the target gateway exists and has an Online status. If the gateway is missing, create it by specifying the interface, IP address, and monitoring parameters.

Step 2: Create Aliases (If Needed)

If the policy route targets a group of hosts or ports, create aliases in advance under Firewall > Aliases. Aliases simplify management and improve rule readability.

Example host alias:

Step 3: Create the Firewall Rule

Open Firewall > Rules on the interface where the source traffic arrives. Click Add (up arrow to add at the top of the list).

Configure the core rule parameters:

1. Action: Pass
2. Interface: the source traffic interface
3. Address Family: IPv4 (or IPv4+IPv6 if needed)
4. Protocol: Any (or a specific protocol)
5. Source: source address or alias
6. Destination: Any (or a specific network)

Step 4: Set the Gateway

In the Advanced Options section (click Display Advanced), locate the Gateway field. Select the target gateway or Gateway Group from the dropdown.

Step 5: Position the Rule

Move the rule above the general pass-any rule. Firewall rules are processed top to bottom, and the first match determines packet handling. If the general rule is positioned above the policy route, traffic matches the general rule and follows the default gateway.

Step 6: Apply and Verify

Click Save, then Apply Changes. To verify, run a traceroute from the source host to an external address and confirm that traffic passes through the expected gateway.

Interaction with Gateway Groups

Gateway Groups add an additional layer of flexibility to policy routing. Instead of specifying a single gateway in a firewall rule, a group can be selected to provide failover or load balancing.

Creating a Gateway Group

Gateway Groups are configured under System > Routing > Gateway Groups. Click Add to create a group.

Group Name - a unique group identifier. This name appears in the Gateway field of firewall rules.

Gateway Priority - for each gateway, specify a priority (Tier 1-5) and a failover trigger:

Trigger Level - the event that triggers failover:

Scenario: Failover

Creating a group for automatic failover to a backup link:

During normal operation, all traffic flows through WAN1. When WAN1 experiences packet loss or excessive latency, traffic automatically switches to WAN2.

Scenario: Load Balancing

Creating a group to distribute traffic across two links:

Both gateways are in Tier 1 and used simultaneously. Weight determines the distribution ratio: WAN1 receives approximately 62% of traffic (5/8), WAN2 receives 38% (3/8). If one gateway fails, all traffic is directed through the remaining gateway.

Scenario: Failover with Load Balancing

A combination of both approaches: two primary links with load balancing and a backup link:

During normal operation, traffic is distributed between WAN1 and WAN2. If both Tier 1 links fail, traffic falls over to WAN3.

Using a Gateway Group in a Firewall Rule

After creating a Gateway Group, it becomes available in the Gateway field of firewall rules alongside individual gateways. Selecting a group instead of a specific gateway provides automatic failover without manual intervention.

Considerations and Limitations

Interaction with NAT

Policy routing is applied after inbound NAT (DNAT) but before outbound NAT (SNAT). This means:

• For inbound traffic (port forwards, 1:1 NAT), policy routing operates on the already-translated destination address.
• For outbound traffic, policy routing determines the egress interface, which affects outbound NAT source address selection.

When using PBR with multiple WAN interfaces, verify that outbound NAT rules are correctly configured for each WAN. In Automatic Outbound NAT mode, pfSense generates rules automatically for all WAN interfaces. In Manual Outbound NAT mode, rules must be created manually for each interface.

Traffic Generated by pfSense

Policy routing does not affect traffic generated by the firewall itself. DNS queries, package updates, NTP synchronization, and other pfSense-originated connections always use the default gateway. To change the outbound path for system traffic, modify the default gateway under System > Routing > Gateways.

Floating Rules and Policy Routing

Floating rules in pfSense also support the Gateway field. Floating rules are processed before interface-specific rules, allowing the creation of global routing policies that apply across multiple interfaces simultaneously.

To enable policy routing in a floating rule, set the Direction to In or Any. When Direction is set to Out, the Gateway field is ignored.

Sticky Connections

When using Gateway Groups for load balancing, pfSense may by default distribute packets from a single connection across different gateways, which breaks certain protocols and web services.

To address this, enable the Sticky Connections option under System > Advanced > Miscellaneous. This setting binds all connections from a given source to a single gateway for a defined period.

Troubleshooting

Policy Route Not Applied

If traffic uses the default gateway instead of the one specified in the rule:

1. Check rule order. The policy route rule must be positioned above the general pass rule. Open Firewall > Rules on the relevant interface and verify the order.

2. Verify rule matching. Open Status > System Logs > Firewall and confirm that the traffic matches the policy route rule rather than another rule.

3. Check gateway status. If the specified gateway is unreachable (Down status), pfSense may route traffic through the default gateway. Verify the status under Status > Gateways.

4. Check existing states. If a connection was established before the policy route was created, it continues using the previous path. To force the new rule, reset the state table: Diagnostics > States > Reset States. Note that resetting states terminates all active connections.

5. Confirm the correct interface. Policy routing is applied on the ingress interface. A rule for LAN traffic must be on the LAN tab, not on WAN or Floating.

Asymmetric Routing Warnings

When using policy routing with multiple WAN interfaces, there is a risk of asymmetric routing on return traffic. A request leaves through WAN2, but the response may arrive through WAN1 if the remote router selects its route independently.

To prevent this:

• Configure reply-to rules (pfSense adds these automatically when policy routing is in use), which ensure return traffic uses the same interface.
• Verify that the Disable reply-to option is not enabled on WAN interface firewall rules.
• If necessary, enable Bypass firewall rules for traffic on the same interface under System > Advanced > Firewall & NAT.

Traffic Not Leaving Through the Expected Interface

To verify the actual path, capture packets on the WAN interface:

1. Open Diagnostics > Packet Capture.
2. Select the WAN interface where traffic is expected.
3. Set a filter for the source or destination IP address.
4. Initiate traffic from the source host.
5. Check whether packets appear on the expected interface.

If packets appear on a different WAN interface, the issue lies in rule order or existing states.

Sticky Connections Issues

If session disruptions occur when using Gateway Groups with load balancing:

1. Verify that Sticky Connections is enabled under System > Advanced > Miscellaneous.
2. Check the Source Tracking Timeout value - the default is 0 (binding lasts for the state lifetime). Increase the value if needed.
3. For services that cannot tolerate source IP changes (banking systems, corporate VPNs), create a dedicated rule with a specific gateway instead of a Gateway Group.

Migration from Other Platforms

Cisco IOS PBR

In Cisco IOS, policy-based routing is configured using route-maps and ip policy:

access-list 110 permit ip 10.0.1.0 0.0.0.255 any

route-map PBR_ACCOUNTING permit 10
  match ip address 110
  set ip next-hop 203.0.113.1

interface GigabitEthernet0/1
  ip policy route-map PBR_ACCOUNTING

Equivalent in pfSense:

1. Create a gateway with address 203.0.113.1 under System > Routing > Gateways.
2. Create a firewall rule on the LAN interface:
   • Source: 10.0.1.0/24
   • Destination: Any
   • Gateway: the created gateway

Key differences:

FortiGate Policy Routes

In FortiGate, policy routes are configured separately from firewall policies:

config router policy
    edit 1
        set input-device "port2"
        set src "10.0.1.0/255.255.255.0"
        set dst "0.0.0.0/0.0.0.0"
        set gateway 203.0.113.1
        set output-device "port1"
    next
end

Key differences:

MikroTik Routing Marks

In MikroTik, PBR is implemented through routing marks in mangle and routing tables:

/ip firewall mangle add chain=prerouting src-address=10.0.1.0/24 \
    action=mark-routing new-routing-mark=via_ISP2

/ip route add dst-address=0.0.0.0/0 gateway=203.0.113.1 \
    routing-mark=via_ISP2

Key differences:

Design Recommendations

When designing policy routing in pfSense, consider the following principles:

• Minimize the number of policy routes. Each rule with an explicit gateway adds diagnostic complexity. Group hosts via aliases and create generalized rules instead of per-host entries.

• Use Gateway Groups instead of individual gateways. Even with a single WAN link, consider creating a Gateway Group with one member. This simplifies adding a backup link later without modifying firewall rules.

• Document routing logic. The Description field in firewall rules should clearly state which traffic is routed and through which link. With many policy routes, use rule separators on the rules tab to visually delineate blocks.

• Test after every change. After adding or modifying a policy route, run a traceroute from the source host and verify that traffic passes through the expected gateway. Also test services sensitive to source IP changes.

• Plan for failure handling. When a specific gateway (not a Gateway Group) is specified, gateway failure may cause total connectivity loss for affected hosts. Always use Gateway Groups with a backup gateway.

• Account for outbound NAT implications. When using multiple WAN interfaces, verify outbound NAT rules for each interface. In Automatic Outbound NAT mode, pfSense creates rules automatically, but Manual mode requires per-interface configuration.

Related Sections

• Static Routes - gateway and static route configuration, viewing the routing table
• pfSense Multi-WAN - multiple WAN connections, closely tied to policy routing
• Firewall Rules - rule creation and management, where policy routing is configured