Securing Sophos Firewall WAF with MFA

With Sophos Firewall WAF MFA, you can additionally secure web applications published via the Web Application Firewall with Multi-Factor Authentication. This is particularly useful for internal portals, admin interfaces, customer areas, or partner accesses that need to be accessible via HTTPS but should not be protected solely by the application itself.

WAF-MFA does not replace a secure application, patch management, or a clean permissions concept. It is a preliminary protective layer on the firewall. The firewall first checks the login and the second factor before forwarding access to the protected web server.

For the basic publication of a web server via WAF, first follow the guide Sophos Firewall WAF: Securely publish web servers. This article focuses on preliminary authentication and MFA.

When WAF-MFA is useful

WAF-MFA is particularly strong when a web application needs to be accessible from the internet but is not intended for all visitors.

Typical use cases:

• Internal portals with external access
• Admin interfaces of specialised applications
• Partner or customer portals with a limited user base
• Legacy web applications without their own strong MFA
• Applications where additional access protection in front of the backend is desired

For public websites, shops, or information pages, WAF-MFA is usually not suitable because every visitor would first see a firewall login. For complex private applications, ZTNA, SSE, or a dedicated reverse proxy may be more appropriate than WAF-MFA. If WebDAV is required, special caution should be taken: Sophos WAF does not support WebDAV cleanly, which can be relevant for applications like Nextcloud.

When WAF-MFA is not sufficient

WAF-MFA is a preliminary access layer. However, this layer does not answer every architectural question. Especially for critical portals, it should be consciously decided whether the application should be publicly accessible at all.

If a portal remains globally accessible, MFA should not be the only measure. Fixed source networks, country restrictions, threat feeds, protection profiles, and clean backend patches further reduce the risk.

Prerequisites

Before setting up, these points should be clarified:

• The web application is already planned or published via a WAF rule.
• Users or groups are present on the firewall, for example locally, via AD, LDAP, or RADIUS.
• Users can set up their OTP token.
• The system time of the firewall is correct and NTP is working.
• HTTPS with a suitable certificate is used for the WAF rule.
• It is clear whether the backend web server needs its own authentication or if the firewall should fully handle the login.
• A test user and an administrative fallback access are available.

⚠️ MFA for WAF should first be tested with a pilot group. An incorrect combination of MFA group, WAF authentication policy, and backend authentication can lock out legitimate users or make an application appear “broken.”

Plan pilot, fallback, and responsibilities

WAF-MFA acts before the actual application. Therefore, the rollout should not be treated like a normal firewall rule but as a change to the application’s login process. Users first see the Sophos Firewall login and only then, depending on the backend, the actual application.

Before activation, these points should be established:

• Which user group tests first?
• Who can disable access again if the login fails?
• Is there a second admin access that does not depend on the same WAF rule, the same portal, or the same test user?
• Which application parts need to be tested after successful login?
• Who checks reverseproxy.log, Log Viewer, and backend logs in case of errors?
• How are users informed about tokens, session expiration, and possible second backend login?

A common planning mistake is mixing firewall authentication and backend authentication. The WAF can check users before the backend. However, this does not automatically mean that the application itself no longer needs its own login, role check, or session management. Especially for admin portals and customer data, backend permissions should be consciously maintained.

If the published service is intended for only a few people, sources should be restricted in addition to MFA. For basic publication and source restriction, see Sophos Firewall WAF: Securely publish web servers. If user rights or remote access MFA are generally planned, Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access can help.

A rollback should be prepared before activation. Practically, this means documenting the old working access method, naming the WAF rule and authentication policy, designating the responsible person, and choosing a time when user feedback and log review are possible. If the application is business-critical, WAF-MFA should first be activated for a test domain, a pilot group, or a maintenance window.

Configuration components

Several settings must align for WAF-MFA:

The most important difference: MFA is not only activated globally. The affected WAF rule must also use a suitable authentication policy.

Enable MFA for WAF

The menu path is:

Authentication > Multi-factor authentication

Procedure:

