TAP without a bridge: a virtual segment with a routed uplink

TAP hands Ethernet frames to the operating system, which is more capability than most remote-access designs need and less than a bridge. The kernel can address it, route through it and firewall it without joining it to any physical segment. That arrangement is worth understanding first: an isolated virtual Ethernet segment whose server acts as a router toward a real LAN. It gives layer-two behaviour inside the tunnel and ordinary IP forwarding outside it, which are two different promises. The rest of this is the build, the route, the return path and the rollback.

Build the isolated segment

On Linux the interface takes three commands: create it, bring it up, give it an address inside the segment you intend. Pick a prefix that does not collide with the office LAN and write it down, because the collision is invisible until a host answers that should not exist.

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

Nothing here requires a bridge, and nothing prevents adding one later. The kernel TUN/TAP documentation describes the interface itself; bridge membership and forwarding policy are separate decisions you make afterwards.

Route across the boundary

Enable forwarding, permit the two prefixes in the forward chain, and add a route toward the office prefix with the LAN router as the next hop. The VPN side then sends office-bound traffic to the server as its gateway, and the server forwards those packets as itself rather than as a bridge. A TAP interface with forwarding disabled is a segment that answers locally and reaches nothing beyond it, which is the usual half-finished state. Check the interface counters on both sides afterwards, since a climbing receive count with a flat transmit count on the LAN side means a forward-chain drop rather than a bad route.

Write the route and the firewall rule as one change, because either alone produces a state that looks like a routing failure from the client's side.

Decide the return path

Either the LAN router learns a route back to the VPN prefix, or the server translates source addresses on the way out. Translation makes the return path trivial and destroys source identity, so destination logs will show the server's address for every client behind it. A routed prefix keeps identity and requires a change on equipment you may not manage.

Choose deliberately rather than by whichever is quicker to type. A single routed prefix is usually cleaner than translation, and translation is usually better than teaching an unmanaged router a new prefix for one lab.

Keep broadcast scope deliberate

Within the virtual segment, DHCP, discovery and neighbour advertisement behave as they would on a switch, because it is one link. Across the routed boundary they do not, so office DHCP and service discovery need an explicit design rather than an assumption that TAP implies them. The interface type is not a relay for services that live somewhere else.

That is the honest reason to choose TAP at all: something on the virtual segment needs link-local behaviour. If nothing does, a TUN device with a routed prefix is smaller, and there is less to explain when it breaks.

Verify, then write the rollback

From a VPN client, ping the LAN router, ping a host, and open one service that matters over TCP. Then check the counters and the forward chain, because a policy drop looks exactly like a missing route from a distance. Rollback is the reverse of the build and belongs in the change record before you start: remove the route, remove the address, delete the interface.

If the requirement really is one Ethernet segment spanning two sites, a bridge is the honest answer and a different design with a different blast radius. If the requirement is reachability, the isolated segment with a routed uplink does the job with less to explain later.