Should I use tap or tun for openvpn?

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.

Solution 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).

Solution 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!