Set up and test a RADIUS server on Sophos Firewall

RADIUS connects Sophos Firewall to Microsoft NPS, an MFA gateway, or another centralized authentication service. First, prepare the remote server and the network path. Then add the server under Authentication > Servers and assign it under Authentication > Services only to the login services that require it. Validate the configuration with a real login, including checks of the user, group, and rule.

For conventional user and group lookups in a Windows domain, a direct Active Directory connection to Sophos Firewall is often suitable. For modern remote access scenarios, Microsoft Entra ID SSO for Sophos Connect and VPN Portal may be the more appropriate architecture. If the firewall must identify already authenticated wireless users from incoming accounting packets, follow a different process: Set up RADIUS SSO with accounting on Sophos Firewall.

When to use RADIUS

The firewall sends the username and credentials to the RADIUS server. The user source, Network Policy, and, if applicable, MFA on that server determine whether it returns Access-Accept or Access-Reject. Only then do the local user group, VPN policy, and firewall rules determine which resources the user can access.

In the RADIUS model, authentication and authorization data are stored in user profiles. Authorization to use a service requires the request to match the specified attributes, such as the IP address of the requesting RADIUS client. The Shared secret protects user passwords; this does not mean that the entire RADIUS transport is encrypted.

Typical use cases include:

• Remote Access VPN with Microsoft NPS or an MFA service;
• centralized authentication for the User Portal, VPN Portal, or Captive Portal;
• a transitional setup where AD or LDAP should not be connected directly to the firewall;
• multiple network devices that use the same RADIUS service.

An enterprise wireless network managed by the firewall also uses the server selection under Wireless > Wireless settings. The complete 802.1X procedure is therefore covered in Set up wireless networks directly on Sophos Firewall.

In an SFOS-managed enterprise wireless network, Accounting Request and Accounting Response contain session and accounting information. They are separate from the access requests, responses, and challenges used for login. For this wireless path, Sophos documents accounting support on all Wi-Fi-enabled devices; the Wireless Network must use 802.1X, and accounting must be enabled on the RADIUS server. The linked wireless guide explains the separate ports and the lack of Interim Accounting Updates. Accounting support does not imply support for a secondary RADIUS server.

Record the initial state and rollback path

Before changing a production service, record the following for each affected section under Authentication > Services:

• the selected servers and their order;
• the state of Set authentication methods same as firewall, Same as VPN, or Same as firewall;
• the current Default group for firewall authentication;
• a user account that is known to work with the current method.

For administrator logins, keep an existing WebAdmin session open during the change. Also verify a local super administrator through an already permitted management path. The server selection for administrators does not apply to this super administrator. Nevertheless, never change an external administrator login without first confirming a local recovery path.

Plan the RADIUS connection

Roles, network path, and protocols

In an NPS environment, Sophos Firewall is the RADIUS client and NPS is the RADIUS server. NPS evaluates the request against its Connection Request Policy and Network Policy, and usually against Active Directory. A subsequent VPN or firewall rule still determines the actual access.

The general SFOS 22 help describes communication between the firewall and the RADIUS server using PAP. Under Authentication > Services, however, Sophos lists PAP, CHAP, and MSCHAPv2 for L2TP and PPTP connections. This protocol matrix does not establish that the same methods apply to IPsec or other login paths. The service, client, and method permitted on the RADIUS server must therefore be checked together.

Traditional RADIUS uses UDP, and the documented SFOS interface does not provide TLS or certificate fields. Place this traffic on a controlled internal or otherwise protected path. A strong shared secret is not a substitute for segmentation or a narrowly scoped rule between the firewall and the RADIUS server.

Older systems may expect different ports, such as 1645/UDP and 1646/UDP. The ports actually configured on both sides are authoritative, not these historical values.

Choose example values deliberately

This guide uses:

• server name NPS-HQ-RADIUS;
• server IP address 10.20.30.15;
• authentication port 1812;
• accounting port 1813;
• time-out 5 seconds;
• domain name corp.example.

Replace 10.20.30.15 and corp.example with the internal address and your own naming convention. Five seconds is a starting value for a direct password check, not a Sophos default. For a push notification, phone call, or external challenge, the value must suit both the provider and the actual client, within the SFOS-supported range of 1 to 60 seconds.

The Shared secret is the technical secret shared by the RADIUS client and server, not a user’s password. Sophos limits it to 48 characters. Exchange the value through a separate protected channel, store it securely, and enter it identically on both sides. RADIUS does not transmit the secret itself over the network.

Add the RADIUS server under Authentication

The menu path is Authentication > Servers.

