Policy-Based Routing: Send VLANs Out a Chosen WAN

Policy-based routing lets you write a firewall rule that says “traffic from this VLAN leaves through this specific WAN,” overriding the normal routing decision. On a multi-WAN home network it is how you pin your work VLAN to the reliable fiber while letting guests and IoT spill onto the cellular backup during the handful of real outages a year — sending different trust zones out different internet lines on purpose, by rule.

This is where multi-WAN stops being just a backup and becomes a tool. In my setup the hydro lab, the kids’ consoles, the work segment, and the IoT VLAN are already four separate trust zones on one router; policy routing lets each one use the internet line that fits it. The work VLAN gets the low-latency fiber. The metered cellular line is reserved for the traffic that actually needs to stay up during an outage — not the NAS backup that would torch my data cap. Same segmentation instinct as the rest of the network, applied to which pipe each hobby’s traffic uses.

You will want the failover mechanism working first. The OPNsense failover setup builds the gateways and the gateway group this relies on, and the multi-WAN overview shows where policy routing sits in the bigger design. Here we go deep on the rules themselves.

What Is Policy-Based Routing?

Policy-based routing is choosing a packet’s exit path based on a policy you define — usually its source, like which VLAN it came from — instead of the router’s default “send everything out the main gateway” behavior. In practice on OPNsense and pfSense, it is an ordinary firewall rule with one extra setting: the Gateway field, set to a specific WAN or gateway group instead of default.

That one field is the whole feature. A normal allow rule lets traffic pass and uses the system’s default route. The same rule with its gateway set to WAN2 forces every packet it matches out WAN2, regardless of what the routing table would otherwise pick. Because it lives in the firewall ruleset, you get the full matching vocabulary — source VLAN, destination, port, protocol — to decide exactly what gets redirected. You could send only one VLAN’s traffic out a chosen line, or only that VLAN’s traffic to specific destinations, and leave everything else on the default path. It is precise, and precision is the point.

Why Would You Send a VLAN Out a Specific WAN?

Three reasons dominate at home: protecting a metered backup line, giving latency-sensitive traffic the better connection, and isolating untrusted devices onto a separate exit. Each maps a class of traffic to the line that suits it, so your two WANs stop being interchangeable and start doing specific jobs.

The metered-backup case is the one that saves money. When failover kicks in, you do not want every VLAN pouring onto cellular at once — especially not a bandwidth-hungry backup job over LTE. A policy rule that keeps heavy, non-urgent VLANs on the primary only means they simply wait for fiber to return instead of eating your data cap. The latency case matters for real-time traffic — a video call or a game feels the difference between a clean fiber and a jittery backup, so you pin it to the good line. And the isolation case extends the segmentation philosophy from the home VLAN guide: if you already keep untrusted IoT gear on its own VLAN with no lateral access, sending its internet traffic out a separate exit is the same instinct one layer up. Different zones, different rules, different pipes.

How Do You Write a Policy Route in OPNsense?

Create a firewall rule on the VLAN interface you want to steer, set it to pass the traffic, then expand the Advanced options and set the Gateway field to the WAN or gateway group you want that traffic to use. Save, apply, and every packet matching that rule now exits through your chosen line. That is the entire mechanism — one rule, one gateway setting.

The details that matter: place the rule on the source VLAN’s interface tab, not on WAN, because you are matching traffic as it enters from that segment. Set the source to that VLAN’s subnet (or “this interface net”) and leave the destination as “any” if you want everything from that VLAN redirected, or narrow it to specific destinations for finer control. The Gateway field is the one doing the work — pick a single WAN gateway to pin traffic hard to one line, or pick a gateway group to pin it to a preferred line that still fails over. The official OPNsense firewall documentation details every field on the rule form. One caution I will expand on below: pinning to a single gateway behaves very differently from pinning to a group when that line goes down.

Why Does Rule Order Decide Everything?

Firewall rules are evaluated top to bottom and the first match wins. So a policy route only works if it sits above any broader rule that would otherwise catch the same traffic first. Put your specific “send this VLAN out WAN2” rule below a general “allow all from this VLAN” rule, and the general one matches first, the packet takes the default gateway, and your carefully written policy route never runs.

