Today we came accross the issue with multiple live users, that Connect client deployed with pro file, does not work when the user has a password beginning with #
Like with space/blank known not working. https://community.sophos.com/sophos-xg-firewall/f/discussions/129828/sophos-connect-client-2-1-20-0309---password-with-spaces-in-it-fails-login
When deployed with the pro file, the client can connect to the userportal and it downloads the protected file. Can see the change in file size and in the XG log file that the user logged in to userportal.
But after it connects to the firewall, it never get's there. Just does nothing while showing "authenticating"
May I know if there is a list of password characters and combinations not working?
I could lough at it if it was'nt so serious. What a joke of a program.
@emmosophos you say that the issue is resolved in version 2.2, yet the current active version on the website (https://www.sophos.com/en-us/support/downloads/utm-downloads) is still 2.1.20 for Windows.…
We have found another case where the inclusion of a single carat (^) in the password caused a similar issue. Changed to another symbol, and the login worked normally.
thanks for replying to this issue.
Can you provide more details please?
I have tested ^ at the end and in the middle of a password and it worked with SSL VPN.
I have 2FA enabled for the test account.
10-character password. The only symbol in the password was a ^ in position 8. Changed the ^ to a $, and the password worked without any other changes.
The password was accepted by the XG User Portal - we could log in just fine. Account also had 2FA enabled.
We re-created the user's account several times during testing, always using the same password (containing ^ in the position specified above).
Sophos Client Connect would not successfully initiate the VPN until we made the change to the password, however.
Also - we tested the Legacy Sophos VPN Client and it accepted the password with the ^ in it. Only SCC had problems with this password.
tested it with PW: ABcdefg^12
and it worked.
is it local or LDAP user?
Tue Jun 21 15:46:10 2022 OpenVPN 2.5.0 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 6 2020
Tue Jun 21 15:46:10 2022 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jun 21 15:46:10 2022 library versions: OpenSSL 1.1.1e 17 Mar 2020, LZO 2.10
Enter Management Password:
Tue Jun 21 15:46:10 2022 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Tue Jun 21 15:46:10 2022 Need hold release from management interface, waiting...
Tue Jun 21 15:46:10 2022 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'state on'
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'log all on'
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'echo all on'
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'bytecount 5'
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'hold off'
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'hold release'
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'username "Auth" testuser'
Tue Jun 21 15:46:11 2022 MANAGEMENT: CMD 'password [...]'
Tue Jun 21 15:46:11 2022 MANAGEMENT: >STATE:1655819171,RESOLVE,,,,,,
Tue Jun 21 15:46:11 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.17:443
Tue Jun 21 15:46:11 2022 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Jun 21 15:46:11 2022 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.17:443 [nonblock]
Tue Jun 21 15:46:11 2022 MANAGEMENT: >STATE:1655819171,TCP_CONNECT,,,,,,
Tue Jun 21 15:46:12 2022 TCP connection established with [AF_INET]xxx.xxx.xxx.17:443
It was a local user.
same password with a local user worked here, too. Strange you could rule it out to the password with ^ .
so it is this one, right? https://theasciicode.com.ar/ascii-printable-characters/circumflex-accent-caret-ascii-code-94.html
If it helps, the final three characters of the password were ^Az. Not sure if a parser might interpret those in any specific way.
We found another user at the same client. Had $ as the final character in their password. Techs had to downgrade him from Sophos Client Connect back to the old Sophos VPN client, as a workaround.