1. Open Add and select RADIUS server for Server type.
2. Enter a Server name, such as NPS-HQ-RADIUS.
3. Under Server IP, enter the RADIUS server’s internal IP address, 10.20.30.15 in this example.
4. Match the Authentication port to the server, normally 1812.
5. Set the Time-out. This example uses 5 seconds for the first direct test.
6. Select Enable accounting only if the remote server is intended to process accounting data. If enabled, also match the Accounting port, normally 1813.
7. Enter the Shared secret exactly as configured on the remote server.
8. Optionally set Domain name. When AD and RADIUS are used in parallel, a consistent domain prevents the same person from appearing as different local user objects. With Domain name set, a local entry in the format user@domainname is automatically created at the first login. Without this value, RADIUS creates a user without a domain, while AD creates a domain-qualified entry; this can result in two local entries for the same person.
9. Enter Group name attribute only if the remote server is proven to return the expected attribute. Sophos help describes it as an alias for the configured group name, but does not document a general mapping of arbitrary NPS attributes to local groups here.
10. Open Enable additional settings only when required by a corresponding policy. NAS-identifier identifies the requesting Network Access Server, for example by an FQDN. NAS-port-type describes the port type used for the login.
11. Run Test connection with a dedicated pilot user, then select Save.

The firewall supports no more than 20 configured authentication servers in total. No more than 20 servers can also be selected for each authentication method under Authentication > Services.

API note for SFOS 23: The API reference for adding and editing RADIUS servers adds the optional parameter EmailAddressAttribute (string, maximum 50 characters) and includes it in the XML example for RADIUSServer. No default value is stated. This note concerns the API documentation, not an additional WebAdmin field.

Understand accounting correctly

With Enable accounting, the firewall sends an Accounting-Start message when a supported client type logs in and an Accounting-Stop message when it logs out normally. Sophos lists Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client, and API client as supported types. The start and stop requests also contain the time of login and logout, respectively.

The firewall does not send an Accounting-Stop message when it shuts down or restarts. If a session remains open on the RADIUS server, compare it with the firewall restart time and the RADIUS logs. This outgoing accounting function is not the incoming RADIUS SSO accounting through which the firewall learns sessions created elsewhere.

Prepare Microsoft NPS as the remote server

Sophos Firewall must be configured as a RADIUS client on NPS. Perform at least the following checks in the Network Policy Server console:

1. Open RADIUS Clients and Servers > RADIUS Clients.
2. Add a New RADIUS Client with a unique Friendly name, such as Sophos-Firewall-HQ.
3. Under Address (IP or DNS), enter the address from which NPS actually receives the request.
4. For Vendor, normally select RADIUS standard.
5. Enter the same Shared secret as on the firewall.
6. In the applicable Connection Request Policy and Network Policy, verify the conditions, access decision, and authentication method allowed for the pilot user.
7. Have Event Viewer and the NPS accounting logs available for validation.

For HA clusters, routed connections, or NAT, do not infer the NPS client address from the topology. An initial test shows which source IP address actually reaches NPS. If no request arrives at all, or NPS cannot validate it, first check routing, the UDP rule, the RADIUS client address, and the shared secret. A normal Access-Reject, by contrast, points to the user, policy, or authentication method.

Assign RADIUS to the correct services

After you save it, the server object is not yet active for any login. SFOS 22 provides the following sections under Authentication > Services:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

For the User Portal, VPN Portal, VPN, and administrators, the server selection can be linked to the firewall authentication methods. SSL VPN provides Same as VPN and Same as firewall. Before making a change, check whether the affected section uses its own list or a linked list.

For a limited pilot, add NPS-HQ-RADIUS only to the required section, place it in the intended position, and select Apply. The firewall queries multiple servers in the displayed order. If the same user can already authenticate successfully against an earlier server, a later RADIUS MFA policy will not be reached.

Captive Portal and Default Group

The Captive Portal does not have a separate section under Authentication > Services. It uses Firewall authentication methods. In addition, the intended zone must permit Captive portal under Administration > Device access, and a suitable user-based firewall rule must be configured. The official functional test is to sign in at https://<firewall-ip>:8090.

The Default group under Firewall authentication methods is security-sensitive. When an external user first logs in successfully to a firewall service, the firewall creates that user under Authentication > Users. If no suitable local group assignment exists, the configured Default Group applies. Before the pilot, review the group’s policies and every rule in which it is used. An excessively privileged Default Group must not become an unnoticed fallback.

Account for challenge-based MFA by service

According to the SFOS 22 help, the VPN Portal does not support RADIUS authentication with challenge-based MFA. A successful Test connection therefore says nothing about this portal path. Push, call, OTP, and challenge methods are not interchangeable either: test each intended client and service separately. For local Sophos Firewall MFA, follow the separate procedure in Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access.

