• The issue I'm encountering is that, no changes have been made to the firewall in several weeks.
    Current situation:

    1. Only 3 users use OpenVPN.
    2. Only 1 user can connect to Pfsense using OpenVPN. 1 single user is able to consistently connect.
    3. I have deployed the Pfsense configured Client, and still get the same error. I plan on bouncing the firewall after office hours tonight.
      I restarted the OpenVPN Service.
      But would like some input as to why this may be happening. I've read different solutions however none have been effective and since I have a single user who's consistently able to connect I'm not sure what else it could be. (Software firewalls have been disabled on windows workstations that access remote network via VPN. Any help is greatly appreciated.
      I have attempted the default remedies such as turning off firewall etc. None of the suggested resolutions have worked.
      Could it be the .p12 and .key files that cause the issue? Any help is greatly appreciated.

    Mon Aug 17 14:24:18 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020 Mon Aug 17 14:24:18 2020 Windows version 6.2 (Windows 8 or greater) 64bit Mon Aug 17 14:24:18 2020 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10 Enter Management Password: Mon Aug 17 14:24:20 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194 Mon Aug 17 14:24:20 2020 UDPv4 link local (bound): [AF_INET][undef]:0 Mon Aug 17 14:24:20 2020 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194 Mon Aug 17 14:25:20 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Mon Aug 17 14:25:20 2020 TLS Error: TLS handshake failed Mon Aug 17 14:25:20 2020 SIGUSR1[soft,tls-error] received, process restarting Mon Aug 17 14:25:25 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194 Mon Aug 17 14:25:25 2020 UDPv4 link local (bound): [AF_INET][undef]:0 Mon Aug 17 14:25:25 2020 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194 Mon Aug 17 14:26:25 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Mon Aug 17 14:26:25 2020 TLS Error: TLS handshake failed Mon Aug 17 14:26:25 2020 SIGUSR1[soft,tls-error] received, process restarting Mon Aug 17 14:26:30 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194 Mon Aug 17 14:26:30 2020 UDPv4 link local (bound): [AF_INET][undef]:0 Mon Aug 17 14:26:30 2020 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194 Mon Aug 17 14:27:30 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Mon Aug 17 14:27:30 2020 TLS Error: TLS handshake failed Mon Aug 17 14:27:30 2020 SIGUSR1[soft,tls-error] received, process restarting

  • LAYER 8 Rebel Alliance

    Not easy to read your log if you post it like this...
    That error is really generic and mostly connectivity related, as the message says.
    Could be routing/peering issue between the Users ISP and the ISP you have on the server side. Are both users with this error all using the same ISP?
    How does a traceroute look from a working and not working client?

    -Rico


  • Hi,

    You should reformat that spaghetti - right now, it close to unreadable.

    Example :

    Aug 21 16:18:37 	openvpn 	32591 	TLS Error: tls-crypt unwrapping failed from [AF_INET]157.230.182.101:59272
    Aug 21 16:18:37 	openvpn 	32591 	tls-crypt unwrap error: packet too short
    Aug 21 16:18:36 	openvpn 	32591 	TLS Error: tls-crypt unwrapping failed from [AF_INET]157.230.182.101:59271
    Aug 21 16:18:36 	openvpn 	32591 	tls-crypt unwrap error: packet too short
    Aug 21 15:16:22 	openvpn 	32591 	Initialization Sequence Completed
    Aug 21 15:16:22 	openvpn 	32591 	UDPv4 link remote: [AF_UNSPEC]
    Aug 21 15:16:22 	openvpn 	32591 	UDPv4 link local (bound): [AF_INET]192.168.10.3:1194
    Aug 21 15:16:22 	openvpn 	32591 	/usr/local/sbin/ovpn-linkup ovpns1 1500 1621 192.168.3.1 255.255.255.0 init
    Aug 21 15:16:22 	openvpn 	32591 	/sbin/ifconfig ovpns1 inet6 2001:470:ccea:3::1/64
    Aug 21 15:16:22 	openvpn 	32591 	/sbin/ifconfig ovpns1 192.168.3.1 192.168.3.2 mtu 1500 netmask 255.255.255.0 up
    Aug 21 15:16:22 	openvpn 	32591 	ioctl(TUNSIFMODE): Device busy (errno=16)
    Aug 21 15:16:22 	openvpn 	32591 	TUN/TAP device /dev/tun1 opened
    Aug 21 15:16:22 	openvpn 	32591 	TUN/TAP device ovpns1 exists previously, keep at program end
    Aug 21 15:16:22 	openvpn 	32591 	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    Aug 21 15:16:22 	openvpn 	32591 	GDG: problem writing to routing socket
    Aug 21 15:16:22 	openvpn 	32421 	library versions: OpenSSL 1.0.2u-freebsd 20 Dec 2019, LZO 2.10
    Aug 21 15:16:22 	openvpn 	32421 	OpenVPN 2.4.9 amd64-portbld-freebsd11.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on May 4 2020
    

    It looks like a client VPN log.
    Where is the OpenVPN server log ? (the one at the same moment as when the client tries to connect).

    Test your xxx.xxx.xxx.xxx:1194 reachability from the client's side by using, for example, https://www.ipvoid.com/udp-port-scan/


  • maybe should upgrade openssl to 1.1.1+