Check the Sophos Firewall User-ID Limit and VPN Portal Downloads

If a user can sign in to the VPN Portal but cannot download an .ovpn configuration, the cause is often the SSL VPN permission, MFA, or the browser. In large environments or those that have grown over many years, however, there is another less obvious possible cause: the internal User ID of Sophos Firewall.

Sophos Firewall supports a maximum of 65,535 User IDs, shared between users and groups. You can check directly in WebAdmin whether a specific user is affected. According to the Sophos Firewall documentation, users with an ID above 65535 are no longer authenticated and may therefore fail when downloading the .ovpn file, among other functions.

This article explains how to verify this error pattern and clean up user management without prematurely deleting production accounts, groups, or MFA assignments.

When to Suspect the User-ID Limit

The limit is not a typical problem in small environments. It becomes relevant when many local accounts, external users, or imported groups have accumulated on the firewall over the years.

The following combination is particularly suspicious:

• The user can sign in to the VPN Portal, but the .ovpn file is missing or cannot be downloaded.
• Only individual users are affected, even though their group and Remote Access policy are identical.
• Newer users fail while older accounts continue to work.
• There are many old objects under Authentication > Users or Authentication > Groups.
• Test accounts, former employees, or directory groups that are no longer needed have never been cleaned up.

If all users are affected or the sign-in fails before the portal is reached, first check the authentication server, MFA, Device Access, and the Remote Access policy. If the tunnel is established but no traffic flows afterwards, the problem is more likely to involve firewall rules, routing, DNS, NAT, or the return path.

What the Internal User ID Means

The User ID discussed here is an internal numeric assignment on the firewall. It is neither an Active Directory SID nor a Microsoft Entra Object ID, and it is unrelated to the Synchronized user ID authentication feature.

Four properties are important for diagnosis:

• Users and groups share the same range of up to 65535 IDs.
• Users can be created beyond this limit, but the firewall can no longer authenticate them if they have a higher ID.
• Users from external authentication servers often appear under Authentication > Users only after they sign in to a firewall service such as the User Portal or VPN Portal for the first time.
• Sophos recommends regularly deleting users and groups that are no longer required or are inactive so that their IDs can be reused.

The number of visible users alone therefore proves nothing. Groups also occupy IDs, and the numbering may contain gaps. The assigned ID of the affected user is what matters.

Check a User’s User ID

The specific ID is visible in WebAdmin:

1. Open Authentication > Users.
2. Select Show additional properties.
3. Find the affected user in the displayed User ID column.
4. Compare their ID with that of a working user in the same group and Remote Access policy.

The result is unambiguous:

• User ID up to 65535: The documented limit has not been exceeded for this user. Continue with the standard VPN, portal, and authentication diagnosis.
• User ID above 65535: The user object is outside the supported range. Plan a clean-up and then retest the user in a controlled manner.
• User is missing from the list: The external user may never have signed in successfully to a firewall service. Check the actual sign-in path first.

⚠️ A large number of user objects is only an indication. Only the User ID column shows whether the specific user has exceeded the limit.

Check Dependencies Before Deleting Objects

Cleaning up users and groups is an administrative change. An object may still be required for Remote Access, rules, or authentication even if it initially appears old.

Before deleting an object, check the following:

• Remote Access: Is the user or group permitted in an SSL VPN or IPsec policy?
• Firewall rules: Is the object used as a user criterion?
• Portals: Does the User Portal or VPN Portal depend on this group?
• MFA: Does the user have an OTP or token assignment?
• Group logic: Is the object a production user’s primary group or an additional group membership?
• Directory source: Will the object be recreated during the next sign-in or group import?

Before a larger clean-up, make sure that a current backup is available. A documented list of the objects to be removed is also more appropriate than deleting objects in bulk based on age or name.

Clean Up Users and Groups in a Controlled Manner

Clean Up Active Directory Users

Sophos describes a clear process for AD users who are no longer required:

1. First remove the user who is no longer required from Active Directory.
2. Open Authentication > Users.
3. Run Purge AD users to remove local records for AD users who no longer exist.
4. In an HA cluster, confirm that the process completed as expected. Sophos performs the deletion on both the Primary and Auxiliary Device.

Purge AD users is not a substitute for correct permissions in Active Directory. If a user remains present there, their record may be recreated on the firewall during a subsequent sign-in.

Clean Up Local Users and Imported Groups

Remove local test accounts and groups that are no longer required specifically under Authentication > Users and Authentication > Groups, respectively. Work in small, traceable steps:

1. Identify objects that are no longer required and document their dependencies.
2. First delete clearly obsolete test accounts and unused groups.
3. After each small clean-up step, check the user list and production sign-ins.
4. Under Authentication > Servers, restrict broad group imports to the VPN, portal, and rule groups that are actually required.

If the affected production user has an ID above 65535, do not blindly delete their record. First, enough unused IDs must be released, and all group, policy, and MFA dependencies must be documented. Sophos describes the reuse of available IDs, but not the automatic renumbering of an existing user object. If the high ID remains or it is unclear how to recreate the record safely, opening a Sophos Support case is more appropriate than repeatedly deleting production identities.

Test After the Clean-Up

The clean-up is not complete until the original error is reproducibly resolved:

1. Sign in to the VPN Portal again as the affected user.
2. Check the assigned User ID under Authentication > Users > Show additional properties.
3. Download the .ovpn configuration again.
4. If the download works, import the profile into Sophos Connect or the client in use and test the connection.
5. If the download still fails, check the standard portal and Remote Access causes.

For the SSL VPN configuration and client workflow, see Configure Sophos Connect on Sophos Firewall and Set Up Sophos SSL VPN with Sophos Connect on Windows.

Other Causes of Failed Downloads

Portal downloads can also fail when the User ID is within the supported range. In that case, the following points are particularly relevant:

• The user or primary group is not permitted in the appropriate SSL VPN policy.
• The VPN Portal is not accessible from the source zone under Administration > Device access.
• MFA or OTP fails.
• The portal certificate is not trusted.
• The browser or endpoint protection blocks the download.
• With Entra ID SSO, the imported group, Allowed users and groups, UPN, or redirect configuration does not match.

For Entra sign-in errors, see Set Up Microsoft Entra ID SSO for Sophos Connect and VPN Portal. For portal hardening and accessibility, see Device Access and Local Service ACL on Sophos Firewall.

Prevent User-ID Problems in Operation

In larger environments, user hygiene should be part of firewall operations:

• Import only directory groups that are actually required for VPN, portals, rules, or user policies.
• Regularly remove former local users and project accounts.
• After directory restructuring, check which old user and group objects remain on the firewall.
• For unusual portal errors, check the User ID column early instead of immediately reconfiguring VPN or certificates.
• Document production groups, primary groups, and MFA dependencies so that future clean-ups can be performed in a controlled manner.

The firewall should know only the identities that it actually needs for policies, portals, Remote Access, and reporting. It is not a substitute for a clean identity lifecycle in the directory service.

FAQ