Validate the configuration

1. Connection and remote server

Under Authentication > Servers, open NPS-HQ-RADIUS and run Test connection with the pilot user. At the same time, verify the following in NPS or in the logs of the other remote server:

• the request comes from the expected firewall address;
• the correct policy processes it;
• the result is Access-Accept;
• the expected return attributes are present.

The test confirms the credentials and server communication. It does not yet confirm the service order, VPN policy, local group, or firewall rule.

2. Test the actual service

Next, sign in the same user through the exact service you intend to use. Captive Portal, SSL VPN, IPsec, User Portal, and WebAdmin have different requirements. For WebAdmin, the external user must also receive the intended administrator profile; successful RADIUS authentication alone does not grant administrator permissions. Leave all unnecessary paths unchanged. For SSL VPN, Set up Sophos Firewall SSL VPN Remote Access covers the policy, Device Access, and firewall rule.

After a successful login, check:

1. The local user, domain, and actual Main Group under Authentication > Users.
2. The active session under Current activities > Live users. If necessary, terminate it there with Disconnect.
3. In the Log viewer at the top right of WebAdmin, open the Authentication module and filter by user, source IP address, and a narrow test period.
4. In the traffic log, verify the actual Firewall Rule ID and that only the permitted destination resource is accessible.
5. Test the negative case with a user outside the permitted NPS policy.

If authentication succeeds but the application remains unreachable, check the zone, VPN IP pool, group, rule position, NAT, and routing. Troubleshoot a Sophos Firewall rule that does not match walks through this data path. If the identity, service selection, or Main Group is already unclear, see Systematically troubleshoot Sophos Firewall authentication errors.

Narrow down errors by symptom

No request reaches the remote server

First check the values configured under Server IP and Authentication port. Then verify routing and the rule for UDP 1812 between the source address used by the firewall and 10.20.30.15. A RADIUS server object does not automatically create a transit firewall rule.

For an SFOS-managed wireless network, Sophos documents a narrowly scoped special case: if the RADIUS server is connected to the firewall through an IPsec tunnel, a source NAT mapping is required for the access point networks. It translates the source IP address to the exact firewall IP address used to reach the RADIUS server. The wireless help refers to configuration through the shell using sys-traffic-nat, but does not provide a complete executable command here. Before making a change, verify the AP networks, the source address actually used, the firewall address for source translation, the tunnel, the return path, and the RADIUS logs. Without confirmed syntax for this purpose, the specific shell configuration, including verification and rollback, requires targeted technical escalation. This wireless guide does not establish a general NAT requirement for other RADIUS paths. A LAN-to-VPN rule or a forwarding IPsec route example does not replace this system traffic procedure.

NPS responds with Access-Reject

A reject shows that the network path and port are basically working. Now check the Reason Code, applicable Network Policy, user status, and permitted authentication method in NPS. An incorrect shared secret, by contrast, results in missing, invalid, or unverifiable responses.

Test connection works, but the service login fails

Under Authentication > Services, check the correct section, linkage switches, server order, and Apply. For the Captive Portal, also check Device access and the user-based firewall rule. For SSL VPN, the policy member, SSL VPN access under Device Access, and the required firewall rule must all be correct.

Login works, but the wrong group applies

Review the domain and Main Group under Authentication > Users. Then compare Group name attribute, the return attributes from the remote server, and Default group. Successful authentication does not prove that the expected authorization applies. The negative test user must demonstrably fail the group or NPS condition.

Push or challenge times out

Use the actual client and compare timestamps in the firewall, NPS, and MFA provider logs. Increase the SFOS time-out only within the range of 1 to 60 seconds, and choose the lowest value that reliably accommodates the normal challenge process. A longer time-out cannot make challenge-based RADIUS MFA work on the VPN Portal because Sophos does not support this path.

Roll back safely

If the pilot fails, restore the previously recorded server list and order, the linkage switches, and the Default group in the affected section under Authentication > Services, then select Apply. Next, sign in the comparison user through the original method and verify the local super administrator.

Only after all affected services are working again should you remove NPS-HQ-RADIUS from any other service assignments. Delete the server object under Authentication > Servers only if no planned use remains. On NPS, restore the client, policy, and shared secret to the documented initial state. Review any local user objects that were created separately. Removing them does not automatically terminate every existing session, so also check Current activities > Live users.

Operations

RADIUS is a production identity service. After changes to NPS, the MFA provider, AD, or service order, validate the configuration with real positive and negative logins. Document the shared secret securely and rotate it on a schedule. Monitor the remote server and define a retention period for its decision logs. This makes it possible to determine whether an error occurred before the firewall, during authentication, or only during authorization.

FAQ