13 min readUpdated

TUN vs TAP in VPN: Virtual Adapters Explained (2026)

LiMP VPN Editorial TeamLiMP VPN Editorial TeamBlog & news editorial team
TUN vs TAP in VPN: Virtual Adapters Explained (2026)

Below you will find a plain-language explanation, a comparison table, where these adapters live in Windows, Linux, Android and virtual machines, how to tell which adapter your VPN uses, and how to fix common TAP driver errors. If you want a ready-made VPN where the adapter, protocol and MTU are already configured, see LiMP VPN features and pricing: apps are available for Android, Windows and the Chrome browser.

What are TUN and TAP in a VPN, in simple terms

TUN and TAP are virtual network adapters that a VPN client creates on top of a physical interface (the Wi-Fi module or Ethernet port). The operating system treats them like ordinary network cards: it assigns them an address, builds routes through them and sends traffic into them. No such hardware exists — these are software interfaces that intercept packets and hand them to the VPN process for encryption, and in the other direction take decrypted data and feed it back into the network stack.

The names speak for themselves: TUN comes from tunnel, TAP from network tap. In the Linux kernel both modes are implemented by a single driver: a program opens the /dev/net/tun device and passes the IFF_TUN or IFF_TAP flag when creating the interface. The only difference is what the program receives from the interface: bare IP packets or full Ethernet frames with MAC addresses.

An analogy: think of the network as a highway. The VPN client sets up a checkpoint at the exit (TUN or TAP) that all traffic passes before entering the protected tunnel. TUN lets through only cars with a clear destination address (IP packets). TAP lets through all traffic, including trucks with unusual cargo and messages addressed to everyone in earshot (broadcast frames).

How TUN differs from TAP: layer 3 vs layer 2

The key difference is the OSI layer: TUN works at layer 3 (network, IP), TAP at layer 2 (data link, Ethernet). Everything else follows from that: what passes through the tunnel, how addressing works and how much overhead is added to each packet.

ParameterTUNTAP
OSI layer3 (network, IP)2 (data link, Ethernet)
Unit of dataIP packet (IPv4/IPv6)Ethernet frame with MAC addresses
Interface typePoint-to-point, no MAC addressVirtual network card with its own MAC
How networks are joinedRouting (separate subnets)Bridging (one shared subnet)
Broadcast, ARP, DHCP broadcastNot carriedCarried
Non-IP protocolsNot carriedCarried
OverheadLowerHigher: +14-byte Ethernet header per frame plus extra broadcast traffic
Android, iPhoneSupported by the OSNot available
WireGuardYes (the only mode)No
Typical useRegular VPN, remote access, mobile clients, routed site-to-site linksLAN-to-LAN bridge, legacy network apps, old LAN games

Why TAP can bridge and TUN cannot

TAP supports network bridging because it sees Ethernet frames — the same ones that travel on a physical local network. A virtual TAP interface can be added to a Linux or Windows bridge together with a physical port, and two geographically separate LAN segments start behaving like one network: ARP requests, DHCP broadcasts and device discovery protocols pass through the tunnel, and remote computers get addresses from the same subnet as local ones.

TUN cannot do this: it handles IP packets only. Broadcast frames, ARP and non-IP traffic never enter a TUN tunnel. To join networks over TUN, you give them different subnets and add routes (static or via a dynamic routing protocol). That requires address planning, but the result is predictable: broadcast noise from one office does not leak into the other.

Routing or bridging: which to choose for linking two offices

For most tasks, routing over TUN is easier to maintain. A TAP bridge is justified when applications genuinely rely on broadcasts and cannot work with a server address directly.

  • Routing (TUN): each office has its own subnet, for example 192.168.1.0/24 and 192.168.2.0/24; traffic between them follows routes; broadcast traffic stays inside each office; access is easier to filter with firewall rules.
  • Bridging (TAP): one subnet for both offices; printer and network share discovery via broadcast works; but all segment noise goes into the tunnel, and a DHCP misconfiguration can hand out addresses to the wrong devices.

Which adapter WireGuard, OpenVPN and other protocols use

WireGuard uses TUN exclusively — this is a design decision of the protocol, not a user setting. OpenVPN supports both modes, but TUN is the default and is recommended in every case except bridging.

