Hacker News Reader

Comment by joshryandavis | Hacker News Reader

I lived in China for a while and there were several waves of VPN blocks. Also very few VPN services even try to actively support VPN-blocking nations anymore. Any commercial offering will be blocked eventually.

What I settled on for decent reliability and speeds was a free-tier EC2 hosted in an international region. I then setup a SOCKS5 server and connected my devices to it. You mentioned Cloudflare so whatever their VM service is might also work.

It's very low profile as it's just your traffic and the state can't easily differentiate your host from the millions of others in that cloud region.

LPT for surviving the unfree internet: GitHub won't be blocked and you'll find all the resources and downloads you need for this method and others posted by Chinese engineers.

Edit: If you're worried about being too identifiable because of your static IP, well it's just a computer, you can use a VPN on there too if you want to!

View on HN

The VM instance is good for setting up a VPN tunnel, but it's not good in terms of bandwidth if it's hosted in. Because of DPI capacity, China has a very limited amount of "real internet" bandwidth. A more capable setup is to have one VM on each side of the firewall on an hosting service with peering between inside and outside - Aliyun (Alibaba Cloud) is an example. The "inside" VM could be just "socat UDP4-RECVFROM:<port>,fork UDP4-SENDTO:<remote>:<port>" or something done using netfilter.

Like others commented in this thread, having an obfuscator is a good idea to ensure the traffic is not dropped by DPI.

When the inevitable ban comes and your VPN stops working, rotate the IP of the external VPN and update the firewall/socat config to reflect it. Usually, the internal VM's IP doesn't need to be updated.

How easy is it to get a VPS in China.

Could HK work?

HK "outside" the firewall, for now. It's where you would place the outside VM.

But does access to HK go throught the firewall?

The access from mainland to HK goes through the firewall, the access from HK to the normal internet is unrestricted as far as I know. The communication between the two VMs still needs to be obfuscated and encrypted. The only reason for the VM inside the Chinese Internet is higher bandwidth.

When I worked in China (not for long periods but frequently enough that the Great Firewall became an irritant) I hosted an OpenVPN server on port 443 and/or port 22 of a server I owned. That worked sufficiently well most of the time.

This doesn't work anymore; the GFW no longer detects VPN connections by port but instead by performing deep packet inspection to characterize the type of traffic going over every connection. Using this technique in combination with some advanced ML systems, they're able to detect any encrypted VPN connection and cut it off; it's basically not possible to run any kind of outbound VPN connection (even to private servers) from inside of China anymore, and it's usually not even possible to _tunnel_ a VPN connection through some other protocol because the GFW now detects that too.

Stepping back and looking at it from a purely technical perspective, it's actually insanely impressive.

Here's a USENIX paper from a few years ago on how it is done: https://gfw.report/publications/usenixsecurity23/en/

> it's basically not possible to run any kind of outbound VPN connection (even to private servers) from inside of China anymore.

Really? Because the paper you linked says they don't block any TLS connections so you can just run a VPN over TLS:

> TLS connections start with a TLS Client Hello message, and the first three bytes of this message cause the GFW to exempt the connection from blocking.

Give it a try if you want; it doesn't work. For TLS traffic they track what the connection looks like over time; a TLS connection for normal web traffic versus a VPN connection tunneling through TLS apparently look different enough that they can detect and cut it off.

Worth noting is that OpenVPN’s TCP TLS mode does not work that way. It’s essentially the UDP protocol messages except wrapped into TCP. The initial handshake is not a normal TLS client hello.

Not sure about other SSL VPNs.

> it's basically not possible to run any kind of output VPN connection (even to private servers) from inside of China anymore.

What if you run your own HTTPS server that look semi-legitimate and just encapsulate it in that traffic?

Can they still detect it?

What about a VPS in HK? Is this even doable?

v2ray and similar servers do exactly that, and I would assume they're still working as they're actively developed.

Assuming they don't MITM SSH, you should still be able to use something like wireguard over an SSH tunnel. At least I would think.. it's all SSH traffic as far as any DPI listener is concerned, you'd of course need to ensure the connection signature through another vector though.

That is impressive. Beyond bonkers, but impressive.

