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
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):
remote YOUR_SERVER_IP 1194 ##YOUR_SERVER_IP is a true IPv4 adress I don't like to share
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...)
push "route 10.8.0.0 255.255.255.0"
management 127.0.0.1 1195
server 10.8.0.0 255.255.255.0
keepalive 10 60
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
status /tmp/ovpn_status_2_result 30
Please excuse me if I didn't test an obvious thing... I only know about OpenVPN since 2 days (and it's awesome )