WireGuard works only at layer 3 on every platform. On Linux the wg0 interface is created by a kernel module (built in since 5.6). On Windows the official client uses Wintun, a high-performance TUN driver from the WireGuard developers. On macOS and iOS it uses the system utun mechanism, on Android the system VPN interface.

OpenVPN lets you choose the mode with dev tun or dev tap in the configuration. The mode must match on server and client: if the server runs TAP and the client TUN, the connection will not come up. TUN suits remote access and routed site-to-site links, TAP suits bridging.

IKEv2/IPsec and L2TP/IPsec create their own virtual interface or work inside the OS network stack. There is no TUN/TAP choice here — the tunnel type is defined by the protocol itself.

What DCO changes in OpenVPN 2.6 and later

OpenVPN 2.6 introduced DCO (Data Channel Offload): encryption and packet forwarding move from the user-space process into the ovpn-dco kernel driver, which lowers CPU load and raises throughput. According to the OpenVPN 2.6 manual, three drivers are available on Windows — ovpn-dco (the default), tap-windows6 and wintun — and ovpn-dco and wintun require dev tun. DCO also requires AEAD ciphers (AES-GCM or ChaCha20-Poly1305). The practical takeaway: a dev tap configuration loses the fastest mode and stays on the classic TAP-Windows driver.

When you need TAP and when TUN

TUN is the right choice almost always: privacy, protection on public Wi-Fi, remote access to work resources, mobile apps and anything on WireGuard. TAP is a specialist tool for specific networking tasks.

Choose TUN when:

  • you need privacy and traffic protection — any consumer VPN scenario;
  • you need remote access to corporate servers, web apps or APIs;
  • you use WireGuard — it supports TUN only;
  • clients are Android phones or iPhones: TAP is not available on them;
  • speed matters and you want DCO in OpenVPN 2.6+.

Choose TAP only when:

  • you need to merge two LAN segments into one Ethernet domain (a bridge between offices);
  • applications rely on broadcast requests (DHCP broadcast, NetBIOS, device discovery);
  • old network games require players to be on the same local network;
  • you use legacy non-IP layer 2 protocols.

Quick decision guide

  1. Using a ready-made VPN app? There is nothing to choose — the app already uses TUN.
  2. Setting up your own server for resource access or traffic protection? Use dev tun or WireGuard.
  3. Are some clients phones? TUN only.
  4. Does an application in the remote office fail without broadcasts, and it cannot be changed? Then TAP and a bridge — with filtering of unnecessary traffic.

TUN and TAP on Windows, macOS, Linux and phones

The TUN/TAP implementation differs per platform, but the idea is the same: the VPN client registers a virtual network interface through which the OS sends traffic into the encrypted tunnel.

Windows: historically OpenVPN used the TAP-Windows Adapter V9, an NDIS driver for a layer 2 virtual network card. Current OpenVPN versions also support Wintun and ovpn-dco, and the official WireGuard client uses Wintun. To see your adapters: Win + R → ncpa.cpl; look for «TAP-Windows Adapter V9», «Wintun» or the name of a WireGuard tunnel.

macOS: uses the built-in utun mechanism, a system TUN interface. Most VPN clients work through it without separate drivers.

Linux: TUN/TAP is implemented in the kernel via /dev/net/tun. The VPN process opens this device and creates a tunN or tapN interface. WireGuard on Linux 5.6+ is built into the kernel and creates the wg0 interface directly.

Android and iPhone: mobile operating systems give VPN apps a system API. On Android it is the VpnService class: the app describes addresses and routes and receives a TUN interface descriptor from the system, through which it reads and writes IP packets. Installing a TAP driver on a smartphone is impossible — the OS does not grant that level of kernel access. How to turn on a VPN on your phone is covered in our guide how to set up a VPN on Android.

Wintun vs the classic TAP-Windows Adapter V9

Wintun beats TAP-Windows Adapter V9 on performance and simplicity. TAP-Windows V9 is a mature layer 2 driver that has been around for many years; it works, but installing it sometimes needs manual confirmation in a Windows security dialog, and with several VPN clients on one PC the adapters start to conflict.

