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

AD Integration issue with long domain name, possible bug ?

We have a case open for this with support but wondering if anyone else can shed any light as progress seems to have stalled.

We have a customer with a long AD domain name e.g. companydomain.companywebsite.co.uk and have just installed an XG230 + SSL VPN using Sophos Connect 2.0.

We have found that some users when connecting, cannot connect by the SSL VPN (using AD integration for authentication).

Looking at the logs, it seems to indicate TLS negotiation errors for the affected users but others can connect fine.

During our testing, we believe there may be an issue due to the domain length causing issues.

On the client, when they try to connect, they get an 'Policy Mismatch Error' or they get a connection failed (generic type) error.

The user can access the user portal fine but either SSL VPN Client or Sophos Connect 2.0 client both fail to connect with same behaviour.

In the logs, we have seen messages in the vpn client log like the below

Sat Oct 3 16:25:42 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sat Oct 3 16:25:42 2020 TLS Error: TLS handshake failed

We've also seen errors like the below in the firewall log, which we feel may have highlighted the actual issue being to do with the username / least the length of the string.

CN=firstname.surname@companydomain.companywebsite.co.uk_173E6175DDF, emailAddress=thexg@companydomain.co.uk') -- note that the username length is limited to 64 characters

Now, the users actual user logon name is well under 64 characters but when you take the domain name into account and include the suffix added at the end by the client/firewall, it actually is 64 characters long and seems to break something and fails to connect.

During testing for the customer, I found that if the CN was 64 or 63 characters long, it seems to break the setup and the VPN won't connect.

We've seen that most of the users who are affected are around 63 - 65 characters long for this CN string whereas the usernames are 14 - 15 characters long themselves.

I've not got another device to test on a lab domain with a similar length (37 chars for the ad domain name) to verify this on a clean setup but we're running out of ideas.

It could be a red herring but the fact I can change the username to 1 character shorter and it works - note, there are no spaces, special characters or umlauts in the usernames.

Ideally, we don't want to rename the domain as the knock on effect is huge but I'm not sure what else we can do at this point.

Any ideas ?



This thread was automatically locked due to age.
Parents
  • There are some unanswered posts in the openvpn community about this exact use case. Not sure what to do about it, if the CN is longer than 64 characters, because it seems to be a limitation in the openvpn module. 

    What about IPsec? Are all users "that long"? So maybe you could switch for those users to Ipsec in Sophos Connect? 

Reply
  • There are some unanswered posts in the openvpn community about this exact use case. Not sure what to do about it, if the CN is longer than 64 characters, because it seems to be a limitation in the openvpn module. 

    What about IPsec? Are all users "that long"? So maybe you could switch for those users to Ipsec in Sophos Connect? 

Children
  • Not all of them but it's probably a 50/50 split.

    Weird thing is the CN is exactly 64 or 63 on some which are affected, with a few being 65 where I cod understand it being an issue.

    I'll give the IPsec a try but we'd ideally hoped to stick with the SSL due to less issues with ISP/Firewalls blocking etc, plus with the new provisioning file and group support, it would mean less admin in the long run.

    The other option would be we change the user login name as they can still login to everything else with UPN but might be a reasonable compromise if there isn't anything that can be done about it / not a 'bug'