The three classic options for branch connectivity
MPLS gives predictable, SLA-backed performance from a leased circuit, but costs a lot per month and adding a branch can take weeks of carrier process. Site-to-site IPsec is cheap but works at Layer 3: each branch is a separate subnet with routing between them, which breaks anything that relies on broadcast. Leaving each branch independent makes management grow linearly with the number of sites.
The hidden cost of a Layer 3 tunnel
- DHCP: a central DHCP server cannot serve branch devices directly; every branch needs a DHCP relay.
- ARP and broadcast: broadcast packets do not cross the router, so legacy and some industrial protocols stop working.
- mDNS / service discovery: network printers and IP phone auto-discovery are invisible across branches.
- IP planning: every branch needs its own subnet, and mergers or moves force renumbering.
Each item looks small on its own; together they are why many networks feel unnecessarily complex.
What L2 tunnelling changes: a single broadcast domain
Layer 2 tunnelling joins branches as if they were plugged into the same physical switch. All endpoints share one broadcast domain, so ARP, DHCP and mDNS flow naturally between sites. One central DHCP server serves every branch with no relay, there is no separate IP plan or routing table to manage, legacy broadcast-dependent applications keep working unchanged, and a new branch simply extends the existing network.
There is a trade-off to respect: one broadcast domain means broadcast traffic reaches every branch. In deployments with many endpoints, VLAN segmentation and broadcast storm control must not be skipped.
OpenVSwitch and Q-in-Q
Using OpenVSwitch in the data plane turns the tunnel from a plain pipe into a manageable virtual switch with flow rules, VLAN port assignment and programmatic traffic steering.
The key capability is Q-in-Q (802.1ad): a VLAN tag wrapped inside another VLAN tag. That lets a branch carry its own VLAN structure (say VLAN 10 office, VLAN 20 cameras, VLAN 30 guest) across the tunnel untouched — you extend the existing trunk to headquarters without redesigning the branch network. Without Q-in-Q you would need a separate tunnel per VLAN, which makes both configuration and troubleshooting far harder.
MTU: the most common mistake
Tunnelling adds headers to every packet. If the standard 1500-byte MTU is left untouched, some packets fragment inside the tunnel or are dropped entirely. The symptom is misleading: ping works, small requests work, but large file transfers or certain HTTPS sites hang.
The fix is to lower the MTU on the tunnel interface to account for the header overhead, use a larger MTU on the transport link with jumbo frames where possible, and keep automatic MTU discovery enabled.
Failover
What matters is not whether a link fails but how quickly it comes back. When the primary fibre is cut, the tunnel must re-establish over a secondary WAN — backup fibre or 4G/LTE — within seconds. That requires continuous health checking between tunnel endpoints, with the path change happening without tearing down the L2 link above it. Done well, users feel a brief pause and sessions survive.
Encryption and topology
Carrying L2 over the internet without encryption is not an option. WireGuard is a modern, low-latency choice; IPsec remains available where compliance requires it.
- Hub-and-spoke: simple to manage, all traffic passes through headquarters — suited to organisations that want central security inspection.
- Full mesh: branches connect directly, lowering latency for inter-branch traffic.
Deployment and central management
The biggest operational cost of distributed infrastructure is on-site installation. Being able to commission a branch without sending a network engineer determines whether the project scales. A single-command install script with a prepared configuration file reduces on-site work to minutes. After that, every endpoint must be visible in one web panel with configuration pushed centrally — otherwise each change becomes twenty separate jobs across twenty branches.
Marta L2 Tunnel
Marta L2 Tunnel is the complete appliance implementation of this approach: an OpenVSwitch data plane running natively on FreeBSD and Debian/Ubuntu, VLAN trunk transport with Q-in-Q (802.1ad), deployment as hardware or as a virtual machine (VMware, Proxmox, KVM, Hyper-V), hub-and-spoke or full mesh topology, optional WireGuard/IPsec encrypted tunnels, automatic failover over a secondary WAN, per-VLAN QoS with DSCP marking, and jumbo-frame-capable automatic MTU discovery. Field installation runs in a single command via kur.sh and sdwan.conf, and every appliance is monitored and configured from a central web panel.
Contact us to review your branch topology and design the right layout together.