Further to the Multithreaded TCP Tunnel Proxy that I wrote a while ago, I’ve picked up a low end UK VPS and installed OpenVPN on it, as well as my local machine. I set up the iproute2 split access load balancer and established the OpenVPN connection.
Now, each of the two DSL lines is established at 17mbit giving me a theoretical maximum of 2.125MB/sec. In actual fact to kernel.org I can get a steady 1.7-1.8MB/sec which is more than enough. From my 100mbit UK VPS, I can get 8-9MB/sec from kernel.org without issue. Establishing OpenVPN over a single connection and then pulling a file from kernel.org leaves me with only 1.3MB/sec which I’m not best pleased about. Pulling the file through a proxy running on the UK VPS downloads at 1.6MB/sec minimum, so it isn’t my new route that’s causing the slow down, it’s OpenVPN. Either way, I didn’t bother testing for any improvement with pptpd because I need OpenVPN’s single TCP connection anyway for this experiment to work.
The positive outcome of the story, is that with iproute2 load balancing set up, and OpenVPN established through the multithreaded TCP proxy over both connections, and using -t4. My single 1.3MB/sec became 2.2MB/sec which is IMHO an incredibly successful outcome.
A problem to note, is that on more than one occasion, netstat/lsof showed 3 TCP connections established over one DSL, and 1 over the other DSL. I just restarted my tcp tunnel a few times until I had them equally balanced. If this was a big enough problem -t6, -t8 or -t10 might have showed interesting results, but the more threads the more delay and potential issue with misordered packets. -t4 with iptables forcing the TCP connections equally over the DSLs might also be worth investigating. Nevertheless, as the experiment goes, a pleasing outcome!
Tags: dsl, iproute2, load balancer, multithreaded tcp tunnel, openvpn, proxy, split access, tcp, tcp tunnel, vps