I'm in a restricted network and my attempts to connect to my OpenVPN server (TCP/443) get interrupted by a TCP RST spoof, right after the OpenVPN P_CONTROL_HARD_RESET_CLIENT_V2. I have recorded the traffic on both sides and noticed that both sides receive a connection reset, but neither side actually generates one, i.e. the RST is injected from a firewall inbetween.
Is there a way to disguise OpenVPN to look more like normal HTTPS traffic?
I have found a solution and wanted to share it.
As explained in other places, for example here, a firewall may block VPN connections and traffic, such as those created by OpenVPN by either blocking ports or doing Deep-Packet-Inspection (DPI).
In the first case, using a different port (for example the https port 443) suffices, however for the later, a more refined method is necessary.
DPI is employed by more and more firewalls these days, including the chinese "great wall". The obvious solution is to disguise the VPN traffic as some other traffic, that the firewall is not blocking. A perfect candidate is SSL/TLS, as employed by HTTPS, as the content is encrypted after the handshake which makes it impossible for the firewall to identify the transmitted data.
To tunnel the OpenVPN traffic inside a SSL/TLS connection, a SSL tunnel like stunnel may be used, as described here. It reduces connection performance even more, but makes it impossible for the firewall to differentiate between the user visiting a website over a secure connection or the user using VPN (note that the firewall may kill the connection regardless after a timeout or a data volume limit).
Another, solution, which does not incur said performance hit is explained here. This method replies on two connections to the same server using the same port, using a feature of OpenVPN that allows non-OpenVPN traffic to be forwarded by the OpenVPN server to another application on the same server. The first connection will be a default HTTPS connection, which will not be blocked by the firewall, as the firewall identifies the TLS handshake as valid traffic. On the remote site, OpenVPN forwards this traffic to an SSL enabled nginx server, which replies and sets up a TLS connection. Once that connection is established, an OpenVPN connection will look like encrypted data that is part of the TLS connection to the nginx webserver, but will be identified properly by the OpenVPN server.
I haven't tested the second connection, however I expect it to be less robust than the first solution, as the nginx connection may close at some point, making the OpenVPN traffic stand out.