This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN failed after system update in February

I have the Sophos UTM configured with a SSL VPN login that I've been using regularly for several years, logging in from 2 different clients.  The first is the Sophos UTM client itself on Windows 10 (current version, downloaded and reinstalled yesterday to be sure), the second is a gli.net mobile router with an OpenVPN client.

Sometime in February, I remember updating my UTM with two version updates ... it was the current version 9.714-4 and whatever was the update before that.  I didn't realize it till next time I tried to log in remotely, but one of these two updates must have broken the SSL VPN system.  Now when I try to log in the connection fails.

Just to be safe, I deleted and recreated my SSL certificate/config file before doing the following test.

Here's the log from the client (IP address obfuscated):

2023-03-21 17:34:48 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2023-03-21 17:34:48 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2023-03-21 17:34:48 OpenVPN 2.5.6 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 22 2022
2023-03-21 17:34:48 Windows version 10.0 (Windows 10 or greater) 64bit
2023-03-21 17:34:48 library versions: OpenSSL 1.1.1n 15 Mar 2022, LZO 2.10
2023-03-21 17:34:48 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
2023-03-21 17:34:48 Need hold release from management interface, waiting...
2023-03-21 17:34:48 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
2023-03-21 17:34:48 MANAGEMENT: CMD 'state on'
2023-03-21 17:34:48 MANAGEMENT: CMD 'log all on'
2023-03-21 17:34:48 MANAGEMENT: CMD 'echo all on'
2023-03-21 17:34:48 MANAGEMENT: CMD 'bytecount 5'
2023-03-21 17:34:48 MANAGEMENT: CMD 'hold off'
2023-03-21 17:34:48 MANAGEMENT: CMD 'hold release'
2023-03-21 17:34:48 MANAGEMENT: CMD 'username "Auth" xxx'  Note I obscured username
2023-03-21 17:34:48 MANAGEMENT: CMD 'password [...]'
2023-03-21 17:34:48 MANAGEMENT: >STATE:1679434488,RESOLVE,,,,,,
2023-03-21 17:34:48 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:443   Note obscured IP address here and below
2023-03-21 17:34:48 Socket Buffers: R=[65536->65536] S=[64512->64512]
2023-03-21 17:34:48 Attempting to establish TCP connection with [AF_INET]x.x.x.x:443 [nonblock]
2023-03-21 17:34:48 MANAGEMENT: >STATE:1679434488,TCP_CONNECT,,,,,,
2023-03-21 17:35:08 TCP: connect to [AF_INET]x.x.x.x:443 failed: Unknown error
2023-03-21 17:35:08 SIGUSR1[connection failed(soft),init_instance] received, process restarting
2023-03-21 17:35:08 MANAGEMENT: >STATE:1679434508,RECONNECTING,init_instance,,,,,
2023-03-21 17:35:08 Restart pause, 5 second(s)
2023-03-21 17:35:13 MANAGEMENT: Client disconnected
2023-03-21 17:35:13 All connections have been connect-retry-max (1) times unsuccessful, exiting
2023-03-21 17:35:13 Exiting due to fatal error

Meanwhile, here's the log for the same episode from the SSL log on the UTM itself:

2023:03:21-17:35:46 djwall openvpn[12983]: TCP connection established with [AF_INET]x.x.x.x:36773 (via [AF_INET]x.x.x.x:443)
2023:03:21-17:35:47 djwall openvpn[12983]: x.x.x.x:36773 Non-OpenVPN client protocol detected
2023:03:21-17:35:47 djwall openvpn[12983]: x.x.x.x:36773 SIGTERM[soft,port-share-redirect] received, client-instance exiting

I reemphasize -- all was working flawlessly on the same machines up until those updates.

I'd be really grateful for help in figuring out what's going wrong here.



This thread was automatically locked due to age.
Parents
  • OK so I'm a little embarrassed to report what turned out to be the problem.  It was never the VPN, it was dynamic DNS.  For reasons so far unclear to me, the UTM was failing to update the dyndns (in my case, No-IP) with the current IP of my network.  As a result, my connection was being attempted on some other hapless internet user whose system had no idea what I was doing.

    Once I fixed that, I found that the log showed some inconsistency in the authentication protocols, so I re-created my SSL user certificate and made sure it was updated with the correct security settings, then re-imported that certificate into my client.  All is now well.

Reply
  • OK so I'm a little embarrassed to report what turned out to be the problem.  It was never the VPN, it was dynamic DNS.  For reasons so far unclear to me, the UTM was failing to update the dyndns (in my case, No-IP) with the current IP of my network.  As a result, my connection was being attempted on some other hapless internet user whose system had no idea what I was doing.

    Once I fixed that, I found that the log showed some inconsistency in the authentication protocols, so I re-created my SSL user certificate and made sure it was updated with the correct security settings, then re-imported that certificate into my client.  All is now well.

Children
No Data