What TUN Does, and What the VPN Protocol Still Has to Do

Treating tun0 and a VPN protocol as one thing sends people to the wrong log. The interface is a local boundary where a userspace program exchanges IP packets with the kernel. The protocol is what that program does with the packets once it has them: transport, authentication, encryption and a peer. Creating the device selects none of those.

Two components, one packet path

The kernel writes an IP packet into the device, and the program reads it from a file descriptor. In the other direction the program writes a packet back and the kernel routes it as if it arrived on a real interface. TUN carries IP, while TAP carries Ethernet frames. Reading a packet at that boundary shows the framing, which is exactly what the device is for.

Everything beyond that boundary is the program's business. Two programs can use the same interface concept and do completely different things with the packets. The device itself has no opinion about what happens next. The file descriptor is the only handle the program has on the kernel side.

Create the device, then watch the boundary

Create a device deliberately when you are testing the boundary. A persistent device survives the process that created it, which is useful for experiments and a common source of confusion afterwards. Check the flags and the owner before blaming the VPN.

sudo ip tuntap add dev tun9 mode tun user alice
ip -d link show tun9

The link detail shows the device type and the attached owner. If no process has it open, packets written to it go nowhere. A device with no process attached can look healthy in a link listing while passing nothing.

What the interface name cannot promise

The interface name says nothing about encryption or authentication. A program can wrap packets in TLS, in a custom protocol, in IPsec, or in nothing at all. Choosing TUN rather than TAP changes the framing at the boundary, not the security design. The framing choice is real, and it is much smaller than the security question.

Detection works the same way: an observer sees the outer protocol on the wire, not a label saying which local device produced it. A tunnel that looks like something else does so because of its outer protocol, not because of its interface name. An observer cannot see which local device produced a packet, only what the packet looks like. Keep those two questions apart when you compare products, because one answer never implies the other.

Match the fix to the failing stage

Separate the failure stages when something breaks. A missing device, a permission error and a rejected login produce different evidence and different fixes. Read the local state first, then the program's own log, then the peer's view. Read all three before changing anything.

ip -d link show tun0
journalctl -u openvpn-client@corp --since '10 min ago'

If the device exists and a process holds it, the local boundary is working and the problem is further out. If the device is missing, no amount of credential checking will help. A stage you can name is a stage you can test. The TUN/TAP documentation describes the boundary and the device model.