Openvpn tcp or udp (specific situation, reliability-layer collisions)

openvpntcpudp

My question is whether to use TCP of UDP for my OpenVPN connection.
I've set up a simple network for a startup company that allows users from the outside to access the network via an OpenVPN server (in routing mode). The only thing users will do with the vpn is accessing files.

The priority is to keep the integrity of the files intact. With that in mind, should I use the UDP of TCP protocol for my vpn tunnel? I've read up on reliability-layer collisions (i.e. on http://openvpn.net/index.php/open-source/documentation/security-overview.html), but since tcp, the openvpn transport layer and the tunneled TCP session can all provide the reliability checks for me, so it leaves me wondering what would work best for me.

So, should I use TCP or UDP in this situation?

Best Answer

UDP. Always UDP for tunneled connections if you can swing it from a network/firewall perspective. The underlying TCP flows will take care of retries if necessary. If you used TCP at the OpenVPN layer, you end up in a situation where both layers can send duplicate packets in the case of loss. This can cause significant performance problems.

Related Solutions

OpenVPN Performance – How Many Concurrent Clients Are Possible?

I doubt that a setup that large has ever been attempted before, so you likely will be pushing limits when trying. I could find an article on a VPN deployment for 400 clients but judging from the text, the author just relied on rough estimates about how many clients could be run per CPU and lacked some understanding about how his setup would perform.

You would mainly need to consider these two points:

The bandwidth your data transfers are going to use would need encryption / decryption at the VPN server side, consuming CPU resources
OpenVPN client connections consume both, memory and CPU resources on the server even when no data is transferred

Any decent PC hardware available today should easily saturate a Gigabit link with Blowfish or AES-128, even $100 embedded devices are capable of rates near 100 Mbps, so CPU bottlenecks due to bandwidth intensity should not be of any concern.

Given the default rekeying interval of 3600 seconds, a number of 1,000,000 clients would mean that the server would need to be able to complete 278 key exchanges per second on average. While a key exchange is a rather CPU-intensive task, you could offload it to dedicated hardware if needed - cryptographic accelerator cards available easily meet and exceed this number of TLS handshakes. And memory restrictions should not bother too much as well - a 64-bit binary should take care of any virtual memory restrictions you would be likely to hit otherwise.

But the real beauty with OpenVPN is that you can scale it out quite easily - simply set up an arbitrary number of OpenVPN servers and make sure your clients are using them (e.g. through DNS round-robin), configure a dynamic routing protocol of your choice (typically this would be RIP due to its simplicity) and your infrastructure would be capable of supporting an arbitrary number of clients as long as you've got enough hardware.

Openvpn – How to prevent TCP connection freezes over an OpenVPN network

This command solves it for me:

$ sudo ip link set dev tun0 mtu 1350 && echo ":)"

You can Verify tun0 settings with

$ ip a s

Cheers!

Best Answer

Related Solutions

OpenVPN Performance – How Many Concurrent Clients Are Possible?

Openvpn – How to prevent TCP connection freezes over an OpenVPN network

Related Topic