Configure Sophos Firewall RADIUS SSO with accounting

RADIUS SSO signs a user in to Sophos Firewall without an additional captive portal. The user has already authenticated on a wireless network, network access server, or another RADIUS peer. The firewall then receives a RADIUS accounting packet containing the username and client IP and can use this mapping for user-based rules.

The decisive point is not merely a successful 802.1X sign-in. The firewall must receive a usable Accounting-Start from the exact configured sender. For Wi-Fi SSO, Sophos uses the Framed-IP-Address from this start packet. If the client IP is missing, the firewall may know the username but can’t associate it with any traffic.

⚠️ RADIUS SSO isn’t the same as Enable accounting on the RADIUS server object. Under Authentication > Servers, Enable accounting means that the firewall sends accounting to a RADIUS server. Under Authentication > Services > SSO using RADIUS accounting request, the firewall receives accounting from a RADIUS client and creates a user-to-IP mapping from it.

Quick procedure

1. Verify that the access point, controller, or RADIUS proxy can generate an accounting start containing the username and Framed-IP-Address.
2. Define the actual sender, the firewall destination address, UDP port 1813, and a strong shared secret.
3. Under Authentication > Services > SSO using RADIUS accounting request, enter the sender IP and shared secret.
4. Under Administration > Device access, allow the RADIUS SSO service only for this sender and the correct firewall address.
5. Prepare a tightly scoped user rule with Match known users and logging.
6. Connect a real client and inspect the accounting packet on the firewall.
7. Under Current activities > Live users, verify the RADIUS SSO client type, user, and correct client IP.
8. Only then test allowed and deliberately disallowed traffic with the expected Firewall Rule ID.

When RADIUS SSO is suitable

RADIUS SSO is especially suitable for 802.1X wireless networks or network access systems where authentication already takes place outside the firewall. The firewall can then identify the user without a second browser sign-in.

The procedure requires an unambiguous relationship between a user and an IPv4 address. Typical prerequisites are:

• The client receives an IPv4 address that Sophos Firewall also sees as the traffic source.
• The accounting sender knows both the username and this client IP.
• The accounting start reaches a firewall address directly and without an unexpected source NAT change.
• The RADIUS sender can provide Framed-IP-Address in the start packet.
• User or group objects and the associated firewall rule have already been planned.

RADIUS SSO isn’t a replacement for STAS on Sophos Firewall when Windows sign-in events from Active Directory are the identity source. RADIUS SSO also can’t distinguish multiple users behind the same RDS or Citrix IP. Depending on the traffic, use SATC for Remote Desktop Services or per-connection AD SSO through the direct web proxy instead.

When to stop the procedure

Do not enable this in production while any of these points remains unresolved:

• The accounting packet doesn’t contain a username or Framed-IP-Address.
• The address reported in the packet differs from the source IP that the firewall later sees in user traffic.
• Multiple users share the same client IP.
• NAT, HA, or routing makes the actual sender or firewall destination address ambiguous.
• The RADIUS client can only use an entire untrusted network rather than a fixed source address.
• The existing rule strategy for unknown users or users who are no longer signed in is unclear.

Understand the accounting path

With conventional RADIUS authentication, the firewall sends an Access-Request to the RADIUS server. With RADIUS SSO, the direction is reversed:

1. A client authenticates on the access point, wireless controller, or network access server.
2. After address assignment, this infrastructure generates an accounting start or forwards it through a RADIUS proxy.
3. Sophos Firewall receives the packet on its RADIUS SSO service.
4. If the sender IP matches RADIUS client IPv4 and the shared secret is correct, the firewall processes the message.
5. The username and Framed-IP-Address appear as a mapping under Live users.
6. Only subsequent user traffic can match a rule with Match known users.

Whether the wireless controller sends directly to the firewall or a RADIUS server such as NPS forwards the accounting depends on the product. The Sophos configuration doesn’t provide a universal NPS or controller procedure. What matters is the packet that actually reaches the firewall. A vendor statement such as “RADIUS Accounting supported” isn’t enough until the username and client IP have been verified in the accounting start.

End-to-end example

This guide uses these example values:

• RADIUS or accounting sender: 10.10.20.15
• Firewall address for RADIUS SSO: 10.10.20.1
• Wireless client: 10.30.40.50
• Accounting destination port: UDP 1813
• User: EXAMPLE\alex.muster
• User rule: RADIUS-SSO-WiFi-Out

The addresses come from private example networks and must be replaced with the actual management, server, and client networks. For RADIUS client IPv4, don’t automatically enter the authentication server IP. Enter the source IP that is actually visible in the packet capture on the firewall.

