Send one subnet out a chosen uplink#

You will end up with chosen traffic — one subnet, one protocol, one destination — always leaving through one uplink, regardless of which uplink the default route currently favours. "The cameras go out through LTE" is this.

Unlike load balancing, this is deterministic: the traffic that matches goes out that way, every time, and nothing spreads it.

How it works#

Three pieces, and the page keeps them in step:

An alternate routing table whose only route is the chosen uplink's gateway.
A policy rule that matches the traffic and sets that table.
A binding of the policy to the interfaces the traffic enters on.

Miss the third and the policy is inert. The Uplinks page flags a policy bound to no interface for exactly that reason.

Before you start#

The operator role and a licence.
Two uplinks, both working.
The traffic you want to pin, described as a source, a destination, a protocol or a port.

Step 1 — Add the policy#

Network → High availability → Uplinks, the policy-routing panel. It keeps one table per uplink and suggests free table and rule numbers.

set protocols static table 10 route 0.0.0.0/0 dhcp-interface eth2
set policy route cameras rule 10 source address 192.0.2.0/24
set policy route cameras rule 10 set table 10
set policy route cameras rule 10 description 'cameras out through LTE'
set policy route cameras interface eth0.20

For a static uplink the table's route names the gateway instead:

set protocols static table 10 route 0.0.0.0/0 next-hop 198.51.100.1

The rule can match on source address, destination address, protocol and destination port — whichever the panel's fields you fill in, each one a line.

Step 2 — Bind it to the interfaces the traffic enters on#

set policy route cameras interface eth0.20

This is the line that makes it do anything. The traffic has to arrive on a bound interface for the policy to be consulted.

Step 3 — Commit with a confirm window#

If the policy matches more than you meant — a source prefix that covers your own workstation, say — the traffic you are using goes out the other uplink, and whether that still reaches you depends on what is at the far end.

Check it worked#

bash

# From a host inside the pinned subnet
curl -s https://ifconfig.co

That should report the chosen uplink's public address, while a host outside the subnet reports the other one.

On the router:

bash

show ip route table 10
ip rule show

The Uplinks tab lists the tables and the policies, and lets you delete either. A policy bound to no interface is flagged as inert.

Things that will bite#

A pinned subnet does not fail over. If the chosen uplink goes down, the alternate table still has its route and the traffic still goes there. That is the point of a deterministic policy, and it is also its cost. If you want fallback, put a second, higher-distance route in the same table pointing at the other uplink.

Return traffic follows the routing table, not the policy. For traffic the router originates or receives, that is usually fine; for a hairpinned service it can be a surprise.

The policy applies before NAT decides. The source NAT rule that matches the outbound interface is what rewrites the address, so a pinned subnet needs the chosen uplink to have its own masquerade rule — Masquerade behind each uplink.

Undoing it#

delete policy route cameras
delete protocols static table 10

The panel's row actions stage each of those separately, so you can remove the binding first and leave the table in place while you test.