Set up a Sophos Firewall RADIUS server

RADIUS is an important bridge from Sophos Firewall to existing authentication services. Typical examples are Microsoft NPS, an MFA gateway, an identity provider with a RADIUS interface or a central authentication platform already used for VPN, wireless or other network services.

This article explains how to add a RADIUS server under Authentication > Servers, which fields matter, how to prepare Microsoft NPS as the peer and how to test the configuration afterwards. For classic user and group queries from a Windows domain, connecting Active Directory to Sophos Firewall is often the better fit. For modern remote access scenarios, Microsoft Entra ID SSO for Sophos Connect and VPN Portal may also be more suitable.

When RADIUS makes sense

RADIUS is useful when the Sophos Firewall should not carry the entire identity logic itself. The firewall sends a request to the RADIUS server. The RADIUS server decides whether username, password, group condition, MFA or policy match.

Typical use cases:

• Remote Access VPN with Microsoft NPS.
• External MFA solution over RADIUS.
• Central authentication for VPN Portal, SSL VPN, IPsec Remote Access or Captive Portal.
• Transitional design when AD/LDAP should not be connected directly to the firewall.
• Mixed environments with several network devices using the same RADIUS service.

RADIUS does not replace clean access rules. After successful authentication, firewall rules, VPN zones, groups, IP pools and logging must still match. For remote access, setting up Sophos Firewall SSL VPN Remote Access is useful context; for MFA designs, use enabling MFA for Sophos Firewall WebAdmin, VPN Portal and Remote Access.

Plan before setup

Before clicking Add, it should be clear what role RADIUS will play. Otherwise the connection test may succeed while the production login later fails because the wrong service, group or timeout is used.

Identity source and peer

In Microsoft environments, RADIUS is often a Microsoft NPS server. NPS can check users against Active Directory, evaluate network policies and write accounting data. Microsoft describes NPS as a RADIUS server for central authentication, authorisation and accounting. In practice, the Sophos Firewall is the RADIUS client and the NPS server is the RADIUS server.

The roles are:

• Sophos Firewall: sends the authentication request.
• RADIUS server: checks user, password, policy and optionally MFA.
• Active Directory or identity provider: provides users and groups in the background.
• Firewall rule or VPN configuration: decides where the user is allowed to go after login.

Network path and ports

The RADIUS server must be reachable from the firewall. These ports are normally used:

Older environments or individual products may still use 1645/UDP and 1646/UDP. Only use these if the peer really expects them.

Shared secret and timeouts

The Shared secret is the shared technical secret between firewall and RADIUS server. It is not a user password. Sophos specifies a 48-character limit for this field.

The timeout must match the use case. A short value is often enough for simple password checks. With push MFA, phone calls or external challenges, a timeout that is too short can interrupt the login even when user and password are correct. Sophos allows Time-out values from 1 to 60 seconds.

Add the RADIUS server on Sophos Firewall

The menu path is:

Authentication > Servers

Procedure:

1. Open Add.
2. Select RADIUS server as Server type.
3. Enter a clear Server name, for example NPS-HQ-RADIUS or MFA-RADIUS.
4. Enter the RADIUS server IP address under Server IP.
5. Check Authentication port, normally 1812.
6. Set Time-out. For simple logins, 3 to 5 seconds may be enough; for MFA, use a higher value depending on the provider.
7. Enable Enable accounting only if the RADIUS server should process accounting.
8. If accounting is enabled, check Accounting port, normally 1813.
9. Enter the Shared secret exactly as configured on the RADIUS server.
10. Optionally set Domain name, especially when AD and RADIUS are used in parallel.
11. Optionally enter Group name attribute if the RADIUS server returns group information in a usable form.
12. If needed, open Enable additional settings and set NAS-identifier or NAS-port-type.
13. Run Test connection with a real test user.
14. Save.

The connection test confirms basic communication between firewall and RADIUS server. It does not prove that VPN Portal, SSL VPN, IPsec Remote Access, Captive Portal or WebAdmin work in the production flow. These services must be tested separately.

Set Domain name deliberately

The Domain name field looks small but matters in mixed environments. If RADIUS works without a domain while Active Directory creates users with a domain, duplicate local user entries can appear on the firewall.

Therefore, when AD and RADIUS are used in parallel, set a suitable Domain name and then check how new users appear under Authentication > Users.

Do not guess Group name attribute

The Group name attribute must match the peer. With NPS or MFA integrations, it depends on which attributes the RADIUS server actually returns and how the firewall should evaluate them. A guessed value often creates confusing group issues.

If group matching matters, test the complete flow:

