Outbound NAT with multiple WANs — per-interface source selection · OPNsense

Multi-WAN deployments have a return-path problem that single-WAN deployments do not. A packet from a LAN client to an Internet host leaves the firewall on some WAN; the remote host replies; the reply must arrive on the same WAN — otherwise the firewall’s state table will not match the reply, and the reply will be dropped. The reply is destined to the source IP the packet appeared to come from. If the source IP is the WAN-A IP, the reply must come back via WAN-A. If WAN-A is down and the reply arrives via WAN-B, the reply is to WAN-B’s IP — which the remote host never sent to.

Outbound NAT is what creates that binding. The translation pins the internal source to a specific WAN IP. The remote host replies to that WAN IP. The reply arrives on the WAN that owns that IP. The state entry binds the flow to that WAN. Return traffic works.

This lesson covers the NAT side of multi-WAN: the rules that pin specific subnets to specific WANs, the return-path implications, and the production patterns that work.

The relationship between NAT and routing

A multi-WAN estate uses both NAT and routing to deliver outbound traffic to the right WAN:

Routing determines which WAN the packet physically leaves on. The kernel routing table decides based on the destination IP and the longest prefix match (or, with policy routing, the source plus the destination).
NAT determines which WAN IP the source is translated to on the way out. The nat rule rewrites the source.

These two decisions are independent. The kernel can route the packet via WAN-B while the nat rule translates the source to the WAN-A IP. The result: a packet leaves on WAN-B but claims to be from WAN-A’s IP. The remote host replies to WAN-A’s IP; the reply arrives on WAN-A; the firewall’s state table matches the reply on WAN-A (because that is the WAN the source was translated to).

This is the failure mode of “auto outbound NAT + multi-WAN”.

The fix: make the routing decision and the NAT decision agree. Either route the packet via the WAN the source IP belongs to, or translate the source to the WAN IP of the egress interface.

The auto outbound NAT trap in multi-WAN estates

In a multi-WAN estate with the default Automatic outbound NAT, OPNsense generates one nat rule per WAN. Each rule translates “any internal source” to “this WAN’s IP”. The routing decision on the outgoing path is made by the kernel based on the default route (or a gateway group). The two decisions disagree on multi-WAN estates.

The symptom: outbound traffic from LAN clients works, but the return path is broken. A flow leaves WAN-A but is translated to WAN-B’s IP. The remote host replies to WAN-B; the reply arrives on WAN-B; the state table says the flow should be on WAN-A; the reply is dropped.

The fix: Manual outbound NAT, with one rule per (source subnet, WAN) pair, plus a routing decision (gateway group or static route) that sends the flow out the WAN the source IP belongs to.

The pattern: pin source subnet to WAN

The production pattern for multi-WAN outbound NAT:

For each source subnet that has a specific WAN requirement, create a manual nat rule that translates the source to that WAN’s IP and uses that WAN as the egress interface.
For each WAN, ensure the routing decision sends the flow out the matching WAN. This can be a gateway group bound to the LAN rule, a static route, or a default route via the matching gateway.
For source subnets with no specific requirement, use the default WAN (typically the WAN chosen by the gateway group’s tier 1).

The implementation:

# LAN-1 (192.0.2.0/24) -> WAN-A (198.51.100.1)
nat on igb1 inet from 192.0.2.0/24 to any -> (igb1:0)

# LAN-2 (10.99.0.0/24) -> WAN-B (198.51.100.5)
nat on igb2 inet from 10.99.0.0/24 to any -> (igb2:0)

# LAN-3 (10.10.0.0/24) -> WAN-A by default
nat on igb1 inet from 10.10.0.0/24 to any -> (igb1:0)

The matching routing decision is in the LAN firewall rules or static routes:

A firewall rule on 192.0.2.0/24 bound to gateway group WAN_A_primary.
A firewall rule on 10.99.0.0/24 bound to gateway group WAN_B_primary.
A firewall rule on 10.10.0.0/24 bound to gateway group WAN_A_primary (default).

The gateway group tells the kernel to route via the WAN the gateway points to; the nat rule tells PF to translate to the IP on that WAN. The two agree.

Read-only / Safemulti-WAN NAT ruleset— A Manual-mode outbound NAT ruleset for a multi-WAN estate. 192.0.2.0/24 and 10.10.0.0/24 are pinned to WAN-A (igb1); 10.99.0.0/24 is pinned to WAN-B (igb2). The matching firewall rules on the LAN side must also route via the corresponding gateway for the return path to work.

$ pfctl -s nat

nat on igb1 inet from 192.0.2.0/24 to any -> (igb1:0)
nat on igb2 inet from 10.99.0.0/24 to any -> (igb2:0)
nat on igb1 inet from 10.10.0.0/24 to any -> (igb1:0)

Illustrative output

The return-path trap

The return path is the most common source of “multi-WAN NAT breaks some flows” tickets. The flow:

Client 192.0.2.50 sends a SYN to 203.0.113.50.
Firewall routes via WAN-A (gateway group binding).
NAT rule translates source to 198.51.100.1 (WAN-A’s IP).
Packet leaves on WAN-A with source 198.51.100.1.
Remote host replies to 198.51.100.1 with source 203.0.113.50.
Reply arrives on WAN-A (because 198.51.100.1 is WAN-A’s IP).
Firewall matches state, reverse-translates, delivers to client.

Now the failure mode:

