Check Sophos Firewall User-ID Limit and VPN Portal Downloads

When users in the VPN Portal cannot download .ovpn configurations or individual portal and authentication functions unexpectedly fail, the first thought is often SSL VPN, group membership, MFA, or a certificate issue. This is often correct. However, there is a less obvious point: the internal User IDs of the Sophos Firewall.

Sophos Firewall uses a limit of 65,535 User IDs, shared between users and groups. Users can be created beyond this limit, but users with a higher assigned ID may experience functional issues. A typical example is .ovpn configuration files that can no longer be downloaded from the VPN Portal.

This article helps to contextualise the issue without hastily deleting users or overhauling the VPN configuration.

When this issue is suspicious

The User-ID limit is not a standard error in small environments. It becomes relevant mainly when many users, groups, or external directory objects have been created on the firewall over the years.

Typical indications:

• A user can log in to the VPN Portal but cannot download the .ovpn file.
• Only individual users are affected, while other users with the same VPN configuration are not.
• The SSL-VPN policy, group membership, and MFA appear correct.
• There are many users in Authentication > Users.
• AD, LDAP, RADIUS, or Entra ID logins have been used over a long period.
• Old users or groups have never been cleaned up.
• An issue occurs after migration, directory restructuring, or many test users.

If the VPN tunnel is established but no traffic flows afterwards, this is a different error pattern. In that case, DNS, firewall rules, routing, NAT, or return path are more likely. For this process, see Set up Sophos SSL VPN with Sophos Connect on Windows or the respective platform guide.

What User IDs are on the Sophos Firewall

The Sophos Firewall manages users and groups internally with IDs. These IDs are not the same as an Active Directory SID, an Entra Object ID, or a username, but an internal assignment of the firewall.

Important points:

• The limit applies jointly to users and groups.
• External directory users do not necessarily appear immediately as local users.
• Users from external directories often appear under Authentication > Users only when they log in to a firewall service, such as the User Portal or VPN Portal.
• Deleted or inactive users and groups should be regularly cleaned up so that IDs can be reused.

In environments with Active Directory, the AD connection itself should be clean first. The process is described in Connect Active Directory with Sophos Firewall. If users are transparently recognised via Windows logons, Set up STAS on Sophos Firewall is also relevant.

Check before deleting

User and group cleanup is an administrative intervention. It should be clear beforehand which objects are really no longer needed.

You should check:

⚠️ Users and groups should not be blindly deleted just because there are many entries. First, check whether the object is still used in policies, rules, portal accesses, or authentication processes.

Systematically narrow down

1. Compare affected users

First, compare a functioning and an affected user:

• same authentication server
• same VPN or portal group
• same MFA requirement
• same SSL-VPN policy
• same access to the VPN Portal
• same client and browser path

If only a new or rarely used user is affected while older users work, the internal User-ID assignment becomes more interesting.

2. Check user list

In WebAdmin:

Authentication > Users

Check there:

• How many users are visible?
• Are there many old local users?
• Are there test accounts, former employees, or technical accounts without purpose?
• Are users from external directories automatically created at portal logins?
• Are groups imported that are not used on the firewall?

Depending on the environment, an export or a documented list can also help, so that cleanups do not happen on a whim.

3. Limit group import

Many problems do not arise from individual users but from overly broad group imports. If many groups are imported from Active Directory or another directory, objects quickly end up on the firewall that are never needed for rules, VPN, or portals.

Under:

Authentication > Servers

check which external servers are connected and which groups have been imported. For firewall and VPN purposes, a small number of clearly named groups, such as for Remote Access, admin access, or user rules, is usually sufficient.

4. Clean up inactive objects

Once it is clear which users or groups are no longer needed, the cleanup can be planned.

Sensible procedure:

1. Document affected users, groups, and policies.
2. Identify old local test users and no longer needed groups.
3. Before deleting, check whether objects are used in firewall rules, VPN policies, or portal accesses.
4. Perform a small cleanup, do not delete hundreds of objects without control.
5. Test again at the VPN Portal with an affected user.
6. Document the result.

If external directory users are recreated at the next login, the source must be adjusted. Otherwise, the firewall will only be cleaned up temporarily.

Check VPN Portal download separately

The User-ID limit is only one possible cause. For .ovpn download issues, you should also check the normal remote access points:

• User is allowed to use SSL VPN.
• User is a member of the correct group.
• VPN Portal is accessible via Administration > Device access.
• MFA or OTP works.
• Portal certificate is trustworthy.
• SSL-VPN configuration is current.
• Browser does not block the download.
• User downloads the current file, not an old copy.

For understanding User Portal, VPN Portal, and other Sophos accesses, see Sophos Portals: SophosID, Central, Support, and Firewall Access. For hardening portal access, see Device Access and Local Service ACL on Sophos Firewall.

If Entra ID SSO is involved

With Microsoft Entra ID SSO, do not confuse the User-ID issue with Conditional Access, OAuth, or Redirect URI errors. If login, redirect, and MFA already fail, the problem likely lies before the actual VPN download.

A clear distinction saves a lot of time:

Only when the login fundamentally works, but certain portal or download functions fail, is it worth looking at internal user objects and User IDs. The Entra-specific setup is described in Set up Microsoft Entra ID SSO for Sophos Connect and VPN Portal.

Practically, compare an affected user with a functioning user: same Entra group, same Remote Access policy, same portal login, same client path, and same permission on the firewall. If UPN, email address, or group mapping do not match, clean up the Entra SSO trail first. If these points match and only the .ovpn download or a portal action fails, the internal User-ID issue becomes more plausible.

It is also important to clean up: Entra users or imported groups should not be blindly deleted if they are still allowed for Remote Access. Otherwise, they will reappear at the next portal login or the next group import. It is better to first narrow down the allowed groups cleanly and then only remove firewall objects that are truly no longer needed. For profile and provisioning topics, see Configure Sophos Connect on Sophos Firewall.

Operational recommendation

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

• Only bring necessary AD/LDAP/Entra groups onto the firewall.
• Regularly remove former local users.
• Delete test accounts after projects.
• Regularly check group memberships for Remote Access.
• Document which groups are productively used for VPN, firewall rules, and portals.
• Plan a short authentication and VPN portal test after directory restructures.

The goal is not to use the firewall as a complete identity management system. The firewall should only know the identities it really needs for policies, portals, VPN, and reporting.

Troubleshooting checklist

FAQ