1. Under One-time password (OTP), select either All users or Specific users and groups.
2. For Specific users and groups, add the affected users or groups.
3. Enable Generate OTP token with next sign-in if users should set up their token themselves at the next login.
4. Under Require MFA for, activate the option Web application firewall.
5. Save the configuration.

If users are to set up their token themselves, they must have access to a portal where the QR code is displayed. In many environments, the User Portal or VPN Portal is relevant for this. General MFA planning is described in Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access.

Prepare token rollout and user communication

In operation, WAF-MFA often fails not because of the actual WAF rule but because of the token rollout. Users need to know where the QR code appears, which app should be used, how long a session is valid, and whether a second login to the application follows after the firewall login.

Before activating the productive WAF rule, determine:

If Generate OTP token with next sign-in is used, the first login should be tested in a controlled manner. It is important whether users see the QR code in the expected portal and whether they can then successfully access the WAF application with password plus OTP. The portals themselves are described in Sophos Firewall Portals: WebAdmin, User Portal, and VPN Portal overview.

For helpdesk and operation, at least document:

• Published hostname of the WAF application
• Affected user group
• Used authentication policy
• Used OTP algorithm
• Allowed authenticator app
• Procedure for token reset
• Expected message for incorrect password or incorrect OTP
• Log locations for initial review: Log Viewer and reverseproxy.log

Especially for external partners or rarely used portals, the first login should not occur only in a productive emergency. A short pilot with normal users often reveals issues that admins do not see in their own tests: different authenticator app, missing portal access, unclear second backend login, or session timeouts that are too short for the application.

Create WAF Authentication Policy

The menu path is:

Web server > Authentication policies

For WAF-MFA, the client mode should be set to Form. With form-based authentication, the firewall can control the login via a form and sessions.

Procedure:

1. Open Add.
2. Assign a descriptive name, for example, WAF_MFA_Portal_Users.
3. Select the option Form under Mode.
4. Select a suitable Authentication template.
5. Select the users or groups who will have access to this WAF publication.
6. Consciously choose the Authentication forwarding mode.
7. Set Session timeout and Session lifetime appropriate to the application.
8. Save.

Choose authentication forwarding correctly

The Authentication forwarding mode decides what happens between the firewall and the backend.

If the application does not require its own authentication or the preliminary firewall login should suffice, None is often cleaner. If the backend itself expects HTTP Basic Authentication, the forwarding mode must match the application.

⚠️ Basic Authentication should only be used with HTTPS. Additionally, it must be clear whether the backend should actually process the login data forwarded by the firewall.

Use Authentication Policy in the WAF rule

The WAF rule is edited under Rules and policies > Firewall rules. The action is Protect with web server protection.

In the affected WAF rule, these points must align:

• Correct Hosted address and listening port.
• Correct domain and suitable HTTPS certificate.
• Correct protected web server.
• Desired Authentication policy selected.
• User group in the authentication policy matches the MFA group.
• Access restrictions via Allowed client networks, countries, or threat feeds are consciously set.

For public or highly exposed portals, MFA should not be the only protective measure. Country and source restriction is described in Sophos Firewall: Block countries and malicious IPs. For dynamic blocklists, see Sophos Firewall Threat Feeds.

Plan sessions and timeout

With form-based WAF authentication, the firewall works with sessions. In the authentication policy, you define:

• Session timeout: after what inactivity users must log in again
• Session lifetime: how long a login remains valid at most

Additionally, under Web server > General settings, there is the maximum number of simultaneous sessions for form-based reverse proxy authentication. The default value is 25,000, the supported range is 100 to 100,000.

Short sessions increase security but can annoy users. Very long sessions are more convenient but increase the risk that a stolen or shared browser access remains usable longer. For admin portals, it is better to start conservatively and observe behaviour in operation.

OTP algorithm and authenticator app

SFOS 22 supports SHA1, SHA256, and SHA512 for OTP tokens. This is sensible from a security perspective but only works if the used authenticator app supports the chosen algorithm.

Important points:

