[wulfstan]

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.

[ykl]

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/

[rglynn]

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.

[ikurei]

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.

[hnfong]

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.

[Quiark]

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

[eqvinox]

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)

[kimixa]

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

[drdaeman]

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.

[Marsymars]

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

[anonzzzies]

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.

[ranger_danger]

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

[wulfstan]

That is impressive. Beyond bonkers, but impressive.

[tracker1]

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.

[77pt77]

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

[tossit444]

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

[IshKebab]

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

[ykl]

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.

[moduspol]

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.

[77pt77]

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

[moduspol]

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.

[ranger_danger]

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