Prepare the peer

On the access point, controller, network access server, or RADIUS proxy, authentication and accounting must be checked separately. A successful sign-in doesn’t prove that accounting is generated or forwarded to Sophos Firewall.

Prepare the peer as follows at minimum:

1. Enable accounting for the affected 802.1X or network access service.
2. Set the intended firewall address 10.10.20.1 as the accounting destination.
3. Use UDP 1813 or the accounting port explicitly agreed on by both sides.
4. Configure a dedicated strong shared secret for this path.
5. Send the accounting start only after the client IP is known.
6. Make sure the username and Framed-IP-Address are included.
7. Document the source IP, routing, and any NAT translation toward the firewall interface.

An accounting stop or update may improve session maintenance on some products. However, the public Sophos documentation explicitly identifies the IP in the accounting start as the sign-in basis for Wi-Fi SSO. A later update must therefore not replace a complete start packet as the success criterion.

For SFOS-managed APX deployments, DHCP timing may matter. Sophos documents the radius_accounting_start_delay parameter with a range from 0 to 60 seconds. Don’t change this value speculatively. First, a capture must show that the accounting start is generated before address assignment. The general wireless setup is covered in Configure a wireless network on Sophos Firewall.

For AP6, the release notes for 1.5.2167 MR5 list fix WIFIX-5189 for a case where the framed IP was missing from accounting start and accounting update. For an AP6 on an older or unknown firmware version, first update to a current supported firmware version and then inspect the packet again. This fix doesn’t prove that every controller, proxy, or NPS combination forwards the attributes correctly.

Configure RADIUS SSO on Sophos Firewall

Enter the sender and shared secret

The menu path is:

Authentication > Services > SSO using RADIUS accounting request

Proceed as follows:

1. Under RADIUS client IPv4, add the sender IP 10.10.20.15 expected in the capture.
2. Enter the Shared secret agreed on for this path.
3. Add further senders only as separate documented entries.
4. Select Apply.

Only packets from the configured IPv4 addresses are considered for RADIUS SSO. An entire network or an arbitrary source address isn’t a sensible substitute for missing sender planning.

This configuration doesn’t add a RADIUS server under Authentication > Servers and doesn’t replace the general RADIUS server configuration on Sophos Firewall. The server article covers requests the firewall sends to NPS, MFA, or another RADIUS server. RADIUS SSO covers incoming accounting messages.

Allow Device Access narrowly

RADIUS SSO is a local firewall service. A normal LAN-to-WAN or WiFi-to-WAN rule doesn’t open this receiving path.

Under Administration > Device access, there are two clean options:

• If the sender zone is small and fully trusted, enable RADIUS SSO in the zone matrix.
• If only one fixed peer is intended, leave the zone access disabled and create a targeted Accept Local service ACL exception rule for the sender IP, the firewall address used, and the RADIUS SSO service.

An additional accept exception doesn’t narrow an already active zone access rule. For a genuinely narrow exception, RADIUS SSO must therefore remain disabled in the affected zone. The complete procedure is explained in Device Access and Local Service ACL.

Prepare the user rule

A broad production rule isn’t required for the first test. A narrow rule provides clearer evidence:

1. Under Rules and policies > Firewall rules, create a rule above more general WiFi or LAN rules.
2. Restrict the source zone and source network to the actual client network.
3. Select only the pilot user or a prepared pilot group.
4. Turn on Match known users.
5. Allow only a harmless test service or a clearly defined destination.
6. Turn on Log firewall traffic.
7. Define a second deliberately disallowed user or destination combination for the negative test.

RADIUS SSO provides an identity, not blanket network access. Create firewall rules on Sophos Firewall explains how users, groups, services, and logging work together.

Validate RADIUS SSO in a controlled manner

1. Verify the accounting packet on the firewall

Under Diagnostics > Packet capture, set a filter for sender IP 10.10.20.15, firewall address 10.10.20.1, and UDP 1813. Then reconnect exactly one pilot client.

The capture must confirm at least the following:

• The source IP is the configured RADIUS client IPv4.
• The destination is the intended firewall address.
• The destination port is the configured accounting port.
• An accounting start appears for the pilot user.
• Framed-IP-Address matches the current client IP 10.30.40.50.

RADIUS accounting contains identity and session data that may be visible in the packet. Treat capture files like authentication logs, retain them only briefly, and don’t share them without protection. Packet capture on Sophos Firewall explains the general operation.

2. Check Live User