1. Sign in to the target portal or VPN with a user.
2. Check whether the user appears under Authentication > Users with the expected group.
3. In Log Viewer, check which firewall rule and user are visible for the traffic.
4. With NPS, also check Event Viewer and the matching Network Policy.

Prepare Microsoft NPS as the peer

When Microsoft NPS is used, the Sophos Firewall must be added as a RADIUS client on the NPS server. Microsoft uses RADIUS Clients and Servers > RADIUS Clients in the NPS console for this.

Minimal flow on the NPS server:

1. Open Network Policy Server.
2. Open RADIUS Clients and Servers > RADIUS Clients.
3. Create a New RADIUS Client.
4. Enter a Friendly name, for example Sophos-Firewall-HQ.
5. Under Address (IP or DNS), enter the IP address of the Sophos Firewall that sends the RADIUS requests.
6. Use RADIUS standard as Vendor in most cases.
7. Enter the same Shared secret as on the Sophos Firewall.
8. Create or check the required Connection Request Policy and Network Policy.
9. Keep Event Viewer and NPS logs ready for testing.

With HA clusters or multiple firewalls, check which source IP NPS sees. If NPS sees a different source IP than the configured RADIUS client, the request is rejected or does not match the expected policy.

Enable RADIUS for firewall services

After saving the RADIUS server, it is not automatically active for every login. Assignment is done under:

Authentication > Services

Decide per service whether RADIUS should be used:

• Firewall authentication methods: general firewall authentication.
• VPN portal authentication methods: VPN Portal login.
• SSL VPN authentication methods: SSL VPN login.
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: relevant Remote Access VPN methods.
• Captive portal authentication methods: Captive Portal login.

Server order matters. If multiple servers are selected, the firewall queries them in the configured order. This may be intentional, but it can also cause users to authenticate through AD instead of RADIUS, so MFA does not apply.

Validate after saving

A good test has several layers. Test connection alone is not enough.

Connection test

Open the RADIUS server under Authentication > Servers and run Test connection with a test user. If this fails, first check network path, source IP, shared secret, NPS client, port and user password.

Service test

Then test the real target flow:

1. Open VPN Portal with the test user.
2. Sign in through SSL VPN or Sophos Connect with a test profile.
3. Test Captive Portal if it is used.
4. For administrative access, check whether local admin permissions, role and authentication match.

With RADIUS MFA, test the full challenge or push flow with the real client. A successful server test does not prove that Sophos Connect, VPN Portal or WebAdmin handle the challenge behaviour in the same way.

Check logs

Several places matter for troubleshooting:

• Log Viewer on Sophos Firewall for authentication and traffic decisions.
• Authentication > Users for automatically created users and group assignment.
• NPS Event Viewer on Windows for accepted or rejected requests.
• RADIUS or MFA provider logs when a third party is involved.
• Firewall rule logs when login works but traffic is not allowed.

If the user is authenticated but no application is reachable, RADIUS is usually no longer the first cause. Check VPN zone, IP pool, firewall rule, group condition, NAT and routing. For that part, use Sophos Firewall rule not matching: check causes.

Typical errors

Test connection fails

Common causes are the wrong source IP, wrong shared secret, blocked UDP port, missing RADIUS client on NPS or an NPS policy that does not allow the test user. On Windows, check Event Viewer to see whether the request arrives at all.

Test connection works, VPN login does not

Then the RADIUS server is reachable, but the service is probably not set to RADIUS correctly. Under Authentication > Services, check whether the right server is selected for VPN Portal, SSL VPN or IPsec Remote Access and whether it is in the expected position.

MFA push arrives too late or not at all

With external MFA, timeouts are often the key issue. The Sophos Firewall timeout, NPS policy, MFA gateway and client must fit together. For push or phone MFA, do not start with an aggressive three-second timeout.

User is created twice

This often happens when AD and RADIUS are used in parallel and RADIUS works without Domain name. Different local user entries are created although they represent the same user. Check Domain name, login format and server order.

Login works, but the rule does not match

Then check user and group matching. The imported group, local user entry, rule position, source zone, VPN IP pool and actual traffic in Log Viewer are relevant.

Operations and security

RADIUS should be operated like a production identity service. If the RADIUS server fails, remote access or portal access may be affected.

Important operating points:

• Document the shared secret securely and rotate it deliberately after staff or provider changes.
• Retain NPS or RADIUS logs for long enough.
• Monitor the RADIUS server, not only the firewall.
• Test MFA timeouts per client and portal type.
• Define fallback admin access, but do not expose it broadly.
• After changes to AD, NPS, MFA provider or firewall services, test a real login.

RADIUS is a good building block when it is operated cleanly. Without monitoring, clear server assignment and real service tests, login problems are merely moved from the firewall to another system.

FAQ