OpenVPN won't connect to Win10 client

[chazz]

Running OpenVPN on a 64-bit Untangle server that is directly connected to the internet (static IP). The external address reported on the OpenVPN server page is pingable from outside, there is no other hardware apart from a cable modem set to Bridged mode. The client is a fully updated 64-bit Windows 10 Home laptop connected to the internet through a Linksys EA2700 home router and a DSL modem. I have installed the OpenVPN client and started it. It complains about two settings in the config file (num_connections and ns-cert-type), and tries to connect. On the server status page, I see the UDP AppSession requests number increase. The client times out, restarts, and I see the UDP AppSessions increase again. However, the server never picks up. The AppSessions increase leads me to believe that the UDP packets are making it through to the server, but I have no explanation as to why the connection is not being established.

The server is on one ISP (Shaw), the client is on another (Telus). The client is running Avast free antivirus. I can tracert from the client to the server with no problem.

I have already tried things suggested in the OpenVPN forums: disabling the Windows firewall, disabling Avast, removing and reinstalling the TAP-Windows driver, disabling IPv6. I'm open to any other suggestions...

[jcoffin]

Was the OpenVPN Windows client generated by the Untangle or download from OpenVPN website?

[chazz]

It was generated by Untangle. I also had it create an inlined profile, and tried connecting with the inlined profile by right-clicking on it.

[jcoffin]

Did you install the Untangle Windows Client as administrator (right click select run as admin)? Avast does block OpenVPN BTW. I know you tried with it off but there might be multiple issues.

[chazz]

I did not, but it did pop up the "Administrative permission is required to install this" message, and I accepted that. I can of course uninstall and reinstall in admin mode, but since it forces itself to admin mode anyway that seems somewhat pointless.

[jcoffin]

Yeah, that is the same.

Can you post the entire log from the client?

[chazz]

Of course. It's not particularly enlightening, though:

Sat Jun 30 17:54:04 2018 OpenVPN 2.4.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jul 14 2017
Sat Jun 30 17:54:04 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Sat Jun 30 17:54:04 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Enter Management Password:
Sat Jun 30 17:54:05 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]184.71.158.234:1194
Sat Jun 30 17:54:05 2018 UDP link local: (not bound)
Sat Jun 30 17:54:05 2018 UDP link remote: [AF_INET]184.71.158.234:1194
Sat Jun 30 17:55:05 2018 [UNDEF] Inactivity timeout (--ping-restart), restarting
Sat Jun 30 17:55:05 2018 SIGUSR1[soft,ping-restart] received, process restarting
Sat Jun 30 17:55:10 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]184.71.158.234:1194
Sat Jun 30 17:55:10 2018 UDP link local: (not bound)
Sat Jun 30 17:55:10 2018 UDP link remote: [AF_INET]184.71.158.234:1194
Sat Jun 30 17:56:10 2018 [UNDEF] Inactivity timeout (--ping-restart), restarting

And repeat indefinitely until stopped.

[jcoffin]

Ping is failing to the remote site. Is ping response turned off at the remote site?

https://forums.openvpn.net/viewtopic.php?t=24874

[chazz]

I'm sorry, I don't understand. The client can ping the server, as I mentioned at the head of this thread. Are you saying the server also needs to be able to ping the client?

Edit: Also, the link you posted seems to talk about ping failing after the connection is established. In this case, the connection is never established, so it doesn't quite fit...

Edit edit: Further, I have confirmed that the server can ping the client, and I have uninstalled Avast and retried the connection. Still no joy.

[chazz]

Following advice in another thread, I moved the active port to 11194: this involved changing the setting in the Advanced page of the OpenVPN settings in Untangle, explicitly opening the port in Untangle's firewall, and changing three port values in the client config file. When little seemed to be happening, I tried the TCPDUMP trick mentioned - Config | Network | Troubleshooting | Packet Test. Here's what I saw:

Mon Jul 02 2018 10:10:07 GMT-0700 (Pacific Daylight Time) - Test Started
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

10:10:24.731643 IP 173.183.113.165.49912 > 184.71.158.234.11194: UDP, length 14
10:10:59.521662 IP 173.183.113.165.49913 > 184.71.158.234.11194: UDP, length 14
10:11:01.625953 IP 173.183.113.165.49913 > 184.71.158.234.11194: UDP, length 14
10:11:05.702716 IP 173.183.113.165.49913 > 184.71.158.234.11194: UDP, length 14
10:11:13.062071 IP 173.183.113.165.49913 > 184.71.158.234.11194: UDP, length 14
10:11:29.234161 IP 173.183.113.165.49913 > 184.71.158.234.11194: UDP, length 14
10:12:04.172244 IP 173.183.113.165.58119 > 184.71.158.234.11194: UDP, length 14
10:12:06.302488 IP 173.183.113.165.58119 > 184.71.158.234.11194: UDP, length 14
Mon Jul 02 2018 10:12:08 GMT-0700 (Pacific Daylight Time) - Test Completed

--------------------------------------------------------

I don't know enough about OpenVPN to know if a 14-byte packet is enough for connection. I can confirm that the address listed as the source for these packets is my client machine. But this would indicate strongly that the ISPs aren't doing DPI to murder OpenVPN packets.

For my next trick, I'm going to set everything back to default and try again. Oh - Untangle 13.2.1, by the way.