I'm currently in the situation of attempting to setup OpenVPN on a personal VPS, for connection primarily through an overly restrictive firewall. All of the setups mentioned below work when used through a reasonably-firewalled connection.

I have tried:

  1. OpenVPN running on the standard port
  2. OpenVPN running on port 443 (I start OpenVPN manually from the command line on the VPS and see that the server reports the connection being closed almost immediately, I assume this is a result of DPI on the firewall)
  3. STunnel running on port 443 to access OpenVPN and evade DPI. This is the most successful and allows a connection and internet access through the VPN for ~10-20 seconds, before the connection is forcibly closed.

Is there anything else I can attempt?

  • 1
    Dear lord, what "personal VPS" provider do you have that goes to such lengths to prevent you from running a VPN?! Also, it isn't clear if you are trying to use the VPS as an OpenVPN server, or if you want to make it the client? Sep 25, 2012 at 20:42
  • Woops! I should have been more clear. The VPS provider is Linode, and they definitely aren't blocking anything. ;) The problem is that I'm connecting to the VPN from a client (my laptop) whose internet access is severely firewalled.
    – R.L. Stine
    Sep 25, 2012 at 20:52
  • 1
    A VPN solution in general is going to be fairly easily detected by anything that does stateful packet inspection, as you hinted. The forceful disconnection could be due to traffic analysis methods looking at the https connection of stunnel and going "wait a minute, standard HTTP request/response connections aren't nearly that chatty!" -- in essence you are stuck. You could try an HTTPS proxy though; maybe something where you pass the request as an HTTP body (over SSL) to a servlet and it forwards your request... o_O Sep 25, 2012 at 21:07
  • 3
    You may want to keep in mind that bypassing restrictions implemented by a company firewall are likely a violation of company policy. I suggest you talk to the firewall admin about the issue. Sep 25, 2012 at 22:57

5 Answers 5


Connections being cut off after a length of time sometimes indicate a bytes-per-second type of limit. Try seeing if slowing down your VPN connection works. Also if you have OpenVPN configured for UDP try TCP (443 UDP may be blocked whereas 443 TCP may go undetected).

Visit a well known site that uses SSL and check the certificate. Then do the same at home. If they don't match then your location is using a transparent HTTPS SSL proxy and can actually see your HTTPS traffic.

It's possible something that isn't port 443 isn't watched so closely. Try 22.

It may sound stupid but try doing it over port 80 and see what you get. You also may try setting up an HTTP tunnel between you and the VPS to make the traffic look like HTTP requests.

If you are feeling insane, try iodine.

  • 2
    +1, but especially for iodine! Mar 22, 2013 at 21:56

I think i know why the stunnel methode behaves like that. It's because you net to set an "static route" for stunnel server. Let me explain that. When you connect to an openvpn server it changes your routing table and route all your packets trough the vpn ,except the openvpn packets. actualy openvpn will add a route for your server ip address. But when you using stunnel to connect to your openvpn server you will connect openvpn to a loopback interface and there is no route to your server outside your vpn, so stunnel packets want to go to server and they going to your vpn and your vpn packets going to stunnel :)

So you need to add a route to your server ip that going outside your vpn (your home router).

And for problem with method port 443 i ganna say that maybe your the firewall using SPI or DPI and the can easily make diffrent openvpn packets from https (ssl) packets. So best way is to use stunnel, or if firewall blocks ssl packets it's better to use obfsproxy or fteproxy to bypass it.

(i know that post is to old but i was looking for answer about the same problem for weeks ,so i wanted to share what i learnd about this)

  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post.
    – Ramhound
    Sep 1, 2015 at 13:03

The reply by Reza Askari was exactly the answer to the third question. This has been happening on both my Linux computer and Android.

On computer, before you connect to OpenVPN through

sudo openvpn --config configFile.ovpn

You should add a rule to remove the stunnel server from the OpenVPN tunnel.

sudo /sbin/ip route add stunnel_ip via default_gateway_ip

Then connect to your OpenVPN server. When done you can remove that rule by:

sudo /sbin/ip route del stunnel_ip

To make things more easy so you would not forget, create a shell script that will add the rule and run the OpenVPN, when OpenVPN exits, the rule will be deleted:

sudo /sbin/ip route add stunnel_ip via default_gateway_ip

sudo openvpn --config configFile.ovpn

sudo /sbin/ip route del stunnel_ip

On Android, use "OpenVPN for Android" client by "Arne Schwabe" and "SSLDroid" by "Balint Kovacs".

Then in the OpenVPN client, exclude "SSLDroid" from the VPN profile that goes through the stunnel.

I would've loved to upvote Reza's answer or comment there, but this reputation score rule prevented me.


I've never tried it (so lemme know if it works!) but give a shot @ using ssh tunneling over 443 and run your OpenVPN through the tunnel. You may need an extra remote host to listen on 443 if you don't have one but there is an example here http://www.anonyproz.com/openvpnsshtunnel.pdf for using their proxy service [Editor’s note: this Wayback Machine link may be safer], but this is also Googlable:


I've also known people to use this approach as a proxy because their employer blocked access to job sites such as dice.com back when they were popular.


In addition to LawrenceC's answer, I would like to add that outgoing DDoS protection against slow loris and other "low and slow" DDoS attacks originating from that network will force-close sessions after a certain length of time.

As mentioned before, it might be caused by a traffic volume limit as well, but there is another reason why there would be such a limit; limiting bandwidth per device is trivial with today's (2021) tech and no longer uses session timeouts to enforce that, but outgoing DDoS protection might also kick sessions that send a constant stream of data that uses a protocol who's behavior is intrinsically sporadic, especially if the traffic contains packets that are either too uniform or too fragmented to match the behavior of legitimate HTTPS sessions (which is what a lot of flood-type DDoS attacks look like).

Stateful firewalls have come a long ways in recent years, and preventing this exact behavior has been on the agenda in the context of preventing data exfiltration, as well as the DDoS protections I just listed.

Achieving this goal today against a well-built firewall is going to take a lot more than just some advice on what configurations to use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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