- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
Not particularly pleased about the decision when OpenVPN is the most supported protocol.
Meanwhile their competitor IVPN even does IPsec.
Not particularly pleased about the decision when OpenVPN is the most supported protocol.
Meanwhile their competitor IVPN even does IPsec.
I assume this is because, in addition to the missing ciphers as referenced in the linked article, OpenVPN, even though it uses TLS, it initially uses a very identifiable handshake before initiating TLS, which is not hard to block. I have personally had problems specifically with OpenVPN being targeted/blocked in this way.
Wireguard is not difficult to block either, it’s not designed to be hidden. China, Russia, etc have learned long ago how to detect and block it. The only semi-reliable way to bypass sophisticated VPN blocking techniques is to use protocols that mask as regular https traffic (and self-host it since well know public VPNs will of course be dealt with by simply blocking packets to their ip addresses).
But why disable it for the people who can use it? Unless there’s a security implication to the handshake?
And I specifically had luck with OpenVPN TCP on port 443 on network which DPI-blocked Wireguard.
Wireguard is not Sensorship and DPI resilient at all, it relies solely on UDP. They state it on their official website that it’s not their priority at all
Yeah OpenVPN is often used for business reasons (e.g. by remote workers), so it’s usually not blocked wholesale, only throttled (and known public VPNs providers and blocked via blacklisting their endpoints’ ip addresses). Wireguard meanwhile is used much more rarely so there is less fallout from blocking it completely.