Virtual network interfaces, TUN and TAP, are the unsung heroes of network virtualization, allowing userspace programs to interact with the kernel’s network stack as if they were physical network devices.
Let’s see one in action. Imagine you want to capture all traffic destined for a specific IP address, but you don’t want to mess with iptables or libpcap directly. We can use a TUN interface to create a virtual point-to-point link, send traffic to it, and then read that traffic from userspace.
First, create the TUN device. We’ll use ip tuntap add dev tun0 mode tun user $(whoami). This creates a TUN device named tun0 owned by the current user. The mode tun specifies a routed IP tunnel, meaning it operates at the IP layer.
sudo ip tuntap add dev tun0 mode tun user $(whoami)
sudo ip link set tun0 up
sudo ip addr add 192.168.100.1/24 dev tun0
Now, tun0 is up and has an IP address. Any IP packets routed to 192.168.100.0/24 on your system will now be sent to this tun0 interface.
To see this, let’s ping an IP in that subnet from another interface:
ping -c 1 192.168.100.2
The packet will be sent to tun0. Now, in a separate terminal, we can read it:
sudo cat /dev/net/tun
You’ll see a raw IP packet printed to your terminal. This is the ping request that was sent to tun0. You can then process this packet in your userspace program.
The key difference between TUN and TAP lies in their layer of operation. TUN interfaces operate at the IP layer (Layer 3), meaning they handle IP packets. TAP interfaces, on the other hand, operate at the Ethernet layer (Layer 2), handling Ethernet frames. This makes TAP interfaces suitable for bridging and creating virtual switches.
Consider a scenario where you’re building a VPN. A TUN interface is perfect for this. Your VPN client can create a TUN device, route all outgoing traffic through it, and then your userspace VPN daemon can read these IP packets, encrypt them, and send them over the network to the VPN server. The server would then decrypt them and inject them back into its own TUN interface to be processed by the kernel.
TAP interfaces are more often used when you need to emulate a physical network card. For example, in a virtual machine, a TAP interface can be used to connect the VM’s virtual network card to the host’s network. The host’s TAP device would be connected to a bridge, allowing the VM to communicate with other devices on the same network segment as the host.
The ip tuntap add command is your primary tool for creating these interfaces. You can specify mode tap to create a TAP device. For example, sudo ip tuntap add dev tap0 mode tap user $(whoami) creates a TAP device named tap0.
sudo ip tuntap add dev tap0 mode tap user $(whoami)
sudo ip link set tap0 up
sudo brctl addif br0 tap0 # Assuming 'br0' is an existing bridge
With a TAP device, you’d be reading and writing Ethernet frames. This is crucial for protocols that rely on MAC addresses, like ARP.
The control mechanism for these interfaces is often a userspace program that opens /dev/net/tun. This file descriptor then becomes the conduit for sending and receiving packets. When you write to this file descriptor, the kernel injects the data into the network stack as if it arrived on a physical device. When you read from it, you receive packets that would have been sent out on that virtual device.
The IFF_TUN and IFF_TAP flags passed during the ioctl call to /dev/net/tun determine whether you get a TUN or TAP device. The IFF_NO_PI flag can be used to omit the 4-byte packet information header that the kernel prepends to packets read from the device.
One of the most powerful, yet often overlooked, aspects of TUN/TAP is their ability to operate without requiring root privileges for the userspace application, provided you use the user $(whoami) option during creation and ensure correct permissions on /dev/net/tun. This allows unprivileged applications to create and manage their own virtual network interfaces, opening doors for sandboxed network environments and custom routing solutions.
The next step after mastering TUN and TAP is exploring how they are integrated into more complex network solutions like OpenVPN or WireGuard, which leverage these virtual devices to create secure, encrypted tunnels.