We deploy to a lot of very restrictive corporate networks where outbound traffic is inspected (even if still encrypted) and many of those outbound gateways can tell the differences between HTTP over TLS and OpenVPN using port 443.
Would be great to have support for GitHub - Doridian/wsvpn: VPN over WebSocket and WebTransport or some other VPN that uses proper HTTP WebSockets instead of OpenVPN. Has this been considered?
This thread seems similarly resolved by adding support for this:
We have the same issue: Customers where VPN traffic is blocked due to SSL inspection.
For example with firewall product ZScaler.
I get that OpenVPN handles a bunch of funky routing on both the edge side and the balena-vpn server side, but I don’t see the edge doing anything that isn’t easily doable over a standard WebSocket, and a standard WebSocket would be fully compliant with virtually any corporate firewall or MITM requirement…
Looking into this more, the easiest fix seems to be to move to the SoftEther VPN, which has full wire-line compatibility with OpenVPN on both the client and server side, meaning it is a drop-in replacement on both openbalena-vpn and in balenaOS, while maintaining backwards compatibility by default.
For advanced users, it can be reconfigured on both client and server to use SoftEther VPN Protocol (Ethernet of HTTPS), L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, or EtherIP. The server can even support all of these at the same time allowing for each fleet or even each device to use a different protocol as necessary, or staged migration to a new protocol.
It even supports VPN over ICMP and VPN over DNS if you a deployment really needs it.
Open Source, Apache 2.0 licensed, builds across all platforms and cpu architectures.