New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
[Tutorial] OpenVPN Sheathing
OpenVPN is soon becoming the standard for bypassing Internet censorship - and for good reason. OpenVPN is secure, Open Source, and extremely easy to use. Because of this, many censoring ISP's are now blocking OpenVPN. The only sure way to block OpenVPN is a method called DPI (Deep packet inspection). What is troubling for many individuals is the fact the DPI works and is now widely used.
From my comment here. I got more than a few requests on how I hid my OpenVPN traffic from DPI. I finally made a tutorial of my methods to share with the Internet.
Check my weblog post (https://silvenga.com/openvpn-sheathing/).
Hope this helps.
Comments
Cool tutorial, thanks for sharing. How is the sTunnel server memory usage?
One very tiny thing: sTunnel creates a full-blow HTTPS tunnel to disguise ... Maybe it should be "full-blown"?
Not bad, 2.5MB. My CPU gets to .20 when downloading at 100Mb/s.
I did a speedtest from Utah through my server (with sTunnel) to my VPN (Private Internet Access): (http://www.speedtest.net/my-result/3448443270). No noticeable performance impacts of using the tunnel.
Thanks!
Good tutorial I'll give it a try soon
Thanks man
It's easier to just use a ssh tunnel rather than that stunnel program which I take it does the same thing.
No, they are not the same thing.
Some ISP's block SSH. No ISP will block HTTPS (as this would cripple the Internet). End users do not need SSH.
SSH is much more than just encryption, therefore you will see more overhead with SSH tunnels.
Also, SSH is difficult to set up on Windows while sTunnel is cross platform.
Ok but I tried to follow your guide and it doesn't work for me.
What doesn't work?
I've set it up exactly as in your tutorial but when I try to connect locally on 127.0.0.1 1194 nothing happens. I'm not sure why. I've check server and client configs and both are fine. There's no firewall either so I don't know why it wont work
my client side log:
2014.04.19 19:18:08 LOG5[5080]: Reading configuration from file stunnel.conf
2014.04.19 19:18:08 LOG5[5080]: FIPS mode disabled
2014.04.19 19:18:08 LOG5[5080]: Configuration successful
2014.04.19 19:18:15 LOG5[1208]: Service [openvpn-localhost] accepted connection from 127.0.0.1:54577
2014.04.19 19:18:15 LOG3[1208]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
2014.04.19 19:18:15 LOG5[1208]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2014.04.19 19:18:21 LOG5[3964]: Service [openvpn-localhost] accepted connection from 127.0.0.1:54578
2014.04.19 19:18:21 LOG3[3964]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
2014.04.19 19:18:21 LOG5[3964]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2014.04.19 19:18:27 LOG5[3080]: Service [openvpn-localhost] accepted connection from 127.0.0.1:54579
2014.04.19 19:18:27 LOG3[3080]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
2014.04.19 19:18:27 LOG5[3080]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Ok problem solved, I've no idea how but it has Thanks for the tutorial
What ISP blocks SSH? o_o that's pretty crippling.
Cool!
That's odd, I did find a typo in the configuration file though. I had an extra comment tag that would prevent the server from starting if copy and pasted. Thanks, I credit you.
I guess I'm using the term "ISP" as any organization that provides Internet services - so some schools/universities, workplaces, etc. Mainly those areas where the employees do not need SSH - SSH I consider a power user only type of protocol.
And what about the techs using the network? A quick google shows a few people having port 22 blocked and stuff in schools but that's probably more a port whitelist system. I suppose that is blocking SSH though, I was thinking about blocking SSH looking traffic as the OP is about DPI.
Maybe not Home ISP, but education facilities and even more corporate institutions block it. I've seen it blocked on a lot of public and not so public wireless networks, but they also block OpenVPN and PPTP for stupid and unknown to me reasons...
Maybe they do, I've just never heard of SSH being specifically blocked before. Learn something new every day I guess, right?
In fact, the largest "ISP" that interfere SSH is the Great Fire Wall of China.
DPI is deployed on every node of this monster, and if it detects any sign of OpenVPN, it will block the handshake package so the connection cannot be established; if SSH is detected(this does not require DPI though), the GFW will try to do the DPI job to figure out whether this connection is used for tunneling. If so, the GFW will block the port and the remote machine(the oversea one) 's IP address.
Still, if there's no evidence showing that this connection is used for bypassing the censorship, the GFW will randomly degrade the performance.(Yes, we have to learn how to use "screen" before we learn how to install LNMP, for the connectivity is too bad to last during the whole install progress)
Clear evidence had shown that they have this ability, and is performing such scan.
@AThomasHowe
FYI.
Nice tutorial
Can you please comment how is this different from this approach
http://lowendtalk.com/discussion/23555/scrambled-openvpn-auto-installer-script
Also, can your solution be used with the Scrambled OpenVPN connection described in that tutorial?
I have to tell that I tried Scrambled OpenVPN approach from a country that blocks lots of traffic (Kingdom of Saudi Arabia) and that it works perfectly well. If I could harden that connection even more with your approach, that would be great
good job,
yeah, the Chinese started the DPI and blocking of openvpn at the time
of the election (not by the people) of some guy who didn't want criticism.
stunnel works fine,
only problem is, it only works for TCP, not UDP, maybe
an issue if you have high packet loss and retransmissions
other options, shadowsocks, ssh, scrambled openvpn, softether,
From what I know of this Scrambled OpenVPN is that you modify the internal workings of OpenVPN - both on the client and server sides. The resulting traffic is completely different than normal OpenVPN traffic.
So basicly Scrambled OpenVPN traffic will look like nothing known by the DPI. On the other hand sTunnel will hide traffic as what is normally expected. Scrambled might raise some flags, sTunnel will not.
In my own opinion I would not use Scrambled because it is a patch. Patching can introduce bugs and should only be done if I trust the pacher. With that said, Scrambled can be more efficient than sTunnel because Scrambled can use UDP, sTunnel cannot because HTTPS is a TCP only protocol.
sTunnel creates a tunnel covered by HTTPS from one location to another. This means any type of TCP traffic (SSH, IMAP, SMTP, etc.) may use the tunnels. So yes, running Scrambled through sTunnel will work.
However, since sTunnel runs through HTTPS, using Scrambled will add no benefits. DPI will be stopped at the first layer (HTTPS) of the tunnel and will not see the OpenVPN tunnel within.
sTunnel is just another tool to be used when ISP's start blocking the latest anti-censorship trend (it will happen). Just add it to your utility belt when needed.
To my knowledge TCP is better when you have a high packet loss rate (like at airports) and UDP is good when you have a solid, but slow connection - because of the less overhead. TCP knows when a packet is lost faster than UDP.
OpenVPN must retransmit both UDP and TCP packets because it knows nothing of the type of information that it may be transmitting. On the other hand, Netflix using UDP doesn't need to because they are transferring data that will become useless in seconds (streaming video).
>
Actually, UDP is better for any kind of tunnel because it's lower overhead and doesn't try to retransmit packets when that may not be necessary; in certain instances retransmitting packets could even be bad. Basically, anything that needs to either have a stateful connection or a connection that is "reliable" (i.e., TCP) already has packet retransmission built into the protocol, and therefore the underlying medium does not need to be concerned with this. If you run two of these protocols on top of each other (such as TCP over a TCP tunnel), then bad things start to happen as now you have more than one layer trying to retransmit packets.
So really you should use UDP unless there's a very specific reason you need to use TCP, such as a firewall restriction or something. TCP over TCP works fine until you start to have a small amount of packet loss, then it basically becomes unusable.