• SHA256 or SHA512 are more secure than SHA1.
• Not every authenticator app supports these algorithms in this context.
• Microsoft Authenticator can scan the QR code with SHA256 or SHA512, but the login may fail afterwards.
• If the algorithm is changed, old tokens must be deleted and rescanned.

For productive rollouts, test the desired app and algorithm with a small pilot group. Only then should existing users be broadly migrated.

Test plan after setup

After configuration, you should not only check if the login page appears. It is important to test the entire access path.

1. Use an external browser or external test network.
2. Open the WAF URL with a user from the allowed group.
3. Test login with correct password and OTP.
4. Test login with incorrect OTP.
5. Test user outside the allowed group.
6. Check session expiration after inactivity.
7. Test backend function of the application.
8. Check Log Viewer and reverseproxy.log for anomalies.

For log files, see Sophos Firewall Troubleshooting: Services and Logs. WAF events typically hang on the Reverse Proxy and also appear in the Log Viewer.

For acceptance, each test case should be assigned a visible result:

If only the browser appears successful but no matching logs are visible, the acceptance is incomplete. Then check whether the correct WAF rule matches, whether the authentication policy is really active, and whether logs land in the expected place.

Go-live and operation after activation

After a successful test, WAF-MFA should not simply be broadly activated and then forgotten. The first hours after go-live are important because real users bring different browsers, different authenticator apps, saved passwords, old bookmarks, and other session states than an admin test.

For go-live, a small operational plan is sensible:

For business-critical applications, do not schedule go-live at a time when no one can properly check login problems. Better is a controlled window with test users from different groups, then a short review of the logs, and only then the expansion to more users.

After a few days, the configuration should be checked again:

• Are there users bypassing MFA because they access via a different WAF rule or a different URL?
• Is access still only allowed for the planned groups?
• Do session duration and inactivity timeout match the application?
• Are rejected logins and token problems actually seen in operation?
• Are there support cases indicating unclear user communication or incorrect authenticator app?
• Are old test rules, test domains, or temporary exceptions removed?

This follow-up is especially important if multiple hostnames, paths, or WAF rules point to the same application. Otherwise, it can happen that one path is cleanly protected with MFA, but a second path remains accessible without preliminary authentication.

Typical errors

Troubleshooting

MFA is not requested

First check if Web application firewall is activated under Require MFA for. Then verify whether the WAF rule really uses an authentication policy and whether this policy contains the expected users or groups.

Login works, but the application does not open

Then the problem often lies after the firewall login. Check backend reachability, certificate, host header, path, protection policy, and authentication forwarding. If the backend expects its own authentication, the forwarding mode must match.

User cannot log in after algorithm change

If switched from SHA1 to SHA256 or SHA512, existing tokens must be deleted and rescanned. Additionally, the authenticator app must support the new algorithm.

Password and OTP are forwarded to the backend

With WAF-MFA, check if the firewall version is current. The SFOS-22.0-Release-Notes document a fixed WAF error where the OTP code was not removed from the password before data was forwarded to the backend.

Too many or old sessions

Check session timeout, session lifetime, and the global WAF session settings. In productive environments, it should be clear whether long sessions are desired or whether users need to re-authenticate quickly after inactivity.

Checklist

• WAF rule is documented and externally tested.
• HTTPS certificate matches the published hostname.
• MFA applies to the correct user group.
• Require MFA for > Web application firewall is activated.
• WAF Authentication Policy uses Form.
• Authentication forwarding matches the backend application.
• Token rollout, portal access, and helpdesk procedure are prepared.
• Session timeout and session lifetime are consciously set.
• OTP app and hash algorithm have been tested.
• Fallback admin access is available.
• Rollback and responsible person are documented.
• Authentication source and backend login have been separately checked.
• Log Viewer and reverseproxy.log have been checked after the test.
• Go-live support window and token reset procedure are established.
• Alternative hostnames, paths, and WAF rules have been checked for MFA bypass.
• Temporary pilot exceptions have been removed after rollout.

Frequently Asked Questions