OpenVPN TUN vs TAP: Three Conditions That Decide It

Two tunnels can carry the same file transfer and differ completely in what they put on the wire. One moves IP packets between two addresses; the other moves Ethernet frames and can be bridged into a segment. That difference decides which applications work, which clients can connect, and how much network design you are signing up for.

Three conditions settle it in practice. Work through them in order, because the first one usually ends the discussion.

What each interface actually carries

A TUN device is a layer-3 point-to-point interface: the kernel hands it IP packets and the tunnel carries them to a peer address. A TAP device is a layer-2 interface that carries Ethernet frames, which is what makes bridging possible at all, as the kernel documentation describes. Neither changes how the payload is encrypted, and neither is a strength setting. The choice is about what the endpoints must exchange, not about how well the traffic is protected.

One consequence follows immediately: both ends must agree. A client configured for one device type cannot join a server configured for the other, whatever else matches.

Condition one: does anything need layer two?

Bridging earns its complexity when a protocol genuinely needs the same broadcast domain: non-IP traffic, discovery that cannot cross a router, or an application that insists on being on one segment. Everything else is a routing problem, and routing solves it with far less machinery. Extending a segment across a wide area also extends its broadcasts, so loop prevention, address planning and failure domains all become part of the design. That is a lot to accept for a requirement a single route would have met.

The test is concrete: name the application that fails on a routed tunnel and say why. If the answer is that it needs broadcast, layer two is the honest answer. If the answer is that somebody could not reach one server, the requirement is a route or a firewall rule.

Condition two: can the clients do it?

Support is not uniform. Desktop clients generally expose both device types, while mobile and embedded clients often implement only the routed mode, and a profile that imports without complaint may still fail when it tries to create the interface. Check the specific client and version rather than inferring the feature set from the platform name.

An unsupported-option error is not an invitation to delete unfamiliar lines until the import succeeds. It means the profile and the client disagree about what is possible, and the repair belongs with the operator who issued the profile. Removing an option to silence a validator can produce a connection that appears to work while quietly omitting the property it existed to provide.

Condition three: is this really an interface question?

Two adjacent choices get blamed for interface problems. The virtual device decides what enters the tunnel, while UDP or TCP decides how the outer transport behaves, and neither cures transfers that stall. When large transfers hang while small ones succeed, packet size and MTU deserve the attention instead.

A client that connects and then cannot reach one internal host is usually looking at routing, a firewall rule or a missing return path.

For a managed service, use the interface arrangement the operator's profile specifies, because the server side is already built around it. For a private deployment, choose from the application's real requirement and write the reason next to the choice.

The question is not which option is stronger. It is which one the traffic actually needs.