Routed or bridged VPN: pick by what the client must reach

Two tickets arrive on the same day: one user needs an internal web app, and one engineer needs a bench instrument to behave as if it sat on the same Ethernet segment. Both get answered with put them on the VPN, and that is where the trouble starts. A routed tunnel and a bridged tunnel extend different relationships, and only one of them matches each request. Choosing the topology is an access decision, not a cryptography setting.

Two requests that look the same at the ticket desk

The employee's requirement is a service, reachable over IP, from a device you do not control. The engineer's requirement is link-level: the instrument expects to see Ethernet frames, broadcast discovery, and possibly DHCP from the segment it believes it is on.

Those are different questions, and answering both with a bridge widens the employee's access to the whole office LAN for no reason.

Write the requirement as a sentence before choosing: which destinations, which protocols, and which peers must appear to be local. If the answer is a host and a port, routing covers it. If the answer is a frame-level relationship with devices that only speak broadcast, bridging may be the only option. Anything in between deserves a test segment rather than the production LAN.

A route is narrower than LAN membership

A routed client gets an address on a tunnel subnet and routes for the prefixes you choose. It can reach the application server and nothing else, if that is what the policy says. The gateway becomes the enforcement point, provided every relevant path crosses it.

Do not confuse a route with a permission. Telling a client how to reach a subnet does not stop it from trying another destination.

Apply access control where it can actually enforce the flow, and keep the application's own permissions in place. A broad forwarding rule or a forgotten second interface can grant more than the diagram suggests. Read the effective rules rather than the intended ones. Then test a destination that should fail, because a policy nobody has tried to violate is a hypothesis.

A bridge changes the admission question

Bridging combines a physical interface and a TAP device into a software switch, so remote devices join the same broadcast domain. That is a real capability and a real risk: the remote device is no longer a routed guest, it is a participant.

Decide which devices may join, which frame types must cross, and where unwanted interaction gets blocked. Addressing and DHCP authority become part of the shared network, and two DHCP servers on one segment produce exactly the mess you expect.

For the instrument, a dedicated test segment is usually a better fit than the office LAN. Keep management access outside the experiment, and define how the temporary participant is removed when the work ends.

Filtering exists in both topologies

A bridge is not inherently unfilterable, and a route is not inherently safe. Linux bridge filtering has its own hooks and its own rule syntax, and a rule written for routed IP forwarding does not automatically apply to bridged frames.

Check what the platform actually supports before promising a boundary:

bridge link show
nft list ruleset

TUN and TAP describe the interface's traffic, not the cipher. Switching interfaces fixes none of that: peer authentication, a stolen key, and an outdated cryptographic policy all survive the change. Both ends still need settings that match and are still supported.

Prove the boundary with three attempts

Acceptance is three observations, not a diagram review. The required operation must work, an unrelated destination must fail, and the gateway's own management services must stay out of reach.

Run the allowed and denied paths from the same client, and record both:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

For a bridge, add the link-level checks: whether the permitted discovery traffic crosses, whether addressing comes from the intended authority, and whether the temporary participant is gone after removal. When plain routed IP already satisfies the requirement, joining the office Ethernet segment needs a separate justification, and it should be written down before the change.