TLS handshake fails for certain clients

Need help configuring your VPN? Just post here and you'll get that help.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
boronian
OpenVpn Newbie
Posts: 7
Joined: Thu Mar 26, 2020 4:37 pm

TLS handshake fails for certain clients

Post by boronian » Thu Mar 26, 2020 5:30 pm

Hello all,
due to the COVID19 situation I try to set up a VPN tunnel for my colleagues to work from home, which works (yay) for three but fails for two others.

The common things for the two persons for whom the connection fails (with the message "tls handshake failed" in their log) are:
Their Internet provider is German Telekom,
They have a IPv6 but apparently as well a IPv4 (I am quite sure the rest only has IPv4. Will try to find out)
They have a Speedport as Router (still need to find out the exact model/Firmware version)

The setup is as follows:
We have a Synology NAS in the company network, which has a VPN-Server app (from the official Synology app store) installed and serves as the OpenVPN server. The NAS is behind a Gateprotect Firewall, and a LANCOM Router. In both these last mentioned devices, a UDP port forwarding is enabled and works fine for 3 Clients. I only want to grant these users access to the NAS, not the whole Network.

Maybe intreresting: I also set up a Cloud app from Synology (which works without port forwarding) and these two users show up in the cloud client list with their IPv6... but see the trace below, why I think IPv6 is not the problem...

Now I don't know if this is something you guys can help me with in the first place, because the server seems to work fine in general and so many (other) sources for the failures are possible. Yet, I am hoping for a hint or two, what could be the reason for the failure.
Is it an OpenVPN setting? Is it IPv6 in general (I actually doubt that, see the trace below - it only has IPv4-Addresses!)? May it be a security setting in the Speedports? Is it some weird network behavior on the Telekom side? Anything else possible?

A problem on the company's network side I am pretty confident to exclude as a trace showed:

Code: Select all

[IP-Router] 2020/03/26 11:31:10,482  Devicetime: 2020/03/26 11:31:08,699
IP-Router Rx (INTERNET, RtgTag: 10): 
DstIP: <server, LAN IP>, SrcIP: <client, WAN IP>, Len: 42, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 1194, SrcPort: 1194
Route: WAN Tx (INTERNET)

[IP-Router] 2020/03/26 11:31:10,482  Devicetime: 2020/03/26 11:31:08,719
IP-Router Rx (INTERNET, RtgTag: 10): 
DstIP: <client, WAN IP>, SrcIP: <generic WAN IP>, Len: 56, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), network unreachable
embedded IP header:
DstIP: <server, LAN IP>, SrcIP: <client, WAN IP>, Len: 42, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 1194, SrcPort: 1194
the things in <> are all true IPv4 addresses
For the <generic WAN IP> I only assume it is a generic one... tbh I can't really explain what it is... but it is from this range:
https://apps.db.ripe.net/db-web-ui/look ... pe=inetnum
And it is not and never was the company's router WAN address to the best of my knowledge...

The trace above I interpret as follows (please correct me if I am wrong):
the connection request from the client is forwarded correctly from the company's LANCOM router and a confirmation package is sent back from the VPN server (so everything works like it should on the company's network, right?) but the confirmation package doesn't reach the client ("ICMP (1), network unreachable").

I paste the client settings below (although these are the the same for the clients who can access the VPN):
Client config

dev tun
tls-client
remote YOUR_SERVER_IP 1194 ##YOUR_SERVER_IP is a true IPv4 adress I don't like to share :)
float
pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
</ca>


EDIT: I found the server configuration file, which I paste below (and adjusted it already to produce the requested verb 4 log... will upload that tomorrow to our NAS as I guess I should stop the service when I do that...)
Server config

push "route 10.8.0.0 255.255.255.0"
dev tun

management 127.0.0.1 1195

server 10.8.0.0 255.255.255.0


dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 10

comp-lzo

persist-tun
persist-key

verb 4

log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher AES-256-CBC
auth SHA512

end EDIT

Please excuse me if I didn't test an obvious thing... I only know about OpenVPN since 2 days :| (and it's awesome :) )
Last edited by boronian on Thu Mar 26, 2020 8:01 pm, edited 1 time in total.

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: TLS handshake fails for certain clients

Post by TinCanTech » Thu Mar 26, 2020 6:10 pm

Your thread reads to me as: "This has nothing to do with openvpn"

Openvpn does not work because you don't know how your network works.

I would ask for configs and logs but there is no point.

boronian
OpenVpn Newbie
Posts: 7
Joined: Thu Mar 26, 2020 4:37 pm

Re: TLS handshake fails for certain clients

Post by boronian » Thu Mar 26, 2020 6:35 pm

