I am looking for a way to get a fast OpenVPN connection out through a restrictive firewall (this is not a workplace and I am not breaking any code of conduct).

Currently I'm using port 443 direct to the openvpn server, as the firewall allows arbitrary TCP on this port. No ports besides 80 and 443 are open (TCP only) and DNS is internal. However, port 443 has a speed limit of 15mbit/s applied, and is extremely unreliable (openvpn link will fail completely every few minutes).

I've thoroughly tested and come to the conclusion that port 80 will only allow traditional HTTP requests - anything involving CONNECT or Transfer-Encoding: Chunked will be silently dropped.

The ping is low enough (5-10ms) and speed high enough (70mbit down, 15mbit up) that I'm genuinely ready to consider a HTTP polling tunnel (or some wizardry that sets a massive content-length and fires down loads of dummy data), but the problem is that I can't find one. Does any solution for this exist already?

I've tried the generally recommended http://sourceforge.net/projects/http-tunnel/, but no joy as it requires chunked encoding.

Edit: Found a semi-solution - http://www.targeted.org/htthost/. Works but unfortunately too slow in terms of latency to really do much with. Interestingly before I put it behind nginx, by opening its internal URLs I was able to see the default page of the transparent proxy I'm behind (wampserver apache apparently).

  • 1
    ssh may forward http traffic and act as a SOCKS proxy (see -D option). Is that feasible?
    – fuero
    Feb 14, 2013 at 17:48

1 Answer 1


Are you having the problem mentioned in this article from Olaf Titz?


Citing (since I could not say it any clearer). Note that the upper and the lower layer TCP have different timers. When an upper layer connection starts fast, its timers are fast too. Now it can happen that the lower connection has slower timers, perhaps as a leftover from a period with a slow or unreliable base connection.

Imagine what happens when, in this situation, the base connection starts losing packets. The lower layer TCP queues up a re-transmission and increases its timeouts. Since the connection is blocked for this amount of time, the upper layer (i.e. payload) TCP won't get a timely ACK, and will also queue a re-transmission. Because the timeout is still less than the lower layer timeout, the upper layer will queue up more re-transmissions faster than the lower layer can process them. This makes the upper layer connection stall very quickly and every re-transmission just adds to the problem - an internal meltdown effect.

TCPs reliability provisions backfire here. The upper layer re-transmissions are completely unnecessary, since the carrier guarantees delivery - but the upper layer TCP can't know this, because TCP always assumes an unreliable carrier."

Maybe this the discussion in this thread (http://news.ycombinator.com/item?id=2409090) will get you some pointers that will help.

Not the answer you're looking for? Browse other questions tagged .