In the previous post, I talked about OpenVPN TCP and UDP tunnels and why you should not be using TCP. In this post, I’m going to talk about optimizing the said tunnels to get the most out of them.
Believe it or not, the default OpenVPN configuration is likely not optimized for your link. It probably works but its throughput could possibly be improved if you take the time to optimize it.
A tunnel has 2 ends! Optimizing one end, does not necessarily optimizes the other. For the proper optimization of the link, both ends of the tunnel should be in your control. That means when you are using OpenVPN in server mode serving different clients that you do not have control over, the best you could do is to optimize your own end of the tunnel and use appropriate default settings suitable for the most clients.
Below are some techniques that could be used to optimize your OpenVPN tunnels.
In today’s world where most connections are either encrypted or pre-compressed (and more commonly both), you probably should think twice before setting up compression on top of your vpn tunnel.
While it still could be an effective way Continue reading
Spoiler alert: You most likely would want to use UDP tunneling!
An OpenVPN tunnel runs over IP and can encapsulates VPN traffic into either a UDP or a TCP connection. To understand the pros and cons of each, we first need to have an understanding of them both.
Transmission Control Protocol is the dominant protocol there is for most daily stuff happening on a network. It has some very interesting features built-in which makes it very resistant to network packet loss, packet reordering, packet duplication, unintentional packet corruption and even link congestion. Despite it being not perfect1, it’s survived the test of time and it’s not going anywhere in near future.
All those features however come at a price. A typical TCP packet has a header size of 20 bytes. Assuming you’re using IPv4, You also get a 20 bytes IP header added on top of it. So at least 40 bytes in each TCP packet is the header data that comes before the actual payload.
Unlike TCP, User Datagram Protocol does not come with much features. It comes with a checksum header for packet integrity but connection reliably as a whole is not guaranteed. In Continue reading
Green as it’s cool, green as it’s quite, just like the trees. You’d think it’s all good and perfect. It’s also supposed to consume way less power. Yay, greener planet… Except…
When i started buying them in bulk, 500GB was a lot and a 32MB cache size seemed to be preferable to 16MB which the blue caviar offered at the time. From time to time when i was in hurry and couldn’t find a WD Green HDD, I’d settle with Blue. After couple of months a pattern started to emerge. Clients after clients started complaining about low performance. Their PCs would freeze. Sometimes as long as couple of minutes and then it would continue working again like nothing had happened. At the time I couldn’t quite figure out why after couple of months of usage, WD Green HDDs would start acting up like that.
The strange thing was that nothing was reported anywhere. Not a single suspicious system log or the so called SMART log. Even on couple of clients using Intel Raid, the “Intel RAID Chipset” seemed to be very happy with minutes of interrupts caused by the HDDs. And in a single case, one HDD suddenly died. Out Continue reading