VLAN Gateway First, Then the VPN Exit Decision

Two VLANs need different VPN exits, and the first question is not which policy to write but which device answers the default gateway. If a switch routes between the VLANs, a firewall rule can describe a path the packets never take. Walk the topology before touching the exit policy.

Step one: find the gateway each VLAN uses

Ask each client for its gateway, and ask the switch which interface owns the VLAN. The default gateway determines the first routing decision for traffic leaving the subnet, so it also determines which device is able to apply a policy.

ip route show default
show ip interface brief

Two coherent layouts are common. The firewall owns the VLAN interfaces and routes between them; or the multilayer switch owns them and routes locally, sending only external destinations to the firewall. Both work, and they put the policy in different places.

Pick one deliberately, because a mixed layout is how rules end up on the wrong device.

Step two: decide where local policy lives

If the switch routes between staff and lab, a firewall rule cannot inspect an exchange that never reaches the firewall. Local policy has to live in the switch's own access controls, or the traffic has to be steered through an inspection point on purpose.

The reverse choice has a cost too. Making the firewall the gateway for every VLAN puts local routed traffic into that appliance's capacity and availability plan, so a firewall reboot becomes an inter-VLAN outage. Evaluate the actual hardware rather than assuming switches are stateless or firewalls are slow. Capacity planning is easier when the device you reboot is not also the path between two busy subnets.

What matters is whether the chosen policy sits on the path the packets actually follow.

Step three: give the two devices one transit

When the switch routes, a single transit subnet keeps the topology readable, instead of hanging both boxes off every client VLAN as rival routers. The switch owns the client subnets and the firewall owns the outside.

# on the switch
ip route 0.0.0.0/0 10.255.0.2
# on the firewall
ip route add 10.20.10.0/24 via 10.255.0.1
ip route add 10.20.20.0/24 via 10.255.0.1

The switch sends external destinations to the firewall's transit address, and the firewall has return routes to both client prefixes through the switch. Keep management access, DHCP gateway settings and VLAN membership intact during the migration, because those three are what turn a clean cutover into an afternoon with a console cable.

A transit design also makes the next firewall replacement a routing change rather than a rewiring project.

Step four: choose the exit from the source that arrives

With ordinary routing and no source translation in between, the firewall receives the original staff or lab address on the transit interface. Both VLANs arrive over one link, and their IP identities survive that.

Express the VPN choice using that source address and the intended destinations on the actual ingress path. OPNsense's rule documentation distinguishes a default gateway setting, which follows system routing, from an explicit gateway, which invokes policy-based routing. Use the explicit form when the choice depends on where the packet came from. A normal default route has no reason to look at the source at all.

Keep local destinations outside an overly broad exit rule, and check the supported gateway model for the release you run.

Step five: prove both paths

Write the result as two sentences: staff traffic to approved destinations leaves through exit A, and lab traffic to approved destinations leaves through exit B. Add the return routes, the translation rules and the intended behaviour when an exit is down.

traceroute -n 198.51.100.10

Then test a local inter-VLAN service separately, because it exercises a different decision in the same design.

A fresh flow from each VLAN, a working local service and a documented outage path together prove the design; a single successful ping proves only that one path existed at that moment.