Isolated TAP Bridge Between Two Boards Over OpenVPN

Two development boards need to share one Ethernet segment while their benches sit in different buildings. The tunnel already exists and already carries Ethernet, so the remaining work looks like three commands and is not. What the host does with a bridged frame, where the PC's own address belongs, and which boundary the bridge does not create are three separate facts, and getting the second one wrong is the usual reason a lab works intermittently and its management access quietly degrades. None of those three facts is visible in a topology diagram.

The path below assumes an authenticated TAP connection between two Linux PCs, one dedicated wired port per bench, and a management interface that is not part of the experiment. The order matters: frames first, addresses second, boundary last.

What the bridge actually moves

A bridge is a switch implemented in software. It learns which MAC address appears behind which member port and forwards frames between members without consulting an IP routing table. Nothing in that description involves a subnet, a gateway or a default route, which is why enabling IP forwarding does not produce this attachment and why a ping can succeed while other traffic still fails. A board can reach its peer with no default route configured at all, which surprises people who expect layer two to behave like layer three.

Each PC contributes one wired port to the bridge and the TAP device to the same bridge, so a frame from a board enters the local port, gets forwarded to the TAP device, crosses the tunnel, arrives on the peer's TAP device and is forwarded out to the peer's board. The tunnel is a member port like any other, and the bridge does not know or care that a VPN sits behind it. That symmetry is what makes the example easy to reason about: each side has one lab-facing port and one tunnel port, and neither side is special.

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

The identical names on both PCs are local names, not shared objects. There is one Ethernet path between the benches, with no second cable and no second tunnel closing a loop; a bridge that sees the same MAC arrive on two ports will happily forward in circles.

Address the bridge, not its member ports

The PC's identity on the lab segment belongs to the bridge device. Member ports stay unnumbered, because a port is a forwarding member and an address on it would create a second, competing owner of the same segment. This is the correction that most hand-rolled recipes get wrong: they address the TAP device and the bridge, and then wonder which one the peer actually reaches.

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

The peer uses the same shape with a different host address, and the boards take addresses in the same range with the PC's bridge address as their next hop if they need one. Use documentation ranges until the plan is agreed, and reserve the range so it does not collide with anything the office already routes. Before running any of it, confirm that the member ports carry no leftover address, no DHCP client and no membership in another bridge, and reconcile the TAP device's addressing through whatever owns the tunnel configuration so it does not restore an address later.

Why one dedicated port per bench

A dedicated wired port is what keeps the experiment from becoming an office-wide change. The management interface carries SSH, the default route and the outer VPN connection, and none of that belongs on a bridge whose purpose is to move lab frames.

Attaching a management adapter puts the office LAN one forwarding decision away from a development board, and a board that misbehaves at layer two is exactly the kind of device you do not want on that segment. A Wi-Fi adapter is worse: bridging a wireless interface in infrastructure mode does not behave like bridging Ethernet, and the failure is confusing rather than clean.

Keep the lab range out of any production DHCP scope. If the boards later need dynamic addressing, one authorized allocator with one pool is the only arrangement that stays predictable; two sites' ordinary routers answering on the same segment produce addresses nobody can explain.

The boundary the bridge does not create

Bridging is not routing, and it is also not isolation. Frames that cross the bridge can still reach the host's filtering hooks, depending on the installed bridge-netfilter path, so the effective policy has to be inspected rather than assumed. Disabling the firewall because one frame went missing trades a specific bug for a general one.

IP forwarding between the bridge and every management or uplink interface should stay off or be explicitly denied, and that is a separate control from bridge membership. A board that selects the PC's lab address as its gateway tests exactly this: if management transit succeeds, the boundary you intended was never there.

Two more families deserve an explicit decision. The address plan does not make the bridge IPv4-only, so IPv6 and other EtherTypes need their own plan or filter. And a successful ping says nothing about whether the board's discovery broadcasts, multicast groups or jumbo frames will traverse the path, because those are different traffic classes with different defaults.

Finally, transport and confidentiality are different purchases. TAP carries Ethernet; the OpenVPN service supplies the protection around it. A VXLAN overlay also carries Ethernet and supplies no confidentiality by itself, so substituting one for the other changes the security properties even when the topology diagram looks identical.

Persistence and the tests that prove it

A command typed once after connecting is not a configuration. Persist the bridge, the port membership and the single host address through the PC's existing network manager, and tie the attachment to the TAP device's appearance so a reconnect does not leave a bridge with a vanished member.

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

Then test what the boards actually need in both directions, reconnect the tunnel, and restart one PC under the approved recovery plan. Confirm three things afterwards: management access still works independently, no duplicate lab address appears, and no unexpected production interface joined the bridge. That combination is the proof the experiment stayed inside its bench.