This is the single most common way policy routing silently fails. The rule is correct, the gateway is set, everything looks right — but it is in the wrong position, so it is dead code. I order mine deliberately: the narrow, gateway-specific rules go up top, and the broad catch-all allow rules go at the bottom, exactly as the VLAN firewall rules guide lays out. When a policy route “isn’t working,” the first thing I check is not the gateway setting — it is whether some broader rule above it is grabbing the traffic first. Reorder it above the catch-all and it springs to life. Top-down, first match wins: tattoo it on the inside of your eyelids before you build multi-WAN rules.

What Happens When a Policy Route Points at a Dead WAN?

By default, a rule pinned to a single gateway keeps forcing traffic out that gateway even after the line dies — so that VLAN goes dark instead of failing over. The fix is either to point the rule at a gateway group instead of a single WAN, or to enable OPNsense’s “Skip rules when gateway is down” setting, which drops the policy rule while its gateway is offline so traffic falls through to the next matching rule.

This bit me and it is worth learning from my mistake. I had pinned a VLAN hard to my primary WAN with a single-gateway policy rule, feeling clever. Then the primary went down for real — and while the rest of the house happily failed over to cellular, that one VLAN sat there stubbornly trying to route out the dead fiber, because its rule was nailed to that specific gateway and nothing told it to give up. Devices on it had “no internet” while every other segment was fine. The clean fix is to enable “Skip rules when gateway is down” under Firewall settings, so a policy rule whose gateway is offline is temporarily ignored and the traffic drops to your normal failover path. The alternative is pinning to a gateway group with tiers rather than a single gateway, so the “policy” is really “prefer this line but fail over if it dies.” I now use groups for anything that must stay online and single gateways only where going dark on that line is genuinely acceptable. Decide which you mean for every policy rule.

How Do Aliases Keep Policy Routing Maintainable?

Aliases let you name a group of hosts, networks, or ports once and reference that name in many rules, so when things change you edit one alias instead of hunting through dozens of rules — the OPNsense aliases documentation covers the supported types in full. For policy routing, an alias for “devices that must ride the good line” or “destinations that should always use the backup” keeps your intent readable and your future edits sane.

Rules without aliases rot fast. Six months on, a ruleset full of raw IP addresses is unreadable, and changing which devices get priority routing means editing every rule by hand and inevitably missing one. With an alias, the rule says something human — “PriorityClients out WAN_FIBER” — and updating who counts as a priority client is a one-line change to the alias that instantly applies everywhere it is used. I lean on aliases heavily across the whole firewall, not just for routing, because the network you can read at a glance is the network you can change without breaking. It is the same labeling discipline I apply to the physical patch runs in the rack: name things well now, thank yourself later.

Which VLAN Goes Where in My House?

My policy is simple and priority-driven: the work VLAN and home automation ride the fiber and fail over to cellular because they must stay up; the kids’ and media VLANs stay pinned to fiber only, so they never touch the metered backup; guest and IoT get the least priority. During an outage, the important, low-bandwidth stuff keeps working on cellular while the heavy, optional stuff simply pauses.

Concretely, that means my work segment uses a gateway group — fiber preferred, cellular as fallback — so a client call survives an outage on the backup line. The media and gaming VLANs use single-gateway rules pinned to fiber with “skip rules when down” enabled, so if fiber dies they go offline rather than draining cellular with a 4K stream or a game download; they come back the moment fiber returns. Home automation and remote access sit with the work group because I want to reach the house and keep the smart-home hub alive even when failed over. The guest and IoT segments get whatever is left and are never allowed to prioritize the backup. The result is exactly what I want during the handful of real outages a year: the network quietly keeps the things that matter running and lets the rest wait, without me touching a thing. That is policy routing doing its job — turning two internet lines into a set of deliberate choices instead of a coin flip.

Further Reading

• Multi-WAN & Internet Failover: A Home Network Guide
• Setting Up Multi-WAN Failover in OPNsense
• Internet Failover With a 5G or LTE Backup Modem
• VLAN Firewall Rules Explained
• The Home Network VLAN Guide