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] [IP-Router] 2020/03/26 11:31:10,482 Devicetime: 2020/03/26 11:31:08,699 IP-Router Rx (INTERNET, RtgTag: 10): DstIP: , SrcIP: , 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: , SrcIP: , Len: 56, DSCP: CS0/BE (0x00), ECT: 0, CE: 0 Prot.: ICMP (1), network unreachable embedded IP header: DstIP: , SrcIP: , Len: 42, DSCP: CS0/BE (0x00), ECT: 0, CE: 0 Prot.: UDP (17), DstPort: 1194, SrcPort: 1194 [/code] the things in are all true IPv4 addresses For the I only assume it is a generic one... tbh I can't really explain what it is... but it is from this range: [url]https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=62.155.128.0%20-%2062.155.247.255&type=inetnum[/url] 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): [oconf=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 -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- [/oconf] 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...) [oconf=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 [/oconf] 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 :) )

Please post your server log at --[b]verb 4[/b] showing the failed connection attempts.

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] Thu Mar 26 22:59:59 2020 us=908316 (37109) SENT CONTROL [/::ffff:/::ffff:]: '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 (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 (48718) MULTI: bad source address from client [::], packet dropped [/code] (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.

[quote=boronian post_id=90468 time=1585262155 user_id=49725] MULTI: bad source address from client [::], packet dropped [/quote]This is safe to ignore.

[quote=boronian post_id=90476 time=1585304199 user_id=49725] Fri Mar 27 10:57:07 2020 us=973619 ::ffff::53917, sid=12121212 12121212 Fri Mar 27 10:58:08 2020 us=8945 ::ffff:(53917) [b]SYNO_ERR_CERT[/b] Fri Mar 27 10:58:08 2020 us=12464 ::ffff:

Protocol error: [list][*]Server: proto udp6 [*]Client: proto udp[/list] I would use `proto udp` for both.

[quote=TinCanTech post_id=90483 time=1585311858 user_id=37053] Protocol error: [list][*]Server: proto udp6 [*]Client: proto udp[/list] I would use `proto udp` for both. [/quote] OOOh! I am trying that currently! :idea:

TLS handshake fails for certain clients

boronian

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

TinCanTech

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

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?

TinCanTech

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

boronian

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:

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

boronian wrote MULTI: bad source address from client [::], packet dropped

This is safe to ignore.

boronian

here is the relevant part of the server log:

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

boronian wrote 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

Protocol error:

Server: proto udp6
Client: proto udp

I would use `proto udp` for both.

boronian

TinCanTech wrote 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/comments/2cak67/question_how_to_disable_ipv6_on_client_andor/

Cheers!

boronian

TinCanTech wrote Protocol error:
Server: proto udp6

Client: proto udp
I would use `proto udp` for both.

OOOh! I am trying that currently! :idea:

boronian

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!