MikroTik Policy-Based Routing: Routing Different Traffic Through Different Gateways
MikroTik policy-based routing (PBR) lets RouterOS send selected traffic through a chosen gateway instead of applying the same default route to every connection. In RouterOS 7, you can implement it with a dedicated routing table plus either /routing rule rules or firewall mangle routing marks. Use routing rules for straightforward source-, destination-, or interface-based policies; use mangle when classification needs address lists, connection state, protocol/port criteria, or more advanced traffic handling.
This guide uses RouterOS 7 syntax. The IP addresses and interface names below are examples: replace them with the addresses and interfaces from your own network. Test changes from a local console or with Safe Mode enabled before applying them remotely.
What policy-based routing does
Normal destination-based routing selects a route mainly from the destination IP address. Policy-based routing adds criteria such as source address, ingress interface, or a firewall routing mark, allowing different traffic to use different routing tables and gateways.
Typical use cases include:
- Sending one department, server, or client through a secondary ISP.
- Routing selected application traffic through a VPN tunnel.
- Keeping guest Wi-Fi on a separate Internet connection.
- Steering traffic to a preferred uplink while leaving other traffic on the primary WAN.
How policy routing works in RouterOS 7
RouterOS 7 policy routing relies on three components:
- Routing tables: Each table can contain a different route to the same destination.
- Routing rules: Rules choose a table based on supported packet attributes, such as source or destination address and incoming interface.
- Firewall mangle: Mangle rules can mark packets for a specific routing table with
action=mark-routing.
For a custom table to forward traffic, it needs a usable route. RouterOS also needs to resolve the next-hop gateway; in common multi-WAN designs, the main table must be able to resolve the gateway used by a custom table. Mangle-based routing marks take precedence over routing rules when the marked table can resolve the packet, so avoid overlapping both mechanisms unless you have designed the interaction deliberately.
Example topology: send one client through WAN2
Assume the router has the following layout:
| Item | Example value | Purpose |
|---|---|---|
| LAN subnet | 192.168.88.0/24 |
Internal clients |
| Selected client | 192.168.88.50 |
Client to steer through WAN2 |
| WAN1 interface | ether1 |
Primary Internet connection |
| WAN2 interface | ether2 |
Secondary Internet connection |
| WAN2 gateway | 198.51.100.1 |
Documentation-only placeholder; replace it |
| Policy routing table | to_wan2 |
Contains the WAN2 default route |
The existing main table is assumed to have a working default route through WAN1. WAN2 must already be configured at Layer 3, and its gateway must be reachable. If your ISP assigns the WAN address and gateway dynamically, adapt the route to your DHCP or PPPoE design rather than copying the placeholder gateway literally.
Method 1: Use routing rules for a simple source-based policy
Routing rules are often the simplest option when the requirement is “traffic from this subnet or client should use this table.” First create a table and add a default route through WAN2:
/routing table
add name=to_wan2 fib
/ip route
add dst-address=0.0.0.0/0 gateway=198.51.100.1@main routing-table=to_wan2The @main suffix asks RouterOS to resolve the gateway using the main table. Replace the example gateway with the actual WAN2 next hop.
Then steer the selected client into that table:
/routing rule
add src-address=192.168.88.50/32 action=lookup-only-in-table table=to_wan2lookup-only-in-table prevents this rule from falling back to the main table if the lookup in to_wan2 fails. That is useful when you want the policy to fail closed, but it means the selected client can lose Internet access if WAN2 becomes unavailable. If fallback through the main table is intended, consider action=lookup instead and test the failover behaviour.
Configure source NAT for WAN2 if the ISP expects traffic to be translated to the WAN address. For a dynamic WAN address, masquerade is commonly appropriate:
/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 out-interface=ether2 action=masqueradeReview existing NAT rules before adding another one. The rule must match the actual WAN2 egress interface, and rule order can affect which NAT rule handles a connection.
Method 2: Use mangle routing marks for more flexible policies
Mangle is a better fit when the policy depends on address lists or more detailed packet classification. The following example routes a selected client through to_wan2 while excluding destinations in an address list of internal networks.
First create the custom table and route if they do not already exist:
/routing table
add name=to_wan2 fib
/ip route
add dst-address=0.0.0.0/0 gateway=198.51.100.1@main routing-table=to_wan2Define the internal destinations that must not be steered out to the Internet. Include every relevant internal, management, VPN, and site-to-site subnet in your environment:
/ip firewall address-list
add list=internal-nets address=192.168.88.0/24
add list=internal-nets address=10.0.0.0/8
add list=internal-nets address=172.16.0.0/12
add list=internal-nets address=192.168.0.0/16Now mark eligible forwarded traffic from the selected client:
/ip firewall mangle
add chain=prerouting src-address=192.168.88.50/32 dst-address-list=!internal-nets action=mark-routing new-routing-mark=to_wan2 passthrough=noThe rule runs in prerouting, where packets arriving from LAN clients can be classified before the route lookup. The exclusion helps prevent private-network traffic from being sent toward an Internet gateway. Adapt the address list to your actual topology; the example private ranges are broad and may overlap with networks you intentionally route elsewhere.
Apply or verify a source NAT rule for the secondary WAN, as shown in Method 1. A routing mark selects a route; it does not automatically translate source addresses or configure the WAN interface.
Route only a specific destination or application
To route only a particular destination, a routing rule can match the destination address:
/routing rule
add dst-address=203.0.113.25/32 action=lookup-only-in-table table=to_wan2203.0.113.25 is also a documentation-only address. Replace it with the real destination. For application-specific policies, mangle can match protocol and port, but ports alone do not always identify an application reliably: services can use multiple ports, encrypted traffic hides application details, and many services use shared infrastructure. If you mark connections first, ensure the subsequent routing-mark logic covers both directions as required by your design.
Important operational details
FastTrack can bypass policy-routing processing
RouterOS FastTrack is designed around the main routing table. Traffic that must use a non-main table should not be FastTracked by a rule that assumes main-table routing. Review /ip firewall filter for FastTrack rules and exclude policy-routed connections or otherwise redesign the filter rules carefully. Do not simply disable firewall protections without understanding the impact.
Router-originated traffic is different
The examples above target traffic forwarded from a LAN client. Traffic generated by the router itself, such as DNS queries, NTP, monitoring probes, or VPN endpoint traffic, follows a different packet path. A prerouting rule does not classify locally generated packets; use an appropriate output-chain policy or routing rule when router-originated traffic must use a particular WAN.
Connection tracking and NAT matter
Routing changes do not necessarily move established connections cleanly between ISPs. NAT mappings and connection-tracking state are tied to existing flows, and a session established through WAN1 may fail if later packets leave through WAN2. Test with new connections after a policy change, and plan how failover should behave for long-lived sessions.
IPv4 and IPv6 need separate consideration
The examples use IPv4 commands under /ip. IPv6 policy routing requires its own IPv6 routing and firewall configuration; an IPv4 mangle or NAT rule does not automatically apply to IPv6. Do not assume IPv4 masquerade is a suitable IPv6 design.
How to verify the policy
- Confirm the custom table exists with
/routing/table/print. - Inspect routes and verify the WAN2 default route is active:
/ip/route/print detail where routing-table=to_wan2. - Inspect routing rules with
/routing/rule/print, or mangle counters with/ip/firewall/mangle/print stats. - From the selected client, open a new connection to an external IP address and check the public egress address using a trusted IP-check service.
- Use
/tool traceroutefrom the router only with care: router-originated probes may follow a different policy from forwarded client traffic. - Test access to internal subnets, DNS resolution, inbound services, VPNs, and the expected behaviour when WAN2 fails.
If the rule counter does not increase, verify the source address, ingress path, rule order, and whether the traffic is actually routed rather than switched at Layer 2. If the counter increases but the client has no connectivity, inspect the custom-table route, gateway reachability, NAT rule, firewall forward policy, and FastTrack interaction.
Common mistakes
- Creating a table without a usable route: Add the intended route and verify it is active.
- Using the wrong gateway or interface: Replace example values and confirm the WAN gateway is reachable.
- Forgetting source NAT: Some providers will not route private LAN source addresses back to the router.
- Sending internal traffic to the Internet: Exclude internal destinations where required and include all routed private or VPN subnets.
- Mixing routing rules and mangle without a plan: Mangle-marked traffic can be resolved before user routing rules are considered.
- Ignoring FastTrack: FastTracked flows may not follow the expected non-main routing behaviour.
- Assuming failover preserves sessions: Changing the egress path can break established NATed connections even when new connections work.
Routing rules vs. mangle: which should you use?
| Requirement | Recommended starting point | Trade-off |
|---|---|---|
| Route a source subnet or destination through another gateway | Routing rules | Simple to read and maintain |
| Classify traffic with address lists or detailed packet criteria | Mangle routing marks | More flexible, but rule order and FastTrack need attention |
| Per-connection load distribution across WANs | A purpose-built PCC/multi-WAN design | Requires connection marking, symmetric handling, NAT, and failure testing |
| Separate routing domains with independent routing tables and interfaces | Consider VRFs | More isolation and more configuration complexity |
Related Layer-x guides: MikroTik load balancing with PCC for per-connection multi-WAN distribution, MikroTik WAN failover for backup-link design, and MikroTik RouterOS 7 NAT configuration for source translation details.
Conclusion
MikroTik policy-based routing lets you choose a gateway according to the traffic rather than relying only on the main default route. For simple source- or destination-based requirements, start with RouterOS 7 routing rules. Use mangle routing marks when the policy needs richer classification. In either case, validate the custom table and gateway resolution, handle NAT deliberately, account for FastTrack, and test both normal operation and WAN failure before relying on the configuration.
Frequently asked questions
What is policy-based routing on MikroTik?
Policy-based routing selects a routing table or gateway using criteria beyond the destination alone, such as source address, incoming interface, or a firewall routing mark. It is commonly used for multi-WAN and VPN traffic steering.
Should I use routing rules or mangle in RouterOS 7?
Use routing rules for straightforward source-, destination-, or interface-based decisions. Use mangle when you need more detailed traffic classification or marking. Avoid overlapping both methods unless you understand the routing decision order.
Does policy routing require NAT?
No. Policy routing chooses the path; NAT is a separate function. Add source NAT only when required by the addressing and return-routing design, which is common when private LAN clients access the Internet through an ISP gateway.
Why does policy-routed traffic stop working when FastTrack is enabled?
FastTrack is intended for traffic using the main routing table and can bypass processing expected by a non-main routing policy. Review the FastTrack filter rule and ensure policy-routed connections are handled by rules compatible with your design.
Can MikroTik route some traffic through a VPN and other traffic through an ISP?
Yes. Create a routing table with a route through the VPN, then select which traffic uses that table with routing rules or mangle marks. Make sure the VPN route, allowed destinations, DNS behaviour, NAT, and failure policy all match your intended security requirements.
References
- MikroTik RouterOS Manual: Routing and Networking Protocols
- MikroTik Documentation: Policy Routing
- MikroTik Documentation: Mangle
- MikroTik Documentation: Packet Flow in RouterOS
- MikroTik Documentation: NAT
Check our list of MikroTik guides
