VPN300: Issues with SSL VPN connection through SecuExtender - mismatched account/user in syslog

Hi,

we are experiencing issues with the SSL VPN access to our VPN300.
1. Sometimes the SecuExtender software does not react when the user clicks the "Connect" button (and also nothing shows up in the Syslog / log on the VPN300 device).
2. Strangely, sometimes the button starts the connection process and we get a message in the syslog that looks like this: 

[...] vpn300 src="192.168.178.34:0" dst="external IP of our VPN300" msg="Failed login attempt to Device from http/https (incorrect password or inexistent username)" note="Account: felix" user="unknown" [...]
[...] vpn300 src="192.168.178.34" dst="0.0.0.0:0" msg="Failed login attempt to SSLVPN from http/https (incorrect password or inexistent username)" note="Account: felix" user="CAROLINE" [...]

The Secuextender is configured to connect to a subdomain that forwards to our VPN300's external IP address. SSL Certificate is set for that subdomain. The port to connect to is set like this in the server line [servername]:[port number]. This works most of the time for most of our users - also for the user, who produced above syslog with their last (non connecting) login. We authenticate the users with our AD. However, there appears to be an issue due to the incorrect "user" in the syslog - the Account:felix and the mismatching user is then "CAROLINE" (who is another one of our SSL VPN users who was connected simultaneously). 

Firmware on the VPN300 is V5.20(ABFC.0). 

Does anybody know what we can do to resolve this?

Thank you in advance and best wishes,
Jan

All Replies

  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,361  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    edited January 2022
    Hi @japande
    You may make sure if password characters of "felix" and "CAROLINE" are belonging to ASCII code.
  • Hi Stanley,
    Thank you for your reply.
    I have reset their passwords myself to make sure that they don't use non-ASCII code symbols but the problem persists.
    In the meantime, I received an answer to my support ticket which suggested setting the AD as first auth. method in Objects > Auth-method, which I did - but this also did not solve the problem.

    Just a few minutes ago I had the issue that my connection timed out as I did not provide the second factor in time and I was unable to connect again with the same credentials that were still in the SecuExtender. It worked again after I had quit and restarted the SecuExtender software. My unsuccessful login attempts were marked as "incorrect password" in the VPN300 log - even though I had not changed them since the first successful connection.

    Thanks and best wishes,
    Jan
  • Hi,
    we are still experiencign the same issue - users can't log in and the log shows note="Account: Jan" user="unknown" or note="Account:Jan" user="CAROLINE" - any idea how to fix this?
    Thanks and best wishes,
    Jan
  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,361  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Hi @japande
    You can have a check:
    (1) Operate a Test for your AD account in AAA setting.
    -> It should reply "OK"

    (2) Login your AD account in web portal.
    ->It should able login to session page success.

    Have a check if both of result are success. It could figure out the issue is not come from AD authentication issue.
  • Hi, 

    Thank you for your advice. AD testing reports "OK" - my colleagues and I can already successfully use the SecuExtender in ~75% of cases but in some cases, the secu extender appears to transmit incorrect data for the user name. Session success is shown when I log in to the VPN300 with my domain credentials.

    Thanks and best wishes,
    Jan
  • MPM
    MPM Posts: 1
    First Comment

    Jan, have you ever fixed the problem?
    I had excatly the same issue but in our case, we could not login at all. After some investigation hit & try I figured out that the problem is caused by having a too long name for your AD Security Group. After shorten that specific Group Name, it works as it should!
    regards
    Mike

Security Highlight