dev tun on Windows still shows a TAP adapter. Is that wrong?
A TAP-Windows adapter under a dev tun profile is normal. The layer-3 driver is an opt-in switch, and the client log, not the adapter name, says which ran.
Device Manager shows a TAP-Windows Adapter V9 while the profile says dev tun, and the tunnel works. That combination is not a misconfiguration, and flipping the mode back and forth will not change it. The adapter name reflects which Windows driver the client loaded, not which packets the tunnel carries. Read the client log for the driver line before you edit anything.
Why a layer-3 tunnel gets an Ethernet adapter
For most of the client's Windows history, no usable layer-3 virtual adapter existed. The only option was the TAP-Windows driver, which presents an Ethernet interface. The client then emulated the missing layer-2 behaviour so that Windows could configure it. That emulation is why the adapter still looks like a network card.
Two pieces of that emulation are visible if you watch: the client answers ARP for the tunnel address, and it serves a small DHCP lease to the local machine. Windows therefore sees a normal Ethernet adapter with a MAC address and an NDIS driver, while the tunnel itself carries bare IP packets. The Ethernet costume belongs to the driver, not to the tunnel mode.
Find the driver line instead of judging by the name
Two adapters can share a name across driver versions, so the name alone cannot tell you what ran. The client log names the device it opened, and on newer builds it also names the driver it selected; that is the line to read.
Check three things in the log, in this order: whether the client opened any adapter at all, which driver it reports, and whether it fell back after a failure. A fallback line is easy to miss because the connection still comes up, and the tunnel then runs on the older driver while the user believes the new one is active.
Switch to the layer-3 driver, and check what has to be present
The layer-3 driver shipped by the WireGuard project is available from client version 2.5 onward, but it is opt-in. Adding one directive selects it:
windows-driver wintunThe driver has to be installed on the machine, and official builds carry a signed copy. Ship that signed release if you package the client yourself, because a privately built driver collides with the copies that other VPN products install. Those collisions produce failures that are slow to attribute, and they usually appear after a second VPN client arrives on the machine. A missing driver, by contrast, leaves a clear line in the log.
The driver also enforces stricter permissions, so the client creates the adapter through its interactive service running as a privileged account. Start the client as a plain user process without that service and the directive can fail, which leaves the previously installed adapter visible and looks like the switch was ignored.
When TAP remains the right answer
If the tunnel must carry Ethernet frames, broadcast traffic or non-IP protocols, a layer-2 adapter is required and the TAP driver follows from that requirement. A bridged design on Windows has the same constraint, since the interface has to join a layer-2 domain.
Performance is not a reason to pick one over the other at the adapter-name level. Version 2.6 adds a data-channel offload driver that moves packet processing into the kernel, and that is the option that changes throughput characteristics. It is a capability decision rather than a requirement for connecting, and it depends on the build and the installed package. A profile that works without it keeps working.
| What the tunnel must carry | Adapter family | Where it is selected |
|---|---|---|
| IPv4 and IPv6 packets | Layer-3 driver, or the older TAP emulation | Client directive plus installed signed driver |
| Ethernet frames, non-IP protocols | TAP-Windows | Profile mode and the TAP driver package |
| Higher throughput on a supported build | Data-channel offload driver | Client build and driver package, separately from the profile |
Clean up after the switch
Removing the old adapter matters as much as adding the new one. A leftover TAP interface can keep an address and a route from an earlier session, and those entries outlive the connection that created them. Delete the stale device in Device Manager, then reconnect and confirm the routing table no longer mentions it.
If several VPN products are installed, note which driver package each one bundles before you debug the profile. Two clients installing different builds of the same driver is a conflict that no amount of profile editing will resolve. Uninstall the unused client and reboot, then look for duplicated adapters in Device Manager. Only after that is it worth comparing log lines between the two products.