Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 7 subscribers
  • Views 2980 views
  • Users 0 members are here
Options
Suggested
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

dwmtractor

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.
  • 0

    Which version Up2Dates did you apply?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0

    Those updates before 9.714 also affect SSL VPN by changing to the Sophos Connect client from the old VPN client.  You can try that and see if it works for you. Old client was still usable, but it's EoL.

    OPNSense 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | ATT Fiber 1GB
    (Former Sophos UTM Veteran, Former XG Rookie)

  • 0 in reply to BAlfson

    I can't find a log that states ... if you can point me to the log I can confirm for sure ... but it's presently at 9.714-4, so I believe the updates were that and 9.714-3

  • 0 in reply to Amodin

    I have tried it with both.  My laptop was using the old client until this failed; and when it failed, the first thing I tried was updating to the current client.  Got the same error both ways.

  • +1

    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.

Unfiltered HTML