Client 192.0.2.50 sends a SYN to 203.0.113.50.
Firewall routes via WAN-B (because the gateway group failed over from WAN-A to WAN-B).
NAT rule still translates source to 198.51.100.1 (WAN-A’s IP) — because the rule is “from 192.0.2.0/24 to any, WAN address” using WAN-A’s IP.
Packet leaves on WAN-B with source 198.51.100.1 — but 198.51.100.1 is not an IP on WAN-B.
Remote host replies to 198.51.100.1 — but the reply goes back to WAN-A (because that is the network that owns 198.51.100.1).
Reply arrives on WAN-A. The state entry says the flow left on WAN-B. PF drops the reply because of the route-to asymmetry.

The fix is one of:

Bind the nat rule’s translation target to the egress interface. Use (\<egress\>:0) or specify the IP dynamically. PF picks the egress interface at runtime based on the route-to clause, so the translation follows the route.
Disable the gateway group failover for that source. If WAN-A is down, do not failover the flow to WAN-B; let it fail instead. This is acceptable when the source has a hard requirement on WAN-A.
Use a single gateway and rely on failover at the WAN layer. One logical WAN with two physical interfaces; failover at the link layer keeps the IP stable.

Reading the generated ruleset for multi-WAN

The verification after configuring multi-WAN NAT:

pfctl -s nat — every rule has the correct interface and target. WAN-A’s rules all reference igb1 and (igb1:0); WAN-B’s rules reference igb2 and (igb2:0).
pfctl -s rules | grep route-to — every relevant firewall rule has the right route-to (igbN ...) clause.
netstat -rn — the routing table has the expected default routes via the right gateways.
tcpdump -nei igb1 host \<remote\> — capture shows the post-NAT source as 198.51.100.1 for flows that should leave on WAN-A.
tcpdump -nei igb2 host \<remote\> — capture shows the post-NAT source as 198.51.100.5 for flows that should leave on WAN-B.

If a flow’s capture on the WAN shows the wrong source IP, the nat rule and the route-to are not aligned. Re-check both.

How PF coordinates nat-to and route-to

PF supports two clauses on a single rule: route-to (which egress interface and gateway) and nat-to (which translation target). When both are present, PF uses the route-to interface to determine the egress and the nat-to address to determine the translation.

OPNsense generates these clauses from two places:

The gateway group binding on the firewall rule produces the route-to.
The Translation target field on the outbound NAT rule produces the nat-to.

When both are configured correctly, PF produces a rule like:

pass in on igb0 inet proto tcp from 192.0.2.0/24 to any port = https \
     route-to (igb1 198.51.100.1) \
     nat-to (igb1:0) \
     round-robin

The route-to says “send this out WAN-A via 198.51.100.1”. The nat-to says “rewrite the source to igb1’s primary IP”. The two agree because they reference the same interface.

If the route-to is (igb2 198.51.100.5) and the nat-to is (igb1:0), the rule says “send this out WAN-B but pretend it came from WAN-A’s IP”. That is the broken configuration.

Production patterns

Three patterns cover the common multi-WAN cases.

Two WANs, subnet pinning, no failover

Each subnet is bound to one WAN. If that WAN is down, the subnet loses Internet. Used when each WAN has a hard contract (VoIP provider, payment processor) and the requirement is “this subnet uses this provider”.

Configuration: gateway groups with a single tier (no failover), and manual NAT rules pinning each subnet to its WAN.

Two WANs, primary/backup with failover

Most traffic uses WAN-A; WAN-B is the backup. If WAN-A goes down, all traffic moves to WAN-B.

Configuration: gateway group WAN_A_primary with tier 1 = WAN-A and tier 2 = WAN-B. The firewall rule on the LAN is bound to this group. The NAT rule translates to WAN-A’s IP. When WAN-A fails, the route-to clause moves to WAN-B, but the NAT rule still references WAN-A’s IP — the failure mode described above.

The fix for this pattern: do not use a static NAT target. Use the egress interface as the NAT target, so the translation follows the route. Or accept the broken return path during failover and document it.

Two WANs, load distribution

Half the traffic uses WAN-A; the other half uses WAN-B. This is the hardest pattern and rarely done correctly.

Configuration: split the LAN into two subnets, each pinned to one WAN via gateway group + NAT rule. The application layer controls which subnet it talks from.

Multi-WAN failover breaks NAT without careful rule design

The most common multi-WAN production failure: a gateway group configured with failover from WAN-A to WAN-B, combined with an outbound NAT rule that translates to WAN-A’s IP. When WAN-A fails, traffic routes via WAN-B but the source is still WAN-A’s IP; the return path goes to WAN-A, which is unreachable.

The fix is one of:

Use the egress interface as the NAT target. PF translates to the egress interface’s primary IP, so the translation follows the route. This works when each WAN has its own primary IP.
Configure the gateway group without failover (single tier). When the WAN goes down, traffic stops. The application or the user retries.
Configure source-based routing without a gateway group. Bind the firewall rule to a specific gateway. Failover does not happen at the firewall; the upstream router handles it.

Choose deliberately. The default — gateway group with failover plus static NAT target — silently breaks.

Summary

In multi-WAN estates, the routing decision (which WAN the flow leaves on) and the NAT decision (which IP the source is rewritten to) must agree, or the return path breaks.
Auto outbound NAT in a multi-WAN estate produces the wrong binding. Use Manual outbound NAT and pin each subnet to its WAN.
The return-path trap: when a flow leaves WAN-B but the source is WAN-A’s IP, the reply goes to WAN-A and is dropped.
Verify with pfctl -s nat and tcpdump on each WAN. The post-NAT source must match the WAN the flow leaves on.
Gateway-group failover combined with static NAT target silently breaks return paths. Choose the failover pattern deliberately.