Bridged Sites Still Need a Local Internet Exit Decision

The VLAN extension tested clean: hosts at both sites see each other, file shares work, and printers answer. Then someone at the smaller site notices that every download is using the other site's internet line, and the ticket arrives as a bandwidth complaint. The bridge did exactly what it was asked to do. It carried frames between two buildings, and it never had an opinion about which router those frames should use for the internet.

The bridge carries frames, not decisions

A Layer 2 extension makes two locations look like one broadcast domain, so ARP requests, DHCP broadcasts and same-subnet traffic all cross the tunnel. That is the entire service it provides. Nothing in the bridge inspects a destination address, compares it against a site's uplink, or steers traffic toward the nearer exit. Every client still makes its own local versus remote decision using the address and mask it was configured with.

Put two routers on that shared subnet and both become plausible gateways, whether or not either is close to the client that uses it.

How a client picks its gateway

The IPv4 decision described in RFC 1122 is simple. A destination inside the client's connected subnet is reached directly, with ARP, and a destination outside it goes to the configured default gateway. That is why same-subnet traffic between the sites can cross the bridge without any router involvement, and why internet traffic depends entirely on the gateway address the client received. The two behaviors are independent, and a working file share proves only the first one.

If a client at the small site was configured with the big site's router, its internet frames cross the tunnel first and exit from there.

Changing the VPN appliance's own default route does not move that client's gateway, because the client is not using the appliance as a router at all. The appliance also needs a separate route for its far peer so the tunnel carrying those frames stays up, and conflating the two is how a bridge extension takes down its own transport.

Let DHCP express the intended exit

Option 3 in a DHCP reply supplies a list of router addresses on the client's subnet, in preference order, and clients normally take the first one that answers. The mechanism is fine; the ownership is where designs go wrong. Record what an actual lease delivers at each site rather than assuming that the nearest DHCP server will hand out the nearest gateway.

Run one coordinated allocator, or two that are explicitly configured for the same policy, and give the policy an owner. A second independent allocator added at the remote site does not create locality, it creates two authorities for the same broadcast domain.

Do not assign one gateway address to two independently active routers just to make both sites' settings look identical. A shared virtual address across a bridged segment is a first-hop redundancy design with its own requirements, and a hand-rolled version produces ARP conflicts that look like intermittent packet loss. If the application does not actually need a shared Layer 2 segment, separate routed prefixes with local defaults are simpler to operate and easier to explain during an incident.

Test the four things separately

Ask for four observations, not one. Take a fresh DHCP lease at each site and record the router and mask it received. Reach a same-subnet service at the other site and confirm the path is the bridge rather than a routed detour. Fetch something from the public internet at each site and confirm which uplink carried it. Then drop the tunnel and see what breaks, because a site that loses all connectivity when the bridge fails was depending on the far gateway without anyone noticing.

Those four results tell you whether you have an intersite bridge, a local exit, or an accidental backhaul, and they take ten minutes to collect.

The design principle is unglamorous: bridging decides reachability, DHCP decides the gateway, and the routing table on the appliance decides the tunnel's own path. Keep the three in separate conversations, because a single change that tries to fix all of them usually breaks two.