Should I use tap or tun for openvpn?

Question

What are the differences between using dev tap and dev tun for openvpn? I know the different modes cannot inter-operate. What is the technical differences, other then just layer 2 vs 3 operation. Are there different performance characteristics, or different levels of overhead. Which mode is better. What functionality is exclusively available in each mode.

Answer 1

if it's ok to create vpn on layer 3 (one more hop between subnets) - go for tun.

if you need to bridge two ethernet segments in two different locations - then use tap. in such setup you can have computers in the same ip subnet (eg 10.0.0.0/24) on both ends of vpn, and they'll be able to 'talk' to each other directly without any changes in their routing tables. vpn will act like ethernet switch. this might sound cool and is useful in some cases but i would advice not to go for it unless you really need it. if you choose such layer 2 bridging setup - there will be a bit of 'garbage' (that is broadcast packets) going across your vpn.

using tap you'll have slightly more overhead - besides ip headers also 38B or more of ethernet headers are going to be sent via the tunnel (depending on the type of your traffic - it'll possibly introduce more fragmentation).

Answer 2

I chose "tap" when setting up a VPN for a friend who owned a small business because his office uses a tangle of Windows machines, commercial printers, and a Samba file server. Some of them use pure TCP/IP, some seem to only use NetBIOS (and thus need Ethernet broadcast packets) to communicate, and some I'm not even sure of.

If I had chosen "tun", I would probably have faced lots of broken services — lots of things that worked while you are in the office physically, but then would break when you went off-site and your laptop couldn't "see" the devices on the Ethernet subnet anymore.

But by choosing "tap", I tell the VPN to make remote machines feel exactly like they're on the LAN, with broadcast Ethernet packets and raw Ethernet protocols available for communicating with printers and file servers and for powering their Network Neighborhood display. It works great, and I never get reports of things that don't work offsite!

Answer 3

I always set up tun. Tap is used by ethernet bridging in OpenVPN and introduces an unprecendented level of complexity that is simply not worth bothering with. Usually when a VPN needs to be installed, its needed now, and complex deployments don't come fast.

The OpenVPN FAQ and the Ethernet Bridging HOWTO are excellent resources on this topic.

Answer 4

Because I find simple advice hard to come by:

You can use TUN if you just use the VPN to connect to the internet.

You need to use TAP if you want to connect to the actual remote network (printers, remote desktops, etc.)

Answer 5

If you plan to connect mobile ( iOS or Android ) devices using OpenVPN, then you should use TUN as currently TAP is not supported by OpenVPN on them:

TAP drawbacks: ..... can not be used with Android or iOS devices

Answer 6

I started out using tun, but switched to tap since I didn't like the use of a /30 subnet for each PC (I need to support Windows). I found that to be wasteful and confusing.

Then I discovered the "topology subnet" option on the server. Works with the 2.1 RCs (not 2.0), but it gives me all the advantages of tun (no bridging, performance, routing, etc) with the convenience of one (sequential) IP address per (windows) machine.

Answer 7

My "rules of thumb"
TUN - if you ONLY need access to resources connected directly to the OpenVPN server machine at the other end, and there are no Windows issues. A little creativity here can help, by making resources "appear" to be local to the OpenVPN server. (examples might be a CUPS connection to a network printer, or a Samba share on another machine MOUNTed on the OpenVPN server.)

TAP - if you need access to multiple resources (machines, storage, printers, devices) connected via the network at the other end. TAP may also be required for certain Windows applications.

---

Advantages:
TUN normally confines VPN access to a single machine (IP address) and therefore (presumably) better security through limited connectivity to the far-side network. TUN connection will create less load on the VPN tunnel, and in turn the far-side network because only traffic to/from the single IP address will cross the VPN to the other side. IP Routes to other stations in the subnet are not included, so traffic is not sent across the VPN tunnel and little or no communication is possible beyond the OpenVPN server.

TAP - usually allows packets to flow freely between the endpoints. This gives the flexibility of communication with other stations on the far-side network, including some methods used by older Microsoft software. TAP has the inherent security exposures involved with granting outside access "behind the firewall". It will allow more traffic packets to flow through the VPN tunnel. This also opens the possibility of address conflicts between the endpoints.

There are differences in latency because of the stack layer, but in most end-user scenarios the connection speed of the endpoints is probably a more significant contributor to latency than the particular stack layer of the transmission. If latency is at issue, it might be a good idea to consider other alternatives. Current GHz-level multiprocessors normally outrun the bottleneck of transmission via the internet.

---

