Hacker News Reader

Comment by nstart | Hacker News Reader

It's actually infuriating this ban. I'm from SL, currently on Nord VPN which hasn't been blocked by 1 of the major ISPs. Both major ISPs are aggressively blocking standard open vpn traffic however. I'm not entirely sure how since this is not my knowledge domain but a default open vpn setup on digital ocean (even on port 443) results in a timeout when contacting the server

I don't understand why one ISP is still allowing Nord and express vpn through. If anyone is open to debug this and help create a work around I'd love help. Feels like a good time to test things.

In the meantime people are using dubious vpn providers and are opening themselves up as easy targets. I dread what would happen if a malicious party created a vpn with malicious intent and then spent some bucks on targeted advertising in SL on the app stores.

This block is such a shit move really. It's become the gov's default crisis time response in the name of national security.

View on HN

OpenVPN, like many other VPN protocols, does not have censorship resistance as part of its design goals. So, I'm guessing that its traffic patterns are quite easy to detect.

You should have better luck with something like Shadowsocks, or even better, Shadowsocks over a SSH tunnel. There are probably better and more potent alternatives that I'm not familiar with. If you just want to do regular web browsing, a simple thing to try is to just use "ssh -D" for a SOCKS5 proxy and configure your browser to use the proxy.

Also, a possible first step in debugging is to run the same server setup in the same country as the client and see whether it allows you to connect to a domestic server. If it doesn't, it's probably a problem with your client/server setup as the state's firewall probably doesn't need to block domestic VPN connections.

In China, most of the solution would be cut down after days/weeks/months. Although the connection was encrypted, GFW would still try to guess if the connection behaviors match some VPN features according to some algorithms, then cut it down.

Currently, I'm using Algo[0] setting up VPN and use Wireguard[1] connect to it, both of them are working perfectly than other solutions I have used.

[0] https://github.com/trailofbits/algo [1] https://www.wireguard.com/

Thanks. I'll be taking a look at tunelling soon. The material around it is difficult to read and put together to be honest.

I'm right now using Nord via their ovpn files. Somehow it made its way through one ISP ruleset.

For my digital ocean box, I asked someone else to use tunnelblick with the ovpn file I provided them to see if it worked (they were in another country) and it worked. This makes me believe it's most likely a country level issue.

In general though I'd like to learn about networking more thoroughly and set up a censorship resistant option which I can help others to setup and share as well later on. Any primers/pointers are appreciated too. I'll start with all the things you mentioned though.

I suggest looking into WireGuard [1]. I found it easier to use than OpenVPN, and I think it will displace it as the de facto standard when it eventually gets merged into the Linux kernel. You'll have to use lower-level configuration tools to get started with it, which I am finding helpful to pursue the same goal of learning about networking more thoroughly.

[1]: https://news.ycombinator.com/item?id=17659983

While like Wireguard a lot, it won't displace Openvpn completely, for the simple reason that it only works over UDP, and cannot work over TCP, unlike Openvpn.

Transforming generic layer 3 datagrams into traffic that looks like something else is the general domain of obfuscation. Making WireGuard traffic look like TCP is one form of such obfuscation. Making it look like TLS or DNS or HTTP are other forms. (Actually putting layer 3 traffic into framing inside a legit TCP stream is inefficient and the wrong way to think about the problem domain.) No promises, but I'm expecting some nice things to come in this domain of generic obfuscation mechanisms to punch through various forms of filtering.

Inefficient as it may be, it is something I simply need for my use case - connecting home from a certain network which only allows outgoing connections on a handful of TCP ports.

No. You need your traffic to look like TCP, for your particular network filtering. But you do not need to achieve that by using the naive and inefficient approach of, "stick the packets into a TCP stream prefixed by a length field." Rather, there are more clever tricks for making your traffic look like TCP, which generally fall into the same realm as other obfuscation mechanisms.

ssh -D1234 remotehost gives you a local SOCKS proxy at port 1234 that goes through remotehost.

Other than that, do investigate DNS on HTTPS and DNS on TLS. I recommend setting up something like dnscrypt-proxy to serve as the DNS resolver for your LAN.

OpenVPN iirc has a custom negotiation protocol which happens before TLS and is probably the vector used for detection.

Reply on news.ycombinator.com