Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Advertise on LowEndTalk.com

[Tutorial] OpenVPN Sheathing
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

[Tutorial] OpenVPN Sheathing

OpenVPN Logo

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

  • souensouen Member

    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"?

  • souen said: How is the sTunnel server memory usage

    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.

    souen said: Maybe it should be "full-blown"?

    Thanks!

    Thanked by 1souen
  • RamiRami Member

    Good tutorial I'll give it a try soon

    Thanks man

    Thanked by 1netomx
  • sc754sc754 Member

    @Silvenga said:
    OpenVPN Logo

    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.

    It's easier to just use a ssh tunnel rather than that stunnel program which I take it does the same thing.

  • sc754 said: 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.

    Thanked by 1netomx
  • sc754sc754 Member

    @Silvenga said:

    • 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.

  • sc754 said: Ok but I tried to follow your guide and it doesn't work for me.

    What doesn't work?

  • sc754sc754 Member

    @Silvenga said:
    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 :/

  • sc754sc754 Member

    @Silvenga said:
    What doesn't 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

  • sc754sc754 Member

    Ok problem solved, I've no idea how but it has :) Thanks for the tutorial

  • Silvenga said: Some ISP's block SSH. No ISP will block HTTPS (as this would cripple the Internet). End users do not need SSH.

    What ISP blocks SSH? o_o that's pretty crippling.

    My personal blog and website | Freelance web developer & programmer. HTML/CSS/PHP/JS (Clientside & Serverside)/C# and more

    Installing Observium on Debian

  • sc754 said: Ok problem solved, I've no idea how but it has :) Thanks for the tutorial

    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.

    Thanked by 1netomx
  • SilvengaSilvenga Member
    edited April 2014

    AThomasHowe said: What ISP blocks SSH? o_o that's pretty crippling.

    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.

    My personal blog and website | Freelance web developer & programmer. HTML/CSS/PHP/JS (Clientside & Serverside)/C# and more

    Installing Observium on Debian

  • @AThomasHowe said:

    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? ;)

    My personal blog and website | Freelance web developer & programmer. HTML/CSS/PHP/JS (Clientside & Serverside)/C# and more

    Installing Observium on Debian

  • @Makenai said:
    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...

    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.

  • mihhamihha Member

    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

  • john564john564 Member
    edited April 2014

    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,

  • SilvengaSilvenga Member
    edited April 2014

    mihha said: Can you please comment how is this different from this approach

    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.

    mihha said: Also, can your solution be used with the Scrambled OpenVPN connection described in that tutorial?

    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.

    mihha said: If I could harden that connection even more with your approach, that would be great

    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.

  • SilvengaSilvenga Member
    edited April 2014

    john564 said: maybe an issue if you have high packet loss and retransmissions

    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).

  • @Silvenga said:
    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.

Sign In or Register to comment.