Linux policy routing is a routing method that selects routes using rules in addition to the main destination table. It lets the kernel choose different next hops based on marks, source addresses, interfaces, or other selectors, which is commonly used for multi-homing, traffic segregation, and advanced packet handling.
What Linux policy routing changes in the routing process
Linux policy routing adds a second decision layer on top of the normal destination-based routing table. Instead of sending every packet through one default path, the kernel can consult rules that match packet marks, source addresses, interfaces, or similar selectors and then choose a different next hop or table.
This matters because it changes routing from a single global lookup into a rules-driven decision process. That lets one host enforce different egress paths for different workloads, networks, or administrative domains without rewriting the basic routing model.
Why policy routing is used
Policy routing is most often used when one route table is not enough. Common cases include multi-homed servers, traffic segregation between internal and external networks, source-specific routing, and environments where different classes of traffic must leave through different gateways.
It is also a control point for routing consistency. If a packet is marked for a specific path, the rule set can keep that packet on the intended route even when the main table would otherwise choose a different next hop. That makes policy routing useful for engineering intentional network behaviour rather than relying only on longest-prefix matching.
How Linux evaluates rules and tables
Linux policy routing is usually built from rules and tables. A rule defines the selector, for example source prefix, fwmark, interface, or priority, while the table contains the candidate routes. The kernel evaluates rules in order and stops when it finds a matching route in the referenced table.
This ordering is important because the first matching rule can override later ones. Misordered rules, overlapping selectors, or incomplete tables can produce asymmetric routing, unexpected egress paths, or blackholes that are hard to diagnose from the destination table alone.
Operational consequences and troubleshooting clues
Policy routing changes the troubleshooting model as well as the behaviour. A packet may be routed correctly by the main table but still fail because a higher-priority rule sends it elsewhere, or because the chosen table lacks a usable route or return path.
- Check the rule order before inspecting the route itself.
- Verify that the selected table contains both forward and return-path routes where symmetry matters.
- Confirm that packet marks, source addresses, and interface bindings are actually present on the traffic you expect to match.
When policy routing fails, the symptoms often look like intermittent connectivity, one-way reachability, or traffic escaping the intended network segment. The root cause is usually a mismatch between the packet selectors and the routing table that the rule points to.
Risk and Threat Considerations
Policy routing can create security exposure when traffic steering is used to bypass intended segmentation, monitoring, or egress controls. If rule precedence, packet marking, or source-based selectors are mismanaged, traffic may exit through an unexpected interface or avoid the defensive path an organisation assumed was in use.
Failure mechanism: An attacker or misconfiguration can exploit rule order, route-table gaps, or untrusted packet marks to push traffic onto a weaker path, hide lateral movement, or break expected return routing and inspection.
Impact: The result can be loss of network control, weakened segmentation, incomplete logging or filtering, and harder incident investigation because the actual packet path no longer matches the intended policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PS-05 — Resilience of Assets | Policy routing affects path selection and network reachability resilience. |
| Recommendation — Validate route-policy failover so critical traffic still reaches approved paths. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Policy routing changes how traffic crosses network boundaries and segmentation points. |
| AC-4 — Information Flow Enforcement | Routing rules can enforce or undermine allowed information flows between interfaces and networks. | |
| CM-2 — Baseline Configuration | Rule and table state form part of the system configuration baseline for host networking. | |
| Recommendation — Enforce SC-7 to ensure routed traffic crosses only approved network boundaries. Apply AC-4 to constrain packet flows to the routes your policy authorises. Baseline route rules and tables so drift is detectable before connectivity fails. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Linux policy routing is a network infrastructure control that must be inventoried and governed. |
| Recommendation — Manage routing policy changes under CIS-12 so approved paths remain documented and controlled. | ||
Practitioner Guidance
What to watch for: Treat policy routing as a governed control, not just a convenience feature. The most common operational mistake is assuming the main routing table tells the whole story when the active rule set may be selecting a different path entirely.
Practitioner takeaway: Document which selectors are authoritative, keep rule precedence intentional, and validate routing from the packet's point of view, not just from the destination prefix alone.
Related resources from NHI Mgmt Group
- Who should own routing and retention policy when telemetry spans security and IT?
- Who is accountable when routing policy or telemetry retention fails?
- What breaks when teams rely on routing instead of policy enforcement for AI tool access?
- What breaks when model routing is not governed with policy and observability?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org