TAP or TUN? Android OpenVPN Clients and Bridged Servers

A profile that works on a laptop fails on the phone. The obvious move is to edit one word in the client config. That word will not help, because the two ends are not talking about the same kind of traffic.

TAP carries Ethernet frames. TUN carries IP packets. An Android VPN app is handed an IP interface, which makes one of those two arrangements possible and the other one not, regardless of what the config says.

The comparison is short, but it decides whether you can fix this on the phone or have to change the service.

Two tunnel types with different payloads

A TAP interface behaves like an Ethernet adapter. It carries frames, which means ARP, broadcast, and anything else a LAN carries below IP. That is what makes bridging possible: the tunnel extends a broadcast domain, and clients behave as if they were plugged into a switch.

A TUN interface carries IP packets addressed to it. There is no link layer to negotiate, no ARP, and no broadcast. Routing decides what enters the tunnel, and the server-side config uses a subnet rather than a bridge.

Both endpoints must agree on which of those they are doing. Changing dev tap to dev tun on one side does not convert the service; it produces a client that expects a routed tunnel and a server still pushing frames, and the handshake can succeed while nothing usable crosses.

What Android actually hands the app

The platform's VpnService API gives an application a virtual interface for IP packets, configured with addresses, routes and an MTU. There is no Ethernet adapter in that API, and no way for the app to conjure one.

That is why OpenVPN Connect documents support for routed TUN connections on Android rather than TAP bridging. The Android FAQ is the client-side statement of the boundary, and it matches the platform API.

Root networking tools, custom firmware, or a product that implements an explicit translation layer are different arrangements. The ordinary case is the one to plan around: an app that can import your file and run as a normal user, with an IP interface and nothing below it.

What it looks like when you try anyway

The connection usually establishes. That is what makes the failure confusing: the client reports connected, the server log shows a peer, and no application works.

Traffic addressed to the phone's assigned address does not arrive, because the server is bridging frames to a MAC address the phone never had. Broadcast-dependent discovery stays empty. If the LAN relies on DHCP across the bridge, the phone will not obtain a lease that way, and a manually assigned address in the bridged subnet still does not create the missing interface.

Some clients fail earlier, at profile import, when they see a device type they cannot implement. Either behaviour means the same thing, and neither is fixed by adding routes, changing DNS, or widening the tunnel's address range.

What the server side has to change

The fix belongs to whoever runs the VPN service, and it is usually additive rather than a migration. Run a second OpenVPN instance with a routed device, its own client subnet, and a server-side configuration that assigns addresses and pushes the routes the phones need. The existing bridged instance keeps serving the devices that genuinely need Ethernet.

Two details make that work in practice. The LAN needs a return route for the new client subnet, pointing at the VPN host, or replies will never come back. And the firewall on the tunnel host must forward between the tunnel interface and the LAN, which is the step most often missed when a test from the host itself succeeds.

If the operator cannot add a service, the alternative is a device that can join the bridge, which means a laptop or a router acting on the phone's behalf. That is a workaround with its own management cost, not an Android configuration.

Decide from the application, not the tunnel

Ask what the phone must actually reach, then map it. A file share or intranet site reached by name or address is an IP requirement, and a routed tunnel satisfies it once DNS resolves the name and the route exists. A discovery tool that browses the local broadcast domain is not an IP requirement, and no amount of routing will populate it.

That table is also the request to send. Name the application, the address or name it uses, and whether it depends on discovery. An operator can act on that description in a way that nobody can act on a phone that will not connect.

Finally, keep the TAP service for the devices that need it instead of making every client imitate a LAN adapter. Two services with clear purposes are easier to support than one that half-works for everybody.