Dear TinCanTech,
Thanks for your Comment.

mmh... maybe I wasn't specific enough, please let me know what specifics you need and I will try to gather them.

Actually OpenVPN does work nicely (as I wrote), just not for certain clients (as I wrote as well).
I was hoping, someone could provide me with some hints what the OpenVPN clients' environments need to receive the response (which I assume is sent correctly?). I actually pretty much know now (also thanks to setting up the OpenVPN server) how the company's network works (do you need any details of that?). Yet, I don't know in detail all the clients' networks, obviously. My use case is, that I am one of many clients, but the administrator of the server. So of course I would like all the clients to be able to connect to the server.
If your ansẃer is: "The server works for some, so it must work for all, so the problem MUST be something unrelated to OpenVPN on the clients' side (router setting, network provider ...)" that's fine, too. Then I can at least rule out the possibility, that I can do something to that problem by adjusting the client settings (which I posted). I didn't find the config file for the server yet (as I don't have native openVPN but "just" the Synology app, which seems to be a bit limited... ), but I can provide a screen shot of the settings page, if you think this might help. EDIT: Found the server config and pasted it to the original post. end EDIT

Which logs would you need in case you reconsider helping me? The failing clients' connection logs?
Last edited by boronian on Thu Mar 26, 2020 11:02 pm, edited 1 time in total.

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: TLS handshake fails for certain clients

Post by TinCanTech » Thu Mar 26, 2020 7:00 pm

Please post your server log at --verb 4 showing the failed connection attempts.

boronian
OpenVpn Newbie
Posts: 7
Joined: Thu Mar 26, 2020 4:37 pm

Re: TLS handshake fails for certain clients

Post by boronian » Thu Mar 26, 2020 10:35 pm

Ok, I couldn't let it (or me) sleep until I tried to upload the modified conf file... The users for which the connection failed are offline currently. This will have to wait until tomorrow (11pm here),
but something cought my eye for 2 of the clients for whom the connection worked before:

Code: Select all

Thu Mar 26 22:59:59 2020 us=908316 <Client1's user name>/::ffff:<client1's WAN IP>(37109) SENT CONTROL [<Client1's user name>]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)
Thu Mar 26 23:00:00 2020 us=205272 <Client1's user name>/::ffff:<client1's WAN IP>(37109) MULTI: bad source address from client [::], packet dropped

...

Thu Mar 26 23:03:03 2020 us=437010 <Client2's user name>/::ffff:<client2's WAN IP>(48718) SENT CONTROL [<Client2's user name>]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.10 10.8.0.9' (status=1)
Thu Mar 26 23:03:03 2020 us=589227 <Client2's user name>/::ffff:<client2's WAN IP>(48718) PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_00000] 0:7 0:6 t=1585260183[0] r=[0,64,15,1,1] sl=[57,7,64,528]
Thu Mar 26 23:03:03 2020 us=952840 <Client2's user name>/::ffff:<client2's WAN IP>(48718) MULTI: bad source address from client [::], packet dropped
(I replaced IP addresses and clients' names with descriptions in <> )

Is this something to worry about? As client1 is me, I can confirm the VPN tunnel is open and working, regardless of the "Packet dropped" and "bad source" statements. Client2 I can talk to tomorrow. I'll update.

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: TLS handshake fails for certain clients

Post by TinCanTech » Thu Mar 26, 2020 10:41 pm

boronian wrote:
Thu Mar 26, 2020 10:35 pm
MULTI: bad source address from client [::], packet dropped
This is safe to ignore.

boronian
OpenVpn Newbie
Posts: 7
Joined: Thu Mar 26, 2020 4:37 pm

Re: TLS handshake fails for certain clients

Post by boronian » Fri Mar 27, 2020 10:16 am

here is the relevant part of the server log:

Code: Select all

Fri Mar 27 10:57:07 2020 us=973090 MULTI: multi_create_instance called
Fri Mar 27 10:57:07 2020 us=973202 ::ffff:<Client's WAN IP>(53917) Re-using SSL/TLS context
Fri Mar 27 10:57:07 2020 us=973246 ::ffff:<Client's WAN IP>(53917) LZO compression initialized
Fri Mar 27 10:57:07 2020 us=973355 ::ffff:<Client's WAN IP>(53917) Control Channel MTU parms [ L:1602 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Fri Mar 27 10:57:07 2020 us=973387 ::ffff:<Client's WAN IP>(53917) Data Channel MTU parms [ L:1602 D:1450 EF:102 EB:143 ET:0 EL:3 AF:3/1 ]
Fri Mar 27 10:57:07 2020 us=973459 ::ffff:<Client's WAN IP>(53917) Local Options String: 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Fri Mar 27 10:57:07 2020 us=973486 ::ffff:<Client's WAN IP>(53917) Expected Remote Options String: 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Fri Mar 27 10:57:07 2020 us=973525 ::ffff:<Client's WAN IP>(53917) Local Options hash (VER=V4): 'aaa173e3'
Fri Mar 27 10:57:07 2020 us=973562 ::ffff:<Client's WAN IP>(53917) Expected Remote Options hash (VER=V4): '9c102b00'
Fri Mar 27 10:57:07 2020 us=973619 ::ffff:<Client's WAN IP>(53917) TLS: Initial packet from [AF_INET6]::ffff:<Client's WAN IP>:53917, sid=12121212 12121212
Fri Mar 27 10:58:08 2020 us=8945 ::ffff:<Client's WAN IP>(53917) TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Mar 27 10:58:08 2020 us=12417 ::ffff:<Client's WAN IP>(53917) SYNO_ERR_CERT
Fri Mar 27 10:58:08 2020 us=12464 ::ffff:<Client's WAN IP>(53917) TLS Error: TLS handshake failed
Fri Mar 27 10:58:08 2020 us=12594 ::ffff:<Client's WAN IP>(53917) SIGUSR1[soft,tls-error] received, client-instance restarting
Why is the hash different? This client has the same ca.crt as the other three Clients for whom the connection works...

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: TLS handshake fails for certain clients

Post by TinCanTech » Fri Mar 27, 2020 12:04 pm

boronian wrote:
Fri Mar 27, 2020 10:16 am
Fri Mar 27 10:57:07 2020 us=973619 ::ffff:<Client's WAN IP>(53917) TLS: Initial packet from [AF_INET6]::ffff:<Client's WAN IP>:53917, sid=12121212 12121212
Fri Mar 27 10:58:08 2020 us=8945 ::ffff:<Client's WAN IP>(53917) TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Mar 27 10:58:08 2020 us=12417 ::ffff:<Client's WAN IP>(53917) SYNO_ERR_CERT
Fri Mar 27 10:58:08 2020 us=12464 ::ffff:<Client's WAN IP>(53917) TLS Error: TLS handshake failed
This means:
  • Initial connection from an IPv6 client
  • One minute later the negotiation failed
  • SYNO_ERR_CERT ... I have no idea what this means ..
Make sure your server machine has IPv6 properly enabled.

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: TLS handshake fails for certain clients

Post by TinCanTech » Fri Mar 27, 2020 12:24 pm

Protocol error:
  • Server: proto udp6
  • Client: proto udp
I would use `proto udp` for both.

boronian
OpenVpn Newbie
Posts: 7
Joined: Thu Mar 26, 2020 4:37 pm

Re: TLS handshake fails for certain clients

Post by boronian » Fri Mar 27, 2020 12:26 pm

TinCanTech wrote:
Fri Mar 27, 2020 12:04 pm
Make sure your server machine has IPv6 properly enabled.
Ok, so my initial thought was correct and I just got side tracked by the trace from our router which showed only the IPv4... The problem is then, that I need to learn more about IPv6 I fear... The Synology OpenVPN app does not retrieve a IPv6 prefix, so I guess I'll need to enable IPv6 somehow for our LAN...?

Thank you, TinCanTech, for your help, I wouldn't have recognized that the initial attempt is via IPv6, I just saw the IPv4 ("<Client's WAN IP>"). I guess the "AF_INET6" was the hint?

Or would there be an option to force the client to use IPv4? I guess that would be easier...

On the other hand... If I understand this thread correctly, the IPv6 should NOT be the problem? (I am confused!)
https://www.reddit.com/r/OpenVPN/commen ... ent_andor/


Cheers!

boronian
OpenVpn Newbie
Posts: 7
Joined: Thu Mar 26, 2020 4:37 pm

Re: TLS handshake fails for certain clients

Post by boronian » Fri Mar 27, 2020 12:34 pm

TinCanTech wrote:
Fri Mar 27, 2020 12:24 pm
Protocol error:
  • Server: proto udp6
  • Client: proto udp
I would use `proto udp` for both.
OOOh! I am trying that currently! :idea:

boronian
OpenVpn Newbie
Posts: 7
Joined: Thu Mar 26, 2020 4:37 pm

Re: TLS handshake fails for certain clients

Post by boronian » Thu Apr 02, 2020 1:15 pm

Sorry for the late follow-up. The proto udp suggestion didn't do the trick, unfortunately, but then more urgent things kept and still are keeping me busy. If anyone has more tips for me, I'd be grateful! I will definitely post something if I find a solution... thanks @TinCanTech, for your help!

Post Reply