Route One Branch Subnet Out the HQ SonicWall Internet Exit

Branch phones should leave through headquarters while branch laptops keep using the local WAN, and the route policy alone will not deliver that. A branch route can select the tunnel, but the tunnel policy has to accept the traffic, headquarters has to forward and translate it, and the reply has to come back the same way. Miss any of those three and the symptom is a subset of clients that lose internet exactly while the tunnel is up.

Start with the selector, not the route

Routing policy matches on a source, so the source has to be stable before anything else. Put the chosen devices in an address group that an administrator maintains, or better, on a dedicated segment whose membership follows the device role. When ordinary DHCP churn can move a matched address to a different machine, the policy silently selects the wrong client, and the first report is usually about slow browsing that is really a detour.

Name the group after the policy it serves rather than after a floor or a department, because the routing rule will outlive both. Record which devices are in it and who is allowed to add one.

Add the branch policy, then defend its order

On the branch SonicWall a route policy selects the source group, names the intended destinations and sets the tunnel interface as the gateway, which is what the supported tunnel-interface design exists for. Keep local and private-destination rules above the broad internet rule, since the first match wins and a private prefix pushed into the tunnel arrives at headquarters only to be dropped. Preserve the firewall's own route to its VPN peer as well, or the tunnel transport will follow the policy it depends on. None of this forces you to convert every existing policy-based tunnel; a tunnel interface is one supported choice among several.

Order is the part that changes by accident. Anyone adding an exception has to insert it above the broad rule, and anyone editing the broad rule can invert the whole design in one save. Write the intended order next to the policy and re-check it after firmware updates, because interface naming and policy rendering do shift between releases.

Finish the path at headquarters

The tunnel policy at headquarters must accept the traffic the branch route now selects. An interoffice selector scoped to the headquarters private LAN is not permission to carry arbitrary public destinations, so the policy needs the branch source and the destination range you actually intend. Headquarters then forwards that arriving traffic to its internet uplink under its own access rules, and SonicWall's central-exit example includes source translation for the remote network at the central WAN. Without that translation the far side sees a private branch address and has no route back to it.

Replies are the other half of the contract. They must return through the tunnel or through the stateful translation created for them, and private-site traffic may need different NAT treatment than public egress. Keep those rules distinguishable, because one broad translation rule that hides every internal source makes later logging and troubleshooting much harder to read.

Decide what the group does when the tunnel drops

If the central exit is a requirement rather than a preference, falling back to the local WAN is a compliance failure even though users stay online. SonicOS documents a drop-tunnel-interface route as the supported way to stop selected traffic from taking an unintended alternate path.

Match that route's scope and priority under the installed release, and test it by bringing the tunnel down instead of trusting the label. A group that must never egress locally should fail closed, while a group where availability matters more may legitimately fall back; both are decisions, and neither should happen by default.

Verify from three clients, then roll back cleanly

A ping to the central gateway tests the wrong thing, because it originates at the firewall rather than at a selected client. Test from devices instead, and test three of them: a selected device, an ordinary device that should stay local, and one that depends on local services.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Compare where the public request actually surfaced. A selected client should reach the internet through the headquarters exit, and an ordinary client should still present the branch's own address on the far side; 203.0.113.10 is a documentation address used as a stand-in for the destination you care about. Include DNS in the same pass, because a client that queries the branch resolver can produce a router-originated lookup with a different source and therefore a different route.

Rollback is the saved policy order plus the address group. Restore the previous order, remove the group from the policy, and re-test both device classes. Keep the exported configuration with the change record, since the next engineer needs to know which rule was the broad one before somebody edited it.