Wintun is a minimalist kernel-level TUN driver from the WireGuard team. It is used by the official WireGuard client for Windows and supported by OpenVPN. Its advantages: higher throughput thanks to fewer switches between the kernel and the user process, interfaces created dynamically on connect, and a compact codebase. Limitations per the OpenVPN manual: Wintun works only with dev tun and requires OpenVPN to run elevated or via the Interactive Service. You can pick the driver manually with the line windows-driver wintun in the .ovpn file.

Where else TUN and TAP appear: virtual machines and containers

TUN and TAP are not only about VPNs. Virtualization systems and network utilities use the same interfaces, so adapters with these names can show up on a computer even without a VPN client.

  • Virtual machines (KVM/QEMU): the guest network card is often attached to the host through a TAP interface added to a bridge. This way the VM gets an address on the same local network as the host.
  • Network utilities and proxy clients: many programs bring up a TUN interface to capture traffic from all applications, not just the browser.
  • Containers: Docker uses veth pairs and a bridge by default, not TUN/TAP; a container is given access to /dev/net/tun explicitly when a VPN client must run inside it.

On Linux you can create an interface manually with ip tuntap add dev tun0 mode tun (for TAP, mode tap) and list them with ip tuntap show. Administrators need this for debugging; for a regular user, the VPN app does it all automatically.

How to tell which adapter your VPN uses

You can check the adapter type in a minute with built-in system tools, without installing anything.

  • Windows: connect the VPN, open Command Prompt and run ipconfig /all. The «Description» field of the VPN adapter names the driver: «TAP-Windows Adapter V9» means TAP, Wintun or WireGuard Tunnel means TUN.
  • Linux: ip -d link show lists tunN, tapN or wg0 interfaces; the detailed output shows the type — tun, tap or wireguard.
  • macOS: ifconfig shows utunN interfaces — these are TUN.
  • Android: the key icon in the status bar means the system has brought up a VPN interface; it is always TUN.

To make sure traffic really goes through the tunnel, open the What is my IP page: with the VPN on, it should show the VPN server address, not your ISP's.

Does the adapter choice affect speed and security

The adapter type does not affect encryption strength — protection comes from the protocol and cipher, not the virtual interface. It does affect throughput and latency: TUN is faster than TAP in most scenarios.

Why TUN is faster:

  • No extra header: TAP adds an Ethernet header (14 bytes) to each frame and passes broadcast traffic that a regular VPN does not need;
  • Less fragmentation: the more overhead bytes, the smaller the usable tunnel MTU and the more often packets must be split and reassembled;
  • Fast drivers: Wintun and ovpn-dco work only in TUN mode, and they deliver most of the speed gains in modern clients.

On home connections the difference is usually unnoticeable; on gigabit and corporate links it is more pronounced. If sites load slowly or downloads stall after connecting, the cause is more often a wrong MTU than the adapter type. For latency, see our article what is ping in a VPN.

A TAP bridge also has a security nuance: since broadcast frames cross the tunnel, remote devices end up in the same segment as local ones and can see them through network discovery. That is why an office bridge is set up together with filtering rules, not as is.

How to fix common TAP adapter errors on Windows

The two most common TAP errors on Windows are «All TAP-Windows adapters on this system are currently in use» and a TAP driver installation failure during OpenVPN setup. Both are usually fixed in five steps.

Step 1. Diagnose. Close the VPN client and open Network Connections with ncpa.cpl (Win + R). Check how many TAP-Windows Adapter V9 entries are listed and whether the one you need is disabled (a grey icon — enable it from the context menu).

Step 2. «All TAP adapters are in use». This error means every TAP adapter is taken by other connections — for example, a second VPN client is running. Close the extra clients or add another adapter with the OpenVPN utility («Add a new TAP virtual ethernet adapter»); you can remove extra adapters in Device Manager under Network adapters.

Step 3. Driver installation error. Run the OpenVPN installer as administrator (right-click → Run as administrator) and allow the driver installation in the Windows security dialog. If antivirus software blocks the installation, temporarily add the installer to its exclusions.