This is what IPsec TFS is for [https://datatracker.ietf.org/doc/rfc9347/]

> the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel

(If they block a constant rate stream, that'll hit a whole ton of audio/video streaming setups)

So they'll just block any constant rate stream that isn't containing AV data or a whilelisted streaming service.

I don’t think that’s possible. AV data is behind the TLS layer, all the DPI can see is a CBR stream that matches HTTPS signature. Unless it can do a MitM (Kyrgyzstan-style) they can’t really tell anything about the payload content save from what the TLS handshake may expose. Past it, observability stops at packet sizes and timings.

As I understand it, modern DPIs try to fingerprint TLS traffic through feeding data that passed some pattern matching to ML models that try to predict how likely it’s between a genuine commonplace browser and a “normal” webserver (or a video streaming server or game server - whatever they trained it on). And in turn modern obfuscation software tries to match the behavior and be seen exactly as it’s your Chrome user watching some cat videos or something equally innocuous.

Aren't many/most audio/video streaming services variable bitrate now?

So there's a disconnect between what you're saying and what others and myself have experienced in China even recently. You appear to be saying that it's not possible to use a VPN to bypass the GFW, but I apologise if I have misunderstood.

The comments have multiple examples of people successfully bypassing the firewall. I personally just used Mullvad with wireguard + obfuscation (possibly also DAITA) and it just worked. No issues whatsoever.

It's possible it worked in the past and doesn't work any more.

This changes, not only over time, but also from region to region.

A close friend of mine travels to China often, and they use Mullvad because of my recommendation. Last year it worked great for them, but earlier this year they went back to China, and it really didn't work.

What I found most interesting is that they had different results in different places. Apparently, in the business areas of Shanghai and Beijing, were they had meetings and events, they could get Whatsapp and Slack messages; when they went back to the hotel, in a residential area where there were almost no offices or tourists, it didn't. In Chongqing even less stuff worked.

I was very skeptical of this when they told me, but they could replicate this consistently over a couple of weeks. It wasn't related to hotel Wifi (that's a different can of worms), this was on mobile data.

Everything worked when they switched to using https://letsvpn.world, at the recommendation of some chinese colleagues of them.

This was with a basic Mullvad install on iOS and Mac, they're not technical enough to harden their VPN connection further; may be they could've easily obfuscated it more and it would've worked.

The GFW being more lenient for tourists (esp. their foreign mobile plan) checks out with the stories I hear too. I'm guessing the less touristy places don't have "support" for these "exceptions" so they get a degraded experience there.

When I lived in China 10 years ago, GFW had a pretty effective way by slowing constant traffic that goes to an outside china ip address more and more over time. I had about 6 hours per ip (it starting to get slower and slower during that time) before having to rotate because even basic webpages didn't get through and ssh was unusable.

> it's basically not possible to run any kind of outbound VPN connection (even to private servers) from inside of China anymore

This is not true anymore, and your own link says so:

> all circumvention strategies adopted by these tools are reportedly still effective in China

And while this paper is not the most up to date, there are actually many new kinds of obfuscating VPN/proxy/tunnel technologies out now, and they are currently not blocked. Some methods can even disguise themselves as unencrypted, plaintext legitimate-looking HTML and still tunnel traffic (slowly) through it.

Which is ridiculous because OpenVPN is trivial to identify, even when over TCP since it's different from "regular" HTTPS/SSL traffic.

Why they chose this I have no idea.

You can even port share.

443 -> Web server for HTTPS traffic 443 -> OpenVPN for OpenVPN traffic

Still trivial to identify and not uncommon for even public WiFi to do so.

Since I changed to tailscale+headscale with my own derp server all these issues have disappeared (for now).

It’s basically the same as the UDP mode, except wrapped into TCP. Presumably because that’s simpler than redesigning it from the ground up for TCP.

So the handshake and such will not look like a normal TLS handshake.

SoftEther works over "regular" TLS at least, you can even reverse-proxy it.

Out of all VPS providers out there, why did you chose one of the most, if not the most, expensive ones - AWS, EC2?

GitHub was briefly blocked a couple of years ago in Indonesia. SSH was also blocked briefly by one of the largest mobile providers.

>the state can't easily differentiate

I'd be very surprised if the GFW DPI can't pick up SOCKS5 protocol.

More likely version is the handful of people with both ability and means to do this are simply not worth going after

Isn't VPS's public IP blocks are well known and very easy to block? I read that this is not a viable solution in case of China's firewall.

Denying the entire country the ability to ssh into ec2 instances would be pretty economically damaging, even for china

Exactly, yeah. Small VPS providers are possible to get blocked but blocking AWS regions would be devastating. So it is the perfect place to put something like this.

Blocking - yes, heavily rate limiting - already happening.

Github is blocked 90% of the time here in China. It is weird.

Oh really? That's surprising.

Reply on news.ycombinator.com