TLS handshake failed!

[Zartosht]

I have successfully spun up an OpenVPN server and connected to it in my network. So far so good.

But I have another network that just allows TLS handshake to be established with well-known TLS certificates. So in this network, I face the "TLS handshake failed".
I am new to OpenVPN. I am looking for a solution to use a domain with a certified TLS to connect to the server. Is it even possible?

[ordex]

Hi there!
With "another network" you mean "another OpenVPN server"?
When connecting to a specific OpenVPN server you need credentials (i.e. a certificate) that is valid for *that* server.

[Zartosht]

Hey!
No. There is one OpenVPN server. Clients are in different networks.
To be precise, I can connect to the OpenVPN server. But clients in Iran(another network) cannot connect to it. Because they blocked the TLS handshake. As I said, they only allow TLS handshakes for well-known issuers.
I do not know how the OpenVPN handshake works. I think if I can use a domain with a well-known TLS issuer, the problem will fix.

[ordex]

OpenVPN does not perform a classic TLS handshake like (for example) web browsers.
So probably in Iran they entirely blocking the OpenVPN protocol or the port being used (?)

[Zartosht]

Thanks for the clarification. Is there any documentation on how the TLS handshake works in OpenVPN?

For now, I run a server inside and did ssh port forwarding to the OpenVPN server. People can connect to the OpenVPN server through the inside server. But I was looking for a solution to remove the inside server. Note that the OpenVPN IP is not blocked and can be reached from Iran. Furthermore, I use a different port rather than 1194(the default port).

I should mention that without the inside server, the clients get a "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)" error. I think the problem occurs before the OpenVPN protocol initiates and the connection cannot be established.

My finding: the server receives the TLS request, then answers it. But the client does not receive the server's answer.

[ordex]

It's very possible that they are intercepting the OpenVPN wire format and just dropping all packets. The TLS handshake is performed like any other handshake, but it happens *inside* the OpenVPN encapsulation. The latter is what might be getting blocked

[Zartosht]

It's very possible that they are intercepting the OpenVPN wire format and just dropping all packets.

Does this answer why it is possible to connect to OpenVPN through an SSH port forwarding?

The TLS handshake is performed like any other handshake, but it happens *inside* the OpenVPN encapsulation.

I know this might be a silly question. It is not possible to use a signed certificate(like websites), right?

[ordex]

It's very possible that they are intercepting the OpenVPN wire format and just dropping all packets.

Does this answer why it is possible to connect to OpenVPN through an SSH port forwarding?

Yeah, in this case the connection looks like a normal SSH connection. What flows inside is not visible to whoever is intercepting it.

[Kamal1401]

I have also the similar problem. I have a Centos 7 server outside Iran, and the IP is not blocked. However, any VPN that I have installed (including Outline, OpenConnect, Wireguard, and OpenVPN) fails to do the TLS handshake with the clients inside Iran. Not to mention that all vpn's work fine if the client is outside Iran.
I tried anything I could:
- upgrading TLS to TLS1.3,
- VPN obfuscation via auth-crypt and auth-crypt-v2 in Openvpn
- relaxing any key verification by the PAM auth (username and password) in Openvpn.
Nonetheless, the problem persists; After receiving the initial TLS packet from the client, the connection stuck and fails.

Any suggestion to circumvent this governmental internet blockage?
Is there any authorization method in Openvpn which does not need this first initial TLS packet?