Step 4. Switch to a TUN driver. If the server runs dev tun, current OpenVPN versions let you drop TAP altogether: the line windows-driver wintun in the .ovpn file enables Wintun (administrator rights required), and OpenVPN 2.6 uses ovpn-dco by default.

Step 5. Restart the PC and reconnect. A restart ends stuck processes that hold on to the adapter.

Common mistakes when setting up TUN and TAP

  • Different modes on server and client. dev tun on one side and dev tap on the other — the tunnel will not come up or traffic will not flow. The mode must match.
  • TAP just in case. People pick a bridge to make sure everything works and end up with a slow tunnel, broadcast noise and no phone support.
  • Overlapping subnets. In TUN mode, the tunnel and office subnets must not match the user's home network (a frequent problem with 192.168.0.0/24 and 192.168.1.0/24).
  • Forgotten MTU. Sites load partially and large downloads hang — a sign that packets do not fit into the tunnel. The fix is tuning MTU/MSS, not changing the adapter.
  • Several VPN clients at once. They compete for adapters and routes; keep one active client. If the VPN stopped working on just one Wi-Fi network, check the tips in VPN not working over Wi-Fi.

Does a regular user need to choose between TUN and TAP?

No. In LiMP VPN, as in any modern VPN app, the adapter is chosen automatically: on Android the system creates a TUN interface itself, on Windows the app installs the right driver during setup. Choosing between TUN and TAP manually is only needed by people who run their own OpenVPN server and bridge local networks — that is a network administrator's job.

If you use a ready-made app, you do not need to think about adapters: the interface type, protocol and MTU are already configured. See what the app can do on the LiMP VPN features page, download it from apps, and compare plans on pricing.

Frequently asked questions

What is the difference between TUN and TAP?

TUN operates at OSI layer 3 and carries IP packets (routing, point-to-point). TAP operates at layer 2 and carries Ethernet frames, including non-IP traffic and broadcasts. TUN is for a regular VPN, TAP for a network bridge between local networks.

Which adapter is better, TUN or TAP?

For most tasks TUN: lower overhead, simpler routing, phone support and compatibility with the fast Wintun and ovpn-dco drivers. TAP is only needed to merge two LAN segments into one Ethernet domain or to carry non-IP traffic.

What is TAP-Windows Adapter V9?

OpenVPN's virtual network driver for Windows that creates a layer 2 Ethernet interface. It is installed with OpenVPN and appears in Network Connections. In current OpenVPN versions, Wintun or ovpn-dco can replace it in TUN mode.

Does WireGuard use TAP?

No. WireGuard works only at layer 3 through a TUN interface on every platform: Linux, Windows (Wintun), macOS, iOS and Android. There is no TAP mode in WireGuard.

Can I enable TAP on Android or iPhone?

No. Mobile operating systems give VPN apps only a system API that creates a TUN interface (VpnService on Android). A TAP driver cannot be installed on a smartphone, so a TAP bridge with a phone is not possible.

Can I remove a TAP adapter on Windows?

Yes, if it is not in use: remove it in Device Manager under Network adapters, or uninstall the VPN program that installed it. If an OpenVPN client needs the adapter, the connection will stop working until the driver is reinstalled.

Why is there a TUN/TAP adapter on my computer if I never installed a VPN?

Other programs create such adapters too: virtualization software (TAP for a virtual machine's network card), network utilities and proxy clients that capture traffic via TUN. Check the Description field in ipconfig /all output to see which driver created it.

Sources

  1. Linux kernel documentation: Universal TUN/TAP device driver
  2. OpenVPN 2.6 reference manual (dev tun/tap, windows-driver, DCO)
  3. Wintun: TUN driver for Windows from the WireGuard developers
  4. WireGuard: protocol description
  5. Android Developers: VpnService class

Author

LiMP VPN Editorial Team

Blog & news editorial team

The LiMP VPN editorial team publishes articles and news about VPNs, privacy and digital security: setting up a VPN on different devices, protocols and encryption, bypassing blocks, staying safe on public Wi-Fi and current threats. Every piece is reviewed by the LiMP VPN service team.

Editorial e-mail: content@limpvpn.com

Read also

Secure your connection in a minute

Download LiMP VPN for free and feel the difference within a minute.