[solved] TLS Error: TLS handshake failed

Bob.Dig

This worked before and I don't get it, why it is not anymore.

I have a OVPN-Server on 2.4.5-RELEASE-p1 which is "Multihome" v4 and v6 on all interfaces.
Now my android-phone is always connected to it with "OpenVPN for Android 0.7.21".
If I am connected via wifi there are no problems, but if I am connected via mobile, I get this error:

TLS Error: TLS handshake failed
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

According to pfSense firewall, it can make the connection, is not blocked.

noplan

@bob-dig

same here .... kind of fixed it with this

and getting a new client on the win machine
but cant say what fixed what first cuz pretty anoyed by this ...

but its workin now

Bob.Dig

But I hadn't newly exported anything, so this can't be it, right?

noplan

@bob-dig

old client with new exported config was here the reproduced problem
new client with same config worked

if this happens when u update to 2.4.5-RELEASE-p1 there will be troubles ...

Bob.Dig

Still only working from LAN, not from internet. Anyone else got some ideas?

impact1560

I'm also having these same issues. I tried to reinstall but I keep getting the same error message.

Bob.Dig

I made a complete new server with the wizard on 2.4.5-RELEASE-p1. But still the same problem with OpenVPN for Android, from inside it works, from external it is not. I also disabled the OVPN 2.5 settings this time, doesn't help.

Any help appreciated.

persist-tun
persist-key
cipher AES-256-GCM
auth SHA512
tls-client
client
remote 192.168.201.1 41174 udp
remote xxx.xx 41174 udp
verify-x509-name "NewClient" name
auth-user-pass
remote-cert-tls server

Bob.Dig

This post is deleted!

viragomann

@bob-dig
Possibly there are more details in the client log.

Bob.Dig

@viragomann said in TLS Error: TLS handshake failed:

@bob-dig
Possibly there are more details in the client log.

There are not, it is the same message like shown in the first post.

1194 is the source port, don't know why it is the default, but anyway, it is not the source of the problem at least.
Still not working here.

viragomann

@bob-dig said in TLS Error: TLS handshake failed:

There are not, it is the same message like shown in the first post.

That is the common log if the client is not able to reach the server.
So check if the packets are arriving properly on WAN at 41174 UDP.

@bob-dig said in TLS Error: TLS handshake failed:

1194 is the source port, don't know why it is the default, but anyway, it is not the source of the problem at least.

As long as the client only establishes a single connection.
For multiple add

lport 0

to the clients config file.

Bob.Dig

@viragomann According to the firewall log they are.

Bob.Dig

Maybe @JeGr has an idea?

JeGr

@bob-dig So works from inside but not from outside? How's it configured on the WAN side then?

Bob.Dig

@jegr Hey, maybe you can help.
It is just an open port to the pfSense WAN-Interface. And the result can be seen in the picture above. fritzbox in between and pfSense is the exposed host.
In the openvpn client config I have two addresses, DDNS of my WAN and the pfSense Interface on my Wifi.
In the server wizard I had selected this WAN-Interface and UDP 4&6 on all interfaces (Multihome).

JeGr

@bob-dig Huh and it works on Wifi but not on WAN? Or vice versa? Would have to rebuild that scenario myself, can't see why it shouldn't be working. I would've used two port forwards instead and bound the server to localhost/udp1194 to simplify as I've seen strange things with that multihome config.

Bob.Dig

@jegr So I setup one server without the wizard listening on any and it worked, although I had to reboot pfSense to get "the surfing" working too.
And you can port forward towards localhost? Have never done this.
But maybe it would be easier to host the OVPN Server on the "Wifi" Interface and do a portforward from WAN to it. Thanks Jens!

So problem is solved by not using "multihome" in the first place.

JeGr

@bob-dig And you can port forward towards localhost? Have never done this.

Sure why wouldn't it? Localhost is a normal interface. 127.x.x.x are "normal" IP addresses. No reason why a service or daemon shouldn't run or listen on localhost or a localhost-style IP address. Many developers e.g. in Ops or DevOps use local development tools and servers to test on their own machines (because faster) and bind e.g. a web-stack for rapid development to localhost. OpenVPN isn't really anything special in that consideration.

Also it's really one of the defaults to run an OpenVPN server on localhost when dealing with MultiWAN. You don't want two different servers for every WAN but same IP space, same settings, same certs etc. so easiest way is to "bind" it to localhost so it is awaiting traffic and just use two port forwards on the appropriate interfaces to direct traffic to it from those WANs. The same could be done with your internal WiFi network, too. Plus side is, that port forwards also use "reply-to" parameters of pf so traffic should always return the way same way out it "got into" the OVPN server in the first place.
We've customers running 4 DSL and 1 fibre line and for easier migration we configured their OVPN server to listen on localhost and redirect traffic from all those WANs to it. So if anyone is still using an old DSL IP it's still working :)

Multihome should make that configuration easier and also add multi-link support for IPv4+IPv6 but somehow multihome still makes trouble when running. Either in selecting the wrong IP family or in some other fashion like your problem that doesn't really make much sense...