Set up and test Clientless Users on Sophos Firewall

A printer, server, or other fixed device often can’t sign in to the firewall. Clientless Users still give such traffic a meaningful identity: Sophos Firewall assigns a configured username to the visible source IP and can use this identity in rules, Live Users, and logs.

This isn’t authentication. Anyone who takes over the configured IP or appears behind the same NAT address can receive the same assignment. Clientless Users are therefore only suitable for devices with stable addresses that are under control. For changing personal devices, shared IPs, or privileged access, a real sign-in method is the better choice.

⚠️ Clientless Users aren’t Clientless SSL VPN. Clientless Users map an internal IP to an identity. Clientless SSL VPN, by contrast, publishes RDP, SSH, or file server bookmarks in the VPN Portal.

Clientless User in eight steps

1. Define the device, owner, required destinations, and the source IP visible to the firewall.
2. Configure the address statically or bind it unambiguously through a DHCP reservation.
3. Under Authentication > Groups, create a small group of type Clientless.
4. Under Authentication > Clientless users > Add, create exactly one pilot user with this IP.
5. Create a separate logged firewall rule with the exact source, Match known users, and the clientless group.
6. Check the user under Current activities > Live users and the real flow in Log Viewer.
7. Briefly set the user to Inactive and confirm that the identity rule no longer matches.
8. Reactivate the user, validate the rule again, and document the assignment, owner, and review date.

When Clientless Users are suitable

Clientless Users are useful when a firewall rule or report needs a stable device identity but the device can’t perform a user sign-in. Typical candidates are printers, monitoring appliances, lab devices, or tightly restricted infrastructure servers.

The feature is only suitable when all the following points are true:

• The firewall always sees the same unambiguous source IP for the traffic.
• The address is static or bound through a controlled DHCP reservation.
• The address doesn’t represent several devices behind NAT or a proxy.
• The identity only receives access to destinations and services that the device actually needs.
• Another device can’t take over the address without being noticed.
• A positive and negative test is possible with a real data flow.

For normal domain clients, STAS is usually more suitable. If network access already produces RADIUS Accounting, RADIUS SSO Accounting can build the user-to-IP assignment dynamically. The Captive Portal provides an interactive sign-in.

Clientless Users aren’t a shortcut for missing segmentation. A printer still belongs in an appropriate zone or separate network and needs a narrow rule. The IP-based identity supplements this control but doesn’t replace it.

How it works and the security boundary

Sophos Firewall lists an active Clientless User as a Live User without an interactive sign-in. When a packet matches the configured IP, the assigned username is available for user-based rules and reporting.

This doesn’t provide cryptographic proof of the device or person:

• There is no password and no second factor.
• The assignment doesn’t verify a personal Windows or Entra session.
• An IP change isn’t automatically interpreted as a device change.
• A shared NAT or proxy IP can’t distinguish individual endpoints.
• A Clientless User isn’t a remote access VPN user.

If rules must be person-specific, Clientless Users should only be used in well-controlled exceptional cases. For a person at a fixed workstation, the DHCP assignment must be stable, but the identity still makes a statement about the IP and not about the person at the screen.

Example and replaceable values

The workflow uses a printer that may only reach DNS, NTP, and an internal print server:

• Username: Printer-Accounting
• visible IP address: 192.0.2.50
• clientless group: Clientless-Devices
• firewall rule: Printer-Accounting_to_Services
• source network: host object Printer-Accounting_192.0.2.50
• destination: internal DNS/NTP service and the intended print server
• review: owner and next review date in the rule description

192.0.2.50 belongs to the official IPv4 documentation range and isn’t a production device address. Replace it with the fixed IP that the firewall sees as the source of the real flow. IPv6 requires a fixed IPv6 address, a separate IPv6 rule, and separate validation.

The example names show the purpose but aren’t product requirements. In a real environment, name the user, group, host object, and rule according to a consistent naming scheme.

Prepare the address and group

Confirm the visible source IP

Before configuring the identity, generate exactly one controlled data flow from the device. In Log Viewer or Packet Capture, record at least the source IP, In interface, destination, service, and previous Firewall Rule ID.

If the visible source is a NAT, proxy, or shared gateway address, stop here. Don’t assign this address to a single Clientless User. Otherwise, all devices behind it receive the same identity.

For DHCP, create a reservation for this exact device. Merely entering an unused pool address in the firewall isn’t enough: If the DHCP server later assigns it to another client, that client inherits the identity and potentially the rule permissions.

Create a clientless group

Under Authentication > Groups > Add, create a separate group:

1. Enter Clientless-Devices as Name.
2. Select Clientless as Group type.
3. Set only the required group policies.
4. Select Save.

User-specific policies take precedence over the policies of the assigned group. The group should therefore have a clear common baseline purpose. Document deviations for individual users and test them separately.

Clientless Users do not support Surfing quota, Access time, or Network traffic policy. If a fixed device should communicate only at specific times, use a schedule in the narrowly scoped firewall rule. Access Time for users and groups, in contrast, applies to regular users, groups, and guest users. Surfing quota and network traffic quota also require a supported user or group assignment.

Manage Sophos Firewall user groups and the main group correctly explains why Normal, imported, and Clientless groups represent different identity models. This article remains focused on the complete IP-based Clientless workflow.

Add a single Clientless User

Under Authentication > Clientless users > Add, set the fields as follows:

1. Username: Printer-Accounting
2. IP address: the fixed device address confirmed earlier
3. Group: Clientless-Devices
4. Name: a meaningful display name for the device
5. Email: enter a real responsible address only if it is needed for features such as Quarantine Digest
6. Quarantine digest: enable only deliberately; this feature will normally remain off for a printer
7. Select Save.

