Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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, but no joy as it requires chunked encoding.

Edit: Found a semi-solution - 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).

share|improve this question

closed as not constructive by Michael Hampton, mgorven, mdpc, Khaled, RolandoMySQLDBA Mar 8 '13 at 2:38

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

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

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 ( will get you some pointers that will help.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.