Skip to content

Policy Based Routing (PBR)

Traditional IP routing relies entirely on Destination-Based Routing. When a router or Linux kernel receives a packet, it looks up only the destination IP address in the routing table (RIB) and forwards the packet out the corresponding interface to the next hop.

Policy-Based Routing (PBR) provides a flexible mechanism to override the standard destination-based routing table. Instead of making forwarding decisions based solely on where a packet is going, PBR inspects multiple attributes of the packet before deciding its path.

Key Criteria Used by PBR

  • Source IP Address or Subnet: Route traffic based on who sent the packet.
  • Transport Protocol: Route TCP, UDP, or ICMP traffic differently.
  • Source or Destination Port: Route specific applications (e.g., HTTP on port 80 vs. SSH on port 22) through different paths.
  • Packet Size or TOS/DSCP Markings: Route traffic based on Quality of Service (QoS) tags or packet characteristics.
  • Incoming Interface: Route traffic based on which physical or virtual interface received the frame.

In Linux, PBR is implemented using the iproute2 suite via multiple routing tables and the IP Rule database (ip rule).

What Problem Does It Solve?

Destination-based routing operates under a strict, single-path assumption for any given destination IP. This creates several operational challenges in complex networks:

Asymmetric Routing & Multi-Homing Issues

When a server has multiple network interfaces connected to different ISPs or subnets, standard routing typically sends all outbound traffic through a single default gateway. This causes packets entering via eth1 to exit via eth0, triggering reverse path filtering (rp_filter) drops or firewall connection state resets.

Lack of Application-Aware Traffic Steering

Without PBR, you cannot force high-bandwidth backup traffic over an inexpensive secondary link while keeping sensitive, real-time database traffic on a low-latency primary link if both destination endpoints share the same target network.

Asymmetric Return Path in Direct Server Return (DSR)

In load balancing topologies like DSR, backend servers process incoming requests forwarded by a load balancer but must send responses directly back to the client. PBR ensures responses sourced from the Virtual IP (VIP) bypass the standard local gateway and exit via the correct egress router.

Implement This in Linux

Linux manages PBR using custom routing tables alongside routing policy rules (ip rule).

Scenario

A Linux host has two network interfaces:

  • eth0 (Primary ISP): 192.168.1.10/24, Gateway 192.168.1.1
  • eth1 (Secondary ISP): 10.0.0.10/24, Gateway 10.0.0.1

We want all traffic originating from 10.0.0.10 to always use 10.0.0.1 as its default gateway, overriding the default system routing table.

Create Custom Routing Tables

Linux allows up to 255 routing tables. You can name custom tables in /etc/iproute2/rt_tables:

echo "200 isp2_table" >> /etc/iproute2/rt_tables

Populate the Custom Routing Table

Add a default route and local subnet route to the new isp2_table: 

# Add local subnet route
ip route add 10.0.0.0/24 dev eth1 src 10.0.0.10 table isp2_table

# Add default gateway for ISP2
ip route add default via 10.0.0.1 dev eth1 table isp2_table

Define Policy Rules (ip rule)

Direct traffic sourced from 10.0.0.10 to consult isp2_table instead of the main routing table: 

ip rule add from 10.0.0.10/32 table isp2_table
To route traffic based on port numbers (e.g., force HTTP/80 traffic through isp2_table), use fwmark with iptables or nftables: 
# Mark HTTP traffic using nftables/iptables
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 0x2

# Direct marked packets to the custom routing table
ip rule add fwmark 0x2 table isp2_table

Verify Configuration

ip rule show
Review routes inside the custom table: 
ip route show table isp2_table

Potential Issues

While PBR is extremely powerful, unconsidered implementation can cause hard-to-debug network failures.

  • Reverse Path Filtering (rp_filter) The Linux kernel includes strict Reverse Path Filtering (net.ipv4.conf.all.rp_filter = 1) by default. If a packet arrives on eth1 but the kernel's normal lookup says the return path should be eth0, the kernel drops the packet before PBR rules can evaluate it. Fix: Set rp_filter to loose mode (2) or disable it (0): 
    sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.eth1.rp_filter=2

  • Rule Evaluation Order Rules in ip rule are evaluated sequentially by priority number (lowest number first). If a broad rule matches before your custom rule, the custom rule is ignored. Always inspect priority ordering with ip rule show.

  • Non-Persistent Configurations Commands executed via ip rule or ip route are volatile and lost upon reboot. Ensure rules are persisted using netplan, NetworkManager dispatcher scripts, ifupdown hooks, or systemd services.

  • Increased Troubleshooting Complexity Standard tools like ip route get evaluate the main table by default unless you explicitly pass selector parameters (e.g., ip route get 8.8.8.8 from 10.0.0.10), which can mislead administrators during outage triage.

Usecases and Enterprise scenarios

  1. Multi-Homed Servers (Dual ISP Egress) In multi-homed Linux hosts, PBR guarantees that inbound connections on secondary interfaces receive replies routed back through the same network interface and provider, preventing asymmetric routing drops.

  2. Direct Server Return (DSR) Load Balancing DSR backend nodes process traffic sent to a Virtual IP (VIP) and respond directly to clients. PBR routes all outgoing packets sourced from the VIP to the core internet router rather than sending them back through the load balancer.

  3. Selective VPN / SD-WAN Tunneling Enterprise edge routers and gateways use PBR to direct critical business SaaS applications (e.g., Microsoft 365, Zoom) directly through local internet breakouts while backhauling internal corporate traffic over secure IPsec/GRE tunnels.

  4. Network Security & Inspection Chaining PBR can steer specific subnets or traffic profiles through inline Web Application Firewalls (WAF), Intrusion Prevention Systems (IPS), or DLP appliances before allowing the traffic out to the internet.