You can then open the user again and add supported user-specific settings. Only consider a change successful after Live Users, the rule match, and the real traffic are correct again.

Use Add range only with clear justification

Authentication > Clientless users > Add range creates individual Clientless Users for all addresses between From IP and To IP. Sophos assigns the selected group; each generated user can then be edited separately.

A normal DHCP pool isn’t a suitable candidate. A range would treat every address that is assigned later as a known identity in advance. Add range is only suitable for a fully reserved, documented address block with a common purpose, controlled assignment, and subsequent individual review. For the first rollout, Add with exactly one IP remains the safe option.

Create a narrow firewall rule

Understand and configure Sophos Firewall rules safely explains the general rule mechanics. For this example, create a separate rule above a more general printer or LAN rule:

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: enabled
• Source zone: the actual device zone
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: zone of the intended services
• Destination networks: only the DNS/NTP destination and print server
• Services: only the required ports
• Match known users: enabled
• Users or groups: Clientless-Devices or the individual pilot user

The source IP and user condition can deliberately be used together. The IP limits the technical origin, while the identity makes the rule and reporting understandable. A broad source of Any or destination of Any isn’t necessary for a fixed device.

After saving, confirm that a more general rule above it doesn’t match first. Only the Firewall Rule ID in Log Viewer or Packet Capture shows which rule processes the real flow. Test a Sophos Firewall rule provides the guided workflow.

Positive and negative test

Check the identity and permitted flow

1. Under Current activities > Live users, look for Printer-Accounting and the expected IP.
2. Generate exactly one intended flow from the device.
3. In Log Viewer, compare the user, source IP, Firewall Rule ID, rule name, service, and action.
4. Verify that the destination receives the request and the return path works.
5. Test an unintended service or destination and confirm the expected drop.

The Live Users entry alone isn’t enough. It confirms the active assignment but not the rule position, allowed service, or data path.

Use a status change as the negative test

Don’t sign out a Clientless User with Disconnect in Live Users. Under Authentication > Clientless users, select the pilot user and use Change status to set it to Inactive.

The user must then no longer appear as a Clientless User in Live Users. A new test connection must no longer match the user-based pilot rule with this identity. Then set the user back to Active and repeat the positive test.

This test must not result in an unexpected allow through a more general rule. If the connection is meant to remain permitted after deactivation, document and test the intended fallback rule as well.

Troubleshoot systematically

User is missing from Live Users

• Check that the status under Authentication > Clientless users is Active.
• Compare the configured IP with the source that is actually visible in the packet.
• Look for a duplicate username or an IP that is already in use.
• Consider IPv4 and IPv6 traffic separately.
• If there are many user and group objects, check the specific internal User ID. The User ID limit isn’t diagnosed from a rough object count.

According to the current SFOS help, Clientless Users are visible as Live Users directly after configuration. A service restart, database intervention, or repeated deletion and recreation isn’t part of the normal setup path.

User is visible, but the wrong rule matches

• Check Match known users, the selected user or group, and the rule status.
• Compare the source zone, source network, destination zone, destination, and service with the real flow.
• Check the rule position and any more general rule above it.
• In Log Viewer, don’t filter only by username; compare the Firewall Rule ID and source IP as well.
• Create a new connection because existing sessions aren’t automatically evaluated again.

Firewall rule doesn’t match provides the deeper troubleshooting logic.

The wrong device receives the identity

The IP assignment isn’t controlled sufficiently. Check the DHCP lease, reservation, static configuration, duplicate IP, NAT, and proxy. Disable the rule or set the Clientless User to Inactive until it is clear which device is using the source address.

Don’t create a larger range to capture changing addresses. This broadens the incorrect trust assumption and makes later attribution harder.

QoS doesn’t apply with many Clientless Users

Sophos documents NC-148705 as fixed in SFOS 22.0 MR1 Build 490: A QoS policy wasn’t applied when there were more than 3000 Clientless Users. The release notes don’t state an affected version range.

If the exact symptom matches, record the firmware version and build and plan a supported update to at least MR1 Build 490 or a later compatible version. A QoS issue with fewer users or on another build doesn’t prove NC-148705; check the policy assignment, rule match, and traffic shaping normally.

Interpret logs and HA

access_server.log contains authentication, authorization, and accounting events. For the data flow, the firewall log, Log Viewer, and Packet Capture remain decisive. Sophos Firewall service logs explains the log mapping.

In an HA cluster, perform configuration and operation on the current primary. Sophos doesn’t document a guarantee that Clientless User live-user or session states survive a failover without interruption. After a controlled failover, check the Clientless User, rule match, real flow, and local logs of the node that processed the event again.

Operation and rollback

Every Clientless User needs an owner, purpose, and review date. When a device is replaced, moved to another network, or no longer needs the rule, don’t simply leave the assignment in place.

The controlled rollback:

1. Document the affected rule, group, reports, and traffic shaping dependencies.
2. Set the Clientless User to Inactive.
3. Negatively test the Live Users status and the real data flow.
4. Change the rule or user condition to the intended successor state.
5. Delete the Clientless User when it is no longer required.
6. Remove the group only when no other user or policy needs it.
7. Clean up the DHCP reservation, host object, and documentation separately.

Don’t delete a production identity during an active incident before preserving the source IP, Rule ID, and logs. If the assignment is unclear, restrict access first and preserve the evidence.

FAQ