"Better" and "Worse" are not definable without a context.
(This is the consultant's favorite answer, "Well that depends...")
Is a Ferrari "better" than a dump truck? If you are trying to go fast, it may be; but if you're trying to haul heavy loads, probably not.

Constraints like "need for access" and "security requirements" must be defined, as well as defining constraints like network throughput and equipment limitations, before one can decide whether TUN or TAP is better-suited to your needs.

Answer 8

Setting up TAP requires almost no additional work from the person setting it up.

Of course if you know how to setup TUN but don't understand what you're doing and simply following a tun tutorial, you will be fighting to setup TAP but not because it's more difficult but because you don't know what you're doing. Which easily can lead to network conflicts in a TAP environment and then it looks like it's more complicated.

fact is, if you don't need a tutorial because you know what you're doing, setting up tap takes as much time as setting up tun.

with tap there are many solutions about subnetting, i found myself the easiest way is to use a class B subnet. site1 (Network1) using 172.22.1.0/16 site2(network2) using 172.22.2.0/16 site3 using 172.22.3.0/16 etc.

you setup site1 with the oVPN server and to give clients the ip range 172.22.254.2 - 172.22.254.255/16 so you can have over 200 ovpn clients (subnets) each subnet can have over 200 clients in itself. Makes a total of 40.000 clients you can handle (doubt oVPN can handle that but as you see, setting up proper subnetting will give you more then enough as you most likely ever need)

you use a tap and all clients are together as in a huge corporate network.

IF, however each site has it's own DHCP, and it should have, you need to make sure using ebtables or iptables or dnsmasq to block dhcp distribution to go wild. ebtables however will slow down the performance. using dnsmasq dhcp-host=20:a9:9b:22:33:44,ignore for example will be a huge task to setup on all dhcp servers. however, on modern hardware the impact of ebtables isn't that big. only 1 or 2 %

the overhead of the tap, roughly 32 to the tun, isn't that much a problem either (might be on unencrypted networks) but on encrypted networks it's usually the AES that will cause the slowdown.

On my wrt3200acm for instance unencrypted I get 360Mbps. Using encryption it goes down to 54-100Mbps depending on what kind of encryption I choose) but openvpn doesn't do encryption on 1500 and a 2nd encryption on the 32 overhead. Instead it does a 1 time encryption on 1500+32overhead.

So the impact here is minimal.

On older hardware you might notice the impact more, but on modern hardware it's really down to the minimum.

Encryption between 2 virtual machines with AES support gets me my ovpn with TAP to 120-150Mbps.

Some report dedicated routers WITH AES hardware encryption support getting as high as 400Mbps! 3 times faster then a i5-3570k can do (which on my test system couldn't get higher then 150Mbps at 100% of 1 core utilization) My other end: E3-1231 v3, then was roughly at 7% CPU utilization, around 25% of the core openvpn was using was utilized. So the E3 most likely could increase the connection by 3 to 4 times.

so you'd have something between 360Mbps and 600Mbps with a connection between E3-1231 v3 cpu doing tap AES265 cipher, auth SHA256 and ta.key, certificates tls-cipher I also used the highest TLS-DHE-RSA-WITH-AES-256-SHA256

To point this out, with tap: wrt3200acm gets up to 70-80mbps with encryption. i5-3570k gets to 120-150 with encryption. E3-1231 v3 gets at least 360Mbps with encryption (this is interpolated from my findings with case 1 and 2 because I didn't have 2 E3-1231 v3 to test with.)

These are my findings based on windows to windows copying between 2 clients in 2 different subnets connected by openvpn TAP

Answer 9

I had this same question years ago and attempted to explain it in straightforward terms (which I personally found lacking in other resources) on my blog: An OpenVPN Primer

Hope it helps someone

Answer 10

I usually default to TUN as having it in it's own subnet is better for a variety of reasons, among which firewalling, and OpenVPN basicly works out of the box like this.

TAP has several advantages though, among which is that connected clients behave exactly like physical ones. This means that for example any ip restricted resources that are normally only available in the physical network also work.

Another use case I see in home situations is that the OpenVPN server has no internet facing side and thusly routes through some sort of provider supported modem/router. More often then not these don't support things like static routing which is a must if you let OpenVPN use it's own subnet.

Answer 11

If then, why what, how much have you got? I would utilize TAP, explicitly for the reason that the layering of the packets proceeds with much less latency and loss of transmission which is abated with this method. However only with layer 3 does this affect any apparent effect on the operation of the VPN, notably the tunneling aspect and which IPs are allowed through and assignable addresses. The use of UDP possibly introduces another situation where you would need to decide which is the best route to take for you. Each network is different and requires a unique set of parameters. Hope this helps.