LFCE 27 🐧 Virtual Networking — TUN and TAP
TUN and TAP are virtual network kernel drivers that move packets between the kernel’s network stack and a userspace program. They are not physical interfaces, but they appear to the kernel as if they were, and they can be assigned IP addresses, added to routes, and used by any application that opens a socket. The distinction between the two is the layer at which they operate: a TUN device carries IP packets (Layer 3), and a TAP device carries Ethernet frames (Layer 2). This difference determines which kind of application can use them. A VPN that routes IP traffic uses TUN. A virtual machine or a bridge that needs to see Ethernet headers uses TAP.
The previous chapters covered network namespaces, bridges, and VLANs—all mechanisms for connecting and isolating interfaces within the kernel’s networking stack. TUN and TAP extend that stack to userspace. They are the interface between the kernel and the programs that implement VPNs, virtual switches, and container networking. OpenVPN, WireGuard (on some platforms), and QEMU/KVM all rely on these devices to move packets between the kernel and their own logic.
Key point: A TUN/TAP device exists only as long as a userspace program holds its file descriptor open. When the program closes the descriptor, the kernel removes the device and all associated routes. The device node is /dev/net/tun, and the program opens it and issues an ioctl() with either the IFF_TUN flag (for IP packets) or the IFF_TAP flag (for Ethernet frames) to register the device with the kernel .
Why TUN and TAP exist
The userspace-packet-processing problem.
The kernel’s network stack is designed to process packets from physical interfaces. A program that wants to implement a custom network protocol, a VPN tunnel, or a virtual switch cannot easily intercept packets at the kernel level without writing a kernel module. TUN and TAP solve this by providing a file descriptor that represents a network interface. When the kernel has a packet to send on that interface, it writes the packet to the file descriptor, and the userspace program reads it. When the userspace program has a packet to inject into the kernel, it writes to the file descriptor, and the kernel processes it as if it arrived on the interface . This is a clean boundary between kernel networking and userspace logic.
The Layer 2 vs Layer 3 distinction.
A TUN device is a point-to-point interface that carries IP packets. It has no MAC address and no Ethernet header. The kernel routes IP packets to and from the device based on the routing table. A userspace program reading from a TUN device receives raw IP packets and must parse the IP header itself. A TAP device is an Ethernet interface. It has a MAC address, it can be added to a bridge, and it carries Ethernet frames. The kernel handles the Ethernet layer, and the userspace program receives frames that include the Ethernet header. The choice between TUN and TAP depends on what the userspace program needs to do: route IP packets (TUN) or switch Ethernet frames (TAP).
The temporary-device problem.
A TUN/TAP device is not persistent by default. It is created when a program opens /dev/net/tun and issues the ioctl(), and it is destroyed when the program closes the file descriptor. This is intentional: the device represents a connection to a specific userspace process, and when that process exits, the interface has no purpose. For configurations that need the interface to persist across program restarts, the kernel supports persistent devices via the TUNSETPERSIST ioctl, but this is the exception rather than the rule .
a. TUN devices — Layer 3 packet interface
A TUN device carries IP packets. It is used by VPNs that route IP traffic between a client and a server. The device has an IP address and appears in the routing table, but it has no MAC address and does not participate in Ethernet bridging.
# Load the tun module if it is not already loaded
modprobe tun
# Create a TUN device named tun0
# This is typically done by a userspace program, not by ip link
# The ip command can create a persistent TUN device for testing
ip tuntap add dev tun0 mode tun
# Assign an IP address and bring it up
ip addr add 10.8.0.1/24 dev tun0
ip link set tun0 up
# Verify the device exists
ip addr show tun0
# Output: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
# inet 10.8.0.1/24 scope global tun0The POINTOPOINT flag in the output confirms that the interface is a point-to-point link, not a broadcast-capable Ethernet segment. There is no MAC address. The kernel routes packets to 10.8.0.0/24 through this interface, but the packets are delivered to the userspace program that holds the file descriptor, not to a physical wire.
A program using a TUN device reads raw IP packets from the file descriptor. For example, a simple VPN program might read a packet, encrypt it, send it over a UDP socket to the remote peer, receive the encrypted response, decrypt it, and write the plaintext IP packet back to the file descriptor. The kernel sees the decrypted packet as arriving on tun0 and routes it according to the routing table.
b. TAP devices — Layer 2 Ethernet interface
A TAP device carries Ethernet frames. It is used by virtual machines, container runtimes, and any application that needs to see the full Ethernet frame. The device has a MAC address and can be added to a bridge, where it participates in Layer 2 forwarding alongside physical interfaces.
# Create a TAP device named tap0
ip tuntap add dev tap0 mode tap
# Bring it up
ip link set tap0 up
# Verify the device
ip addr show tap0
# Output includes: link/ether 5a:3c:... brd ff:ff:ff:ff:ff:ff
# The presence of a MAC address distinguishes TAP from TUN
# Attach the TAP device to a bridge
ip link set tap0 master br0The link/ether line confirms that the interface has a MAC address, which is what makes it an Ethernet interface. The kernel handles the Ethernet header, and the userspace program that reads from the file descriptor receives the full frame, including the destination MAC, source MAC, and EtherType fields.
QEMU/KVM uses TAP devices to connect virtual machines to the host’s network. The TAP device is created on the host, attached to a bridge, and passed to the virtual machine as its network interface. The virtual machine sends Ethernet frames to the TAP device, and the host kernel forwards them to the bridge, which delivers them to the physical network or to other virtual machines .
c. Creating and managing TUN/TAP devices
The ip tuntap command creates TUN/TAP devices from the command line. This is useful for testing and for creating persistent devices that a userspace program can attach to later.
# Create a TUN device
ip tuntap add dev tun0 mode tun
# Create a TAP device
ip tuntap add dev tap0 mode tap
# Create a persistent device (survives program exit)
ip tuntap add dev tun0 mode tun persist
# Delete a device
ip tuntap del dev tun0 mode tun
# List all TUN/TAP devices
ip tuntap listThe persist flag keeps the device alive even when no userspace program holds it open. This is necessary when the device is created at boot and a program attaches to it later. Without persist, the device disappears as soon as the creating program exits.
The device node /dev/net/tun must exist for any of this to work. On most modern distributions, it is created automatically by udev. If it is missing, it can be created with mknod /dev/net/tun c 10 200 . The kernel module tun must also be loaded; it is usually autoloaded when the device node is opened, but modprobe tun ensures it is present.
Complete Example Session
# ============================================
# PART 1: ENSURE THE TUN MODULE IS LOADED
# ============================================
modprobe tun
lsmod | grep tun
# ============================================
# PART 2: CREATE A TUN DEVICE
# ============================================
ip tuntap add dev tun0 mode tun
ip addr add 10.8.0.1/24 dev tun0
ip link set tun0 up
ip addr show tun0
# Output confirms POINTOPOINT and the IP address
# ============================================
# PART 3: CREATE A TAP DEVICE
# ============================================
ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr show tap0
# Output confirms link/ether (MAC address)
# ============================================
# PART 4: ATTACH THE TAP DEVICE TO A BRIDGE
# ============================================
ip link add br0 type bridge
ip link set br0 up
ip link set tap0 master br0
ip link show master br0
# Output lists tap0 as a bridge port
# ============================================
# PART 5: VERIFY ROUTING FOR THE TUN DEVICE
# ============================================
ip route show | grep tun0
# Output: 10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
# ============================================
# PART 6: CREATE A PERSISTENT DEVICE
# ============================================
ip tuntap add dev tun1 mode tun persist
ip tuntap list
# Output includes tun1 even without a userspace program
# ============================================
# PART 7: DELETE THE DEVICES
# ============================================
ip tuntap del dev tun0 mode tun
ip tuntap del dev tap0 mode tap
ip tuntap del dev tun1 mode tun
ip link delete br0The seven parts demonstrate the complete lifecycle: module loading, TUN creation with IP addressing, TAP creation with MAC addressing, bridge attachment, routing verification, persistence, and cleanup. The critical distinction is visible in Parts 2 and 3: tun0 has no MAC address and is POINTOPOINT; tap0 has a MAC address and can be bridged.
Quick Reference
TUN vs TAP
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3 (IP packets) | Layer 2 (Ethernet frames) |
| MAC address | No | Yes |
| Point-to-point | Yes (POINTOPOINT) | No |
| Bridgeable | No | Yes |
| Typical use | VPN, IP tunneling | Virtual machines, container networking |
Commands
| Task | Command |
|---|---|
| Load module | modprobe tun |
| Create TUN | ip tuntap add dev tun0 mode tun |
| Create TAP | ip tuntap add dev tap0 mode tap |
| Create persistent | ip tuntap add dev tun0 mode tun persist |
| Delete | ip tuntap del dev tun0 mode tun |
| List devices | ip tuntap list |
| Device node | /dev/net/tun |
Kernel Flags
| Flag | Meaning |
|---|---|
IFF_TUN | TUN device (no Ethernet headers) |
IFF_TAP | TAP device (Ethernet frames) |
IFF_NO_PI | No packet information header |
IFF_MULTI_QUEUE | Multiple queues for parallel processing |
Best Practices
✅ Do This:
# Ensure the tun module is loaded
modprobe tun # ✅
# Use TUN for IP routing
ip tuntap add dev tun0 mode tun # ✅
# Use TAP for bridging and virtual machines
ip tuntap add dev tap0 mode tap # ✅
# Use persist when a program will attach later
ip tuntap add dev tun0 mode tun persist # ✅
# Attach TAP devices to a bridge
ip link set tap0 master br0 # ✅
# Verify the mode with ip addr show
ip addr show tun0 | grep POINTOPOINT # ✅❌ Don’t Do This:
# Try to bridge a TUN device
ip link set tun0 master br0 # TUN has no MAC address # ❌
# Expect a TUN/TAP device to persist without persist flag
# The device disappears when the program exits # ❌
# Forget to load the module on minimal systems
# /dev/net/tun may not exist or may fail to open # ❌
# Assign a MAC address to a TUN device
# TUN is point-to-point; MAC addresses are not used # ❌
# Use TAP for IP-only VPNs
# TAP adds Ethernet overhead that is unnecessary # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
/dev/net/tun not found | Module not loaded or node missing | modprobe tun; mknod /dev/net/tun c 10 200 |
| TUN device disappears | No persist flag and program exited | Use persist or keep program running |
| Cannot add TUN to bridge | TUN has no MAC address | Use TAP for bridging |
| TAP device has no traffic | Not attached to bridge or bridge is down | ip link set tap0 master br0; ip link set br0 up |
| VPN program cannot create device | Permission or capability missing | Run with CAP_NET_ADMIN or as root |
Real-World Examples
1. Create a TUN device
ip tuntap add dev tun0 mode tun2. Create a TAP device
ip tuntap add dev tap0 mode tap3. Persistent TUN device
ip tuntap add dev tun0 mode tun persist4. Assign IP to TUN
ip addr add 10.8.0.1/24 dev tun05. Attach TAP to bridge
ip link set tap0 master br06. List TUN/TAP devices
ip tuntap list7. Delete a device
ip tuntap del dev tun0 mode tun8. Load the module
modprobe tun9. Verify TUN is point-to-point
ip addr show tun0 | grep POINTOPOINT10. Verify TAP has MAC address
ip addr show tap0 | grep link/etherVisual
TUN Device (Layer 3)
┌──────────────────────────────────────────────────────────────┐
│ TUN: IP PACKETS BETWEEN KERNEL AND USERSPACE │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Userspace Program (e.g., VPN client) │ │
│ │ │ │
│ │ read(fd) ← raw IP packet │ │
│ │ write(fd) → raw IP packet │ │
│ └──────────────────────────┬─────────────────────────────┘ │
│ │ │
│ │ /dev/net/tun │
│ │ │
│ ┌──────────────────────────▼─────────────────────────────┐ │
│ │ Kernel Network Stack │ │
│ │ │ │
│ │ tun0: POINTOPOINT, no MAC, 10.8.0.1/24 │ │
│ │ Routes: 10.8.0.0/24 dev tun0 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ No Ethernet headers. IP packets only. │
│ Cannot be bridged. Used for VPNs and IP tunnels. │
└──────────────────────────────────────────────────────────────┘TAP Device (Layer 2)
┌──────────────────────────────────────────────────────────────┐
│ TAP: ETHERNET FRAMES BETWEEN KERNEL AND USERSPACE │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Userspace Program (e.g., QEMU/KVM) │ │
│ │ │ │
│ │ read(fd) ← Ethernet frame (with MAC headers) │ │
│ │ write(fd) → Ethernet frame │ │
│ └──────────────────────────┬─────────────────────────────┘ │
│ │ │
│ │ /dev/net/tun │
│ │ │
│ ┌──────────────────────────▼─────────────────────────────┐ │
│ │ Kernel Network Stack │ │
│ │ │ │
│ │ tap0: BROADCAST, link/ether 5a:3c:..., UP │ │
│ │ Can be attached to bridge br0 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Full Ethernet frames. Has MAC address. │
│ Bridgeable. Used for VMs and container networking. │
└──────────────────────────────────────────────────────────────┘TAP Attached to a Bridge
┌──────────────────────────────────────────────────────────────┐
│ TAP DEVICE AS A BRIDGE PORT │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ VM 1 │ │ VM 2 │ │ Physical │ │
│ │ (QEMU) │ │ (QEMU) │ │ Network │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ tap0 │ │ tap1 │ │ eth0 │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ br0 (bridge) │ │
│ │ (Layer 2 forwarding) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ VMs appear as physical hosts on the LAN. │
│ The TAP devices are the bridge ports. │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| TUN | Layer 3 virtual interface; IP packets |
| TAP | Layer 2 virtual interface; Ethernet frames |
| Device node | /dev/net/tun |
| Kernel module | tun |
| Creation (ip) | ip tuntap add dev <name> mode tun/tap |
| Persistence flag | persist |
| TUN use case | VPN, IP tunneling |
| TAP use case | Virtual machines, container networking, bridging |
| TUN bridgeable | No (no MAC address) |
| TAP bridgeable | Yes |
Key takeaways:
- TUN carries IP packets; TAP carries Ethernet frames. The choice depends on what the userspace program needs. VPNs that route IP traffic use TUN. Virtual machines and bridges that need MAC addresses use TAP .
- The device exists only while a program holds it open. Without the
persistflag, closing the file descriptor removes the interface and its routes. This is intentional: the device is a connection to a specific program. /dev/net/tunis the entry point. A program opens this device node and issues anioctl()withIFF_TUNorIFF_TAPto create the interface. Theip tuntapcommand performs the same operation from the command line for testing and persistence .- TUN is point-to-point and has no MAC address. It cannot be added to a bridge. TAP has a MAC address and can be bridged like any physical interface.
- TAP is the standard mechanism for VM networking. QEMU/KVM creates a TAP device on the host, attaches it to a bridge, and passes it to the VM. The VM’s traffic traverses the TAP device and the bridge to reach the physical network.
- The kernel module must be loaded. On most systems it autoloads when
/dev/net/tunis opened, but minimal systems may needmodprobe tunor manual creation of the device node.
Remember: TUN and TAP are the bridge between the kernel’s network stack and userspace programs. TUN is for IP packets, used by VPNs and tunnels. TAP is for Ethernet frames, used by virtual machines and bridges. Both are created through /dev/net/tun and exist only as long as a program holds them open. Use TUN when the program needs to route IP, use TAP when it needs to switch Ethernet, and use persist when the device must outlive the creating program.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!