Two SSIDs, Two Exits: Which Policy Wins Where?

Two SSIDs on one gateway look like two networks and are not, until the gateway treats them that way. The radio hands both to the same bridge unless the access point maps each SSID to its own VLAN. And even with separate interfaces, traffic follows whatever route and firewall policy the gateway applies to that ingress. The SSID is a label; the policy is what you write down.

The SSID is not the policy

Name the two networks and write their intended exits before touching the router. Home goes to the ordinary WAN, Work goes to the VPN interface, and neither inherits the other's path. If both SSIDs land on one unsegmented bridge, the names have not created anything. That flat bridge is the most common way this design fails quietly.

The access point has to present them as separate interfaces, tagged or bridged apart. That is a prerequisite, not a detail. Write the mapping down before the first rule.

Classify by ingress interface

Classify at the point where the packet enters the gateway. The incoming-interface selector in a policy rule is separate from a source prefix, and it is the honest way to say that this traffic came from Work. Matching on the source address alone lets a client on Work claim a Home address and take Home's path.

ip rule show

Validate the source against the ingress as well, so the two tests agree instead of contradicting each other. A rule that checks only one of them is half a policy.

Keep the gateway's own tunnel out of it

Keep the gateway's own outer VPN connection on the underlay that works. A rule written for forwarded Work clients should not recursively capture the tunnel that carries them, which is the classic way to build a loop that only appears under load. Exempt the local output path or scope the rule to forwarded traffic. Test the loop case with a large transfer, not a single ping.

Translation needs the same care. If the VPN exit requires the gateway's tunnel address as the source, apply that only to Work sources leaving the VPN interface. Home's ordinary WAN translation is a different scope, and one unqualified masquerade rule cannot express both.

Write both rules next to each other, so the pair is visible as a design rather than two unrelated lines. A comment naming the source and the intended exit is enough.

Decide the failure state on purpose

Decide what happens when the VPN route disappears. For a work network the honest answer is usually deny: no fallback to the ordinary WAN, because the point of the separate SSID is that its traffic does not leave through the wrong path. Automatic reconnection is a convenience, not the blocking policy. A deny rule that never logs is indistinguishable from a broken network.

ip route show table work

Test a fresh connection from each SSID, then remove the tunnel and test again. Home should keep its ordinary path while Work fails closed. Check IPv6 separately, because two IPv4 subnets say nothing about it, and the policy-rule reference documents the selectors used above.