Under Current activities > Live users, the user, client IP, and client type must match. For this procedure, the expected client type is RADIUS SSO.

A visible user with the wrong IP isn’t partial success. User rules later match the traffic source, not the intended wireless mapping.

3. Correlate the authentication log

In Log Viewer, search for the pilot user and the incident time. For deeper analysis, access_server.log is relevant because Sophos processes user authentication, authorization, and accounting there.

In HA, each node stores only the logs for traffic it processed. Check the node that received the accounting packet at the time of the test. Check Sophos Firewall services and logs through the CLI explains how to read and save access_server.log without an uncontrolled service restart.

4. Perform positive and negative tests

Use the pilot client to test four items separately:

1. An allowed destination matches the expected Firewall Rule ID and shows the correct user.
2. A deliberately disallowed destination remains blocked.
3. An unassigned user doesn’t receive the pilot access.
4. After a new connection or controlled roaming, the user, IP, and rule mapping remain correct.

The test must use real user traffic. A Live User entry alone proves neither rule matching nor routing or the return path. Test firewall rules reliably describes the repeatable procedure.

Troubleshoot by symptom

No accounting packet reaches the firewall

First check the destination IP, UDP port, routing, and peer configuration. Then inspect Device Access or the Local Service ACL Exception Rule. A successful RADIUS sign-in on NPS or the wireless network doesn’t prove that the separate accounting path to the firewall exists.

If the packet arrives with a different source IP, investigate that exact cause. Don’t hastily allow an entire network as a RADIUS client. With NAT or HA, document and specifically allow the stable sender address that is actually visible.

Accounting arrives, but Live Users remains empty

Check the shared secret, sender IP, and packet contents together. The accounting start, username, and Framed-IP-Address are particularly important. If the client IP is missing, correct the access point, controller, or RADIUS proxy first. Restarting a firewall service can’t create a missing attribute.

Only when the packet is complete and access_server.log still doesn’t process the event should the timestamp, capture, CTR, and node logs be saved for Sophos Support. Don’t delete the authentication database or clear Live Users speculatively.

The user appears with the wrong IP

This often indicates an accounting message sent too early, a stale DHCP mapping, roaming, or a different NAT path. Disconnect the client, record the current lease, and capture one new connection attempt. What matters is the IP in the new accounting start.

With SFOS-managed wireless, change radius_accounting_start_delay only after this evidence and with the previous value documented. Third-party access points or controllers use their own accounting and DHCP mechanisms; a Sophos wireless parameter doesn’t change those devices.

Live User is correct, but the rule doesn’t match

The accounting path is then further along than the policy. Check the source zone, source network, user or group, Match known users, rule order, Firewall Rule ID, and actual traffic IP. If rule #0 or a general rule matches, correct the policy rather than changing the shared secret.

The user remains visible after signing out

First verify whether the peer sends an accounting stop and whether this packet refers to the same session and user mapping. Then correlate Live User, current client traffic, and access_server.log. A manual disconnect may clear the state temporarily, but it doesn’t prove that the automatic process is correct.

Security, HA, and operations

RADIUS accounting uses UDP and doesn’t protect transport like TLS. The shared secret authenticates the RADIUS path but doesn’t encrypt all identity and session attributes. Accounting therefore belongs in a trusted management or server network and shouldn’t traverse untrusted networks without protection.

Apply these boundaries in operation:

• Use a separate strong shared secret and documented owner for each sender.
• Allow RADIUS SSO only from the required zones and preferably only from fixed hosts.
• Treat capture files, RADIUS logs, and access_server.log as personal operational data.
• Complete changes to DHCP, wireless controllers, NPS, RADIUS proxies, or NAT with a new end-to-end test.
• In HA, don’t promise uninterrupted preservation of the user mapping. After a planned failover, verify a new accounting start, Live User, and real traffic on the processing node.
• Handle unknown users or missing mappings with a safe default rule, not a broad allow rule.

Rollback

Roll back in an order that neither leaves the accounting service exposed nor unintentionally grants access to users:

1. Restore the previous authentication and rule strategy for the pilot network.
2. Disable the pilot rule and perform a negative test with an unknown user.
3. Remove the accounting destination from the access point, controller, or RADIUS proxy, or restore its documented previous state.
4. Remove the sender under SSO using RADIUS accounting request.
5. Remove the RADIUS SSO ACL exception or temporary zone access.
6. Check Live Users, Firewall Rule ID, and normal client traffic again.

Document the original configuration, shared-secret ownership, and tested return to the previous user-identification method in the change. Merely deleting a Live User entry isn’t a complete rollback.

FAQ