Routed VPN vs Bridged LAN for a Branch to Lab Link

There are two ways to make a branch reach a home lab, and the difference is not a setting. You can route between distinct prefixes, so each site keeps its own broadcast domain, or you can bridge the two LANs into one, so broadcasts and discovery traffic behave as if everyone were in the same room. Routing is the design that survives contact with a real network. Bridging is the design that makes the first week easy and the first outage interesting. The comparison below is about what each one gives you and what it costs, followed by how to make the routed version testable.

Two ways to connect, one obvious trade

A routed link treats the home lab as a remote network with its own addressing. The branch asks for the lab prefix, the tunnel carries those packets, and the lab gateway answers from its own subnet. Nothing about the branch's ARP table changes, and nothing about the lab's DHCP scope reaches the branch.

A bridged link extends one Layer 2 domain across both sites. Discovery protocols work, devices appear automatically, and every broadcast, ARP request and multicast packet is now a candidate for crossing the tunnel, which is a large amount of traffic carried by protocols designed for a local segment rather than a WAN with a different MTU and a variable round-trip time.

What routing gives you

The first benefit is blast radius. A loop, a rogue DHCP server or a broadcast flood stays inside the site that produced it, because a router does not forward broadcasts. The second is addressing clarity: the branch prefix and the lab prefix are distinct, so a packet's destination tells you which site should answer it, and a firewall rule can say "branch to lab subnet" rather than "anywhere to anywhere".

The third is that it matches what the tunnel actually transports. An IPsec policy is a pair of prefixes, and the forwarding path on each side is ordinary IP routing with forwarding enabled on the gateway:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

What you give up is discovery by broadcast. That is a real loss and it should be replaced deliberately rather than worked around by bridging everything.

What bridging costs

Bridging has to carry Layer 2 frames over a tunnel, which means an encapsulation such as a GRE or VXLAN over IPsec rather than a plain policy-based tunnel. Once that exists, the two sites share a failure domain. Spanning tree sees the tunnel as a link, broadcast traffic consumes tunnel bandwidth, and any device that assumes a low-latency segment will misbehave in ways that are hard to attribute from either end.

It also removes the addressing check that keeps you honest. With one flat prefix, a duplicate address is not a routing mistake but two hosts quietly stealing each other's traffic, and overlapping prefixes between a branch and a lab are common in home-lab setups, so bridging does not resolve that conflict; it distributes it.

The security argument is the one that usually decides it. A bridge extends the segment on which link-local protocols operate, so a device in the branch can talk to lab devices that were never meant to be reachable from outside. If the lab has a hypervisor, a storage console and a management interface on the same flat network, that is now one segment with the branch as well.

Names without broadcast

The reason people bridge is usually discovery: a printer, a media device or a lab host that never shows up in a list. The routed answer is a name service. Publish the lab hosts in a zone the branch resolver can reach, then have users connect by name instead of by scanning the network. That is more work up front and considerably less work at every future change.

Multicast discovery is the harder case, and it deserves precision. Protocols such as mDNS use link-local multicast, which routers do not forward by default, so a lab host missing from a discovery list may still be reachable at its documented address. If a specific service genuinely requires multicast, plan that one protocol, with a reflector or a targeted forwarding rule, rather than bridging the entire LAN as a general repair.

A reflector is not a free win either. It imports the same chatty traffic you were trying to avoid, one service at a time, and it needs an owner who will notice when a device starts advertising more than it used to. Choose it per service, and write down why. Record which service needed it and what it advertises, because a firmware update can change that list without telling anyone.

Make the routed design testable

Pick one target, such as a lab web interface on its own server subnet, and prove it in both directions. From a branch host, confirm the address and the listening service locally, then connect through the tunnel and repeat. A tunnel that is up proves the gateways agree; it proves nothing about the host firewall or the return route.

The lab's normal gateway needs a route back to the branch prefix unless the design deliberately translates the source, and the server's own firewall has to accept the permitted remote range. Neither of those is configured by a successful tunnel. The strongSwan forwarding notes describe the packet path that has to work on each side.

Then test a denied destination as well. A branch user who needs one application does not need the hypervisor console, and the only way to know the policy is real is to try the thing it should refuse. Record the prefixes, the resolver dependency and the test results, and a future change to either site can be reviewed in minutes instead of rebuilt from memory.