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.

The current Sophos procedure confirms this workflow for SFOS-managed APX access points. It doesn’t provide general approval for AP6 or arbitrary third-party controllers. For another platform, confirm with the vendor and, where necessary, Sophos Support that it supports the same proxy and attribute path before production rollout. A technically suitable test packet alone doesn’t extend the documented support scope.

Quick procedure

1. For the officially documented workflow, use APX with 802.1X and configure the RADIUS accounting server as a proxy to the firewall.
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 SFOS-managed APX against the RADIUS server selected under Wireless > Wireless settings.
2. The APX sends accounting through the firewall to that server. The server is also configured as an accounting proxy and forwards the message back to the firewall.
3. Sophos Firewall receives the forwarded 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.

In the official APX workflow, the RADIUS server isn’t only the authentication and accounting destination; it also acts as a proxy and forwards the APX accounting packets to the firewall. NPS therefore requires a suitable RADIUS proxy configuration. The source IP of this forwarded packet is the value that matters for RADIUS client IPv4. A general vendor statement such as “RADIUS Accounting supported” proves neither support for this design nor the presence of the username and client IP 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

In the officially documented APX design, check authentication, accounting to the RADIUS server, and the proxy return path to the firewall separately. A successful 802.1X sign-in doesn’t prove that the RADIUS server forwards accounting to Sophos Firewall.

Prepare the peer as follows at minimum:

1. Configure the APX and 802.1X wireless network under Wireless, then select the RADIUS server under Wireless > Wireless settings.
2. Enable accounting on the RADIUS server and configure it as an accounting proxy to firewall address 10.10.20.1.
3. Use UDP 1813 for forwarding to the firewall.
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 radius_accounting_start_delay with a range from 0 to 60 seconds. The official Device Console example sets 30 seconds:

system wireless-controller global radius_accounting_start_delay 30

30 is an adjustable example, not a universal default. Before changing it, run system wireless-controller global show and record the current value. Only make the change when a capture shows that the accounting start is generated before address assignment. For rollback, run the setting command with the recorded value. If that value was 0 (no delay), the exact rollback command is system wireless-controller global radius_accounting_start_delay 0. The official sources don’t identify a universal default, so don’t infer one when the previous value is unknown. Sophos also specifies use_tunneled_reply for FreeRADIUS; that option belongs on the FreeRADIUS server and must not be transferred to NPS without evidence. The general wireless setup is covered in Configure a wireless network on Sophos Firewall.

The AP6 release notes list WIFIX-5189, a resolved issue involving the framed IP in accounting packets. However, the RADIUS SSO procedure limits the described workflow to APX. The AP6 fix therefore isn’t proof that this configuration is supported.

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.

In this section, SFOS 22 provides only RADIUS client IPv4 and Shared secret; it doesn’t provide a separate port setting. 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 receiver configuration alone doesn’t add a RADIUS server under Authentication > Servers. The official APX workflow nevertheless requires the external RADIUS server to be added there and selected under Wireless > Wireless settings; the general RADIUS server configuration on Sophos Firewall explains that part. Outbound authentication and accounting and the proxied RADIUS SSO messages remain separate paths.

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 UDP 1813.
• 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.

After a firewall restart, Sophos states that APX clients must disconnect and reconnect so a new accounting start restores the sign-in. If Show captive portal to unknown users is enabled in the user rule, the portal may appear initially; in the documented APX workflow, transparent sign-in follows after the configured accounting delay without the user entering credentials again.

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 proxy forwarding destination for the firewall from the RADIUS server, or restore the proxy’s documented previous state. Don’t remove the APX accounting destination if the RADIUS server is still required for wireless authentication and accounting.
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