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.

The version matters: Integrated MFA for WAF is an SFOS 22 feature. On older firmware versions, WAF publications require different architectures, such as external authentication, a dedicated reverse proxy, VPN, or ZTNA.

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.

Use and planning

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. Sophos WAF does not support WebDAV; applications such as Nextcloud are therefore not supported WAF publications. Plan another architecture with appropriate firewall rules and its own access protection; publishing without WAF does not automatically retain its authentication or application protection.

WAF protects at Layer 7 against threats including cookie, URL, and form manipulation. The web server, Protection Policy, and Authentication Policy are associated through the WAF rule; a maximum of 60 WAF rules is supported. Manage the WAF service under System services > Services. Restarting the service affects published applications and is not the first response to an individual login failure.

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.

• Application is intended for only a few internal users: Consider VPN, ZTNA, fixed source networks, or non-public publication.
• Application contains particularly sensitive data: Additionally check backend permissions, logging, audit trail, and application sessions.
• Application needs WebDAV: Choose another architecture; a pilot does not turn missing WAF support into a supported solution. For other special protocols, check compatibility separately before rollout.
• External partners access infrequently: Clearly document token rollout, support process, and fallback.
• Backend has its own login and roles: Consider WAF-MFA only as an additional layer, not as a replacement for backend roles.

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.
• The firewall runs SFOS 22 or later.
• 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

Configuration components

Several settings must align for WAF-MFA:

• MFA setting: Determines which users use MFA and whether Web application firewall is protected.
• WAF authentication policy: Defines login mode, users/groups, template, and session behaviour.
• WAF rule: Links the published web server with the authentication policy.
• Backend authentication forwarding: Determines whether the firewall forwards login data to the web server.
• Token rollout: Ensures users can actually generate their OTP code.

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. Set OTP hash algorithm and, if required, OTP timestep settings deliberately. The defaults are 30 seconds for Default token timestep, 2 for Maximum verification code offset, and 10 for Maximum initial verification code offset.
6. Save the configuration.

When Generate OTP token with next sign-in is on, User portal is selected automatically. Users first sign in to the VPN portal or User portal and scan the QR code there. The default administrator can instead use the web admin console when MFA is enforced for that administrator’s web admin sign-in. This onboarding step must work before the first WAF access. General MFA planning is described in Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access.

The two offset values are not the normal fix for an incorrect clock. With a 30-second timestep, a Maximum verification code offset of 2, for example, accepts an unused code from the previous 60 seconds. A larger window makes sign-in more tolerant but also extends the validity of older codes. Correct NTP and the phone’s clock first, and only change the offset for a documented reason.

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 production WAF rule, determine:

• Token creation: Where does the user set up the OTP token?
• Portal access: Is the User Portal or another intended QR-code path accessible to the affected users?
• Authenticator app: Which app is approved and tested with the chosen algorithm?
• Fallback: Who can reset a lost or defective token?
• Emergency codes: Is it clear whether and how additional one-time passcodes may be issued in support cases?
• Support case: What information does the helpdesk need for login problems?
• Communication: What login sequence do users see from go-live?

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 many firewall services, the OTP code is processed as a combination of password and passcode. User communication and the helpdesk runbook should therefore clearly state which input screen users actually see and whether password and OTP must be entered separately or combined. With WAF-MFA and form-based login, this point is particularly important because a second backend login is otherwise quickly misread as “MFA broken”.

Sophos Authenticator should no longer be planned as the new standard app because the app has been End of Life since 2022. In practice, Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify, or an internally approved app should be tested. What matters is not only the app name, but whether it correctly supports the firewall’s chosen algorithm, timestep, and QR code.

The mobile operating system also matters during rollout. QR scanning in the Okta app doesn’t work for these tokens on iOS or Android. On iOS, the same restriction also applies to Google Authenticator, Duo, and Microsoft Authenticator. In these cases, the user must enter the Base32 secret manually. Include this in the user guide; an otherwise correct firewall configuration can look broken when the runbook only covers QR scanning.

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 during a production 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, set the client mode to Form. Form-based authentication creates session cookies and permits a dedicated sign-out; the firewall controls login through the 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.

The SFOS 23 XML API documentation describes the optional RedirectToRequestedURL parameter only for the Form client mode, with the values Enable and Disable. With Enable, the user is redirected to the originally requested URL after successful authentication. The documentation specifies no default for this parameter; the API parameter is not an established GUI field label. Redirection replaces neither authentication nor authorization checks.

Choose authentication forwarding correctly

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

• None: No backend authentication by the firewall; frontend authentication remains active. Removing a Basic header supplied by the client additionally involves Remove basic header.
• Basic: The firewall forwards the username and password to the backend via HTTP Basic Authentication.

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.

With None, also check whether Remove basic header must be set. This prevents a Basic Authentication header sent by the client from being unnecessarily passed to the web server. This is especially important when old clients, saved browser data, or earlier publications still generate Basic headers.

⚠️ 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.

The client mode Basic does not create session cookies and does not offer a dedicated logout. Sophos therefore requires the Form client mode for WAF-MFA. Independently of that choice, the Authentication forwarding mode must match the backend.

In the Basic client mode, Basic prompt is only the message shown in the browser dialog. In the Basic forwarding mode, Username affix adds a configured prefix or suffix when only a username is entered. Check fully qualified login names separately so the domain or suffix does not reach the backend twice. HTTP Basic follows RFC 7617; its encoding does not encrypt credentials.

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. The following checklist and the association through Protected servers apply to SFOS 22; SFOS 23 additionally requires the explicit per-path checks under Traffic routing described afterwards.

Saving a WAF rule restarts all web server protection rules. Existing connections through those rules are lost and must be re-established. Coordinate the change with the owners of all affected applications in a suitable change window, preserve the previous settings, and then check reachability, login with OTP, and backend access. This effect and the recovery path have not been tested on an appliance here.

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.

SFOS 23: Assign MFA to Every Portal Path

The outer rule action Protect with web server protection alone is not sufficient. The path configuration must be correct for every portal path to be protected, on every published hostname and in every associated WAF rule; the existing MFA steps and session limits remain unchanged.

1. Under Traffic routing, edit or add each protected portal path and set Action > Protect. Assign the intended backend objects from Web server > Web servers.
2. In the Authentication field, select the intended Authentication Policy. It must use the Form client mode and include the intended user group; the group assignment must match the MFA configuration. Check Allowed client networks and other source and access restrictions, including deliberately chosen network and country blocks, for each path.
3. If only specific portal paths are allowed, retain / with Block as the fallback route. If Protect for / is intended to publish the entire application, assign the same intended authentication and appropriate access restrictions there. Explicitly check alternative paths and hostnames for equivalent protection or intentional blocking.
4. Retain the existing tests for successful login with password and OTP, backend function, logout, session expiration, and re-login. Incorrect OTPs and users outside the allowed group must fail; alternative paths or hostnames must not open up unprotected access. Correlate the client result with WAF, authentication, and backend logs.

Documentation boundary for Passthrough: The rule overview describes authentication as a function of Protect; at the same time, the settings table provides an Authentication field for the Passthrough routing action. This discrepancy establishes neither MFA enforcement nor an MFA bypass with Passthrough. Therefore, base required WAF-MFA on explicitly configured Protect paths, not on unconfirmed Passthrough behaviour. Coordinate required WebSocket tunnels separately with those responsible for WAF routing and authentication.

Basic with passthrough refers to an authentication mode for forwarding credentials; Passthrough under Traffic routing, by contrast, is a routing action for handling traffic. The similar name does not establish any MFA property. For basic publication, those responsible must review the SFOS 23 path configuration together with the MFA assignment: the unchanged Sophos attack-protection tutorial is not a complete SFOS 23 routing guide, and WAF rules support only IPv4.

Safely customise an Authentication Template

Create a custom form under Web server > Authentication templates > Add. The HTML must retain the form with action="<?login_path?>" and method="POST", as well as the httpd_username and httpd_password fields. For MFA, otp_field must also be present. Removing or renaming these elements can break login even when the page looks correct.

For images, styles, and scripts, SFOS provides placeholders including <?assets_path?>, <?admin_contact?>, <?company_logo?>, and <?company_text?>. Uploadable assets are limited to .jpg, .jpeg, .png, .ico, .css, and .js. Test the template with a pilot user first; production credentials, external trackers, and unreviewed JavaScript do not belong on the login page.

After Add, enter a name, select the HTML file and its assets, click Upload, then Save. Select the saved template in the Form authentication policy. This minimal form retains the required technical names; it is a documentary example, not an appliance-tested template:

<form action="<?login_path?>" method="POST">
  <label>Username <input name="httpd_username" type="text"></label>
  <label>Password <input name="httpd_password" type="password"></label>
  <?otp_field?><label>OTP <input name="otp_field" type="password"></label><?otp_field?>
  <button type="submit">Login</button>
</form>

Conflicts in the template documentation: One short password example uses type="text", whereas the field definition and full example show type="password". Keep the password field masked. A note also names only <?login_path?> as substituted, but the optional table describes substitutions for <?assets_path?> and <?admin_contact?> too. This does not establish behaviour on every firmware version. Before rollout, check the rendered form, asset paths, OTP entry, and login with a pilot group; do not replace a working template without validation.

<?assets_path?> refers to uploaded accompanying files, for example in <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. This keeps images and CSS outside the form. The field description links <?admin_contact?> to Administration > Notification settings > Email settings > Send notifications to email address; check whether that address may be displayed publicly. Replace <?company_logo?> with your logo path and <?company_text?> with the intended visible text rather than assuming automatic substitution. If placeholders remain visible or login fails, return to the saved working template and investigate with support instead of disabling MFA.

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.

Maximum sessions is shared across all WAF rules using Form authentication. At the limit, the firewall closes old or expired sessions to allow new ones. Repeated login prompts can therefore reflect global capacity, not just an individual policy’s timeout.

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.

If a very large number of users or several WAF portals use the same firewall, the global session limit should not be checked only after error messages appear. Form-based WAF authentication is a shared reverse-proxy operating parameter and therefore belongs in capacity and monitoring considerations.

Handle global WAF settings safely

Web server > General settings affects all protected web servers, not just the MFA portal. Before changes, preserve the values, identify affected applications and client compatibility, and plan a maintenance window and recovery path. These notes are documentarily checked; their effects and rollback have not been tested on an appliance.

Slow HTTP protection limits waiting for incomplete request headers. In a Slow HTTP DoS, slowly arriving pieces keep connections occupied until no capacity remains:

• Soft limit: minimum time to receive a request header.
• Hard limit: maximum time to receive the header.
• Extension rate: data amount in bytes; exceeding it extends the soft timeout by one second each time.
• Skipped networks/hosts: targeted exceptions. Use only IP host types IP and Network, not IP ranges or IP lists. Broad exceptions also remove protection for unwanted clients.

After adjustments, check normal and slow legitimate clients and the other WAF applications. Do not adopt arbitrary timeout values as a general login fix.

TLS version settings determines allowed client connections. The documented profiles also differ in their ciphers:

• TLS v1 or later: excludes SSLv3; a legacy profile, not a recommendation for new portals.
• TLS v1.1 or later: excludes SSLv3 and TLSv1; likewise not a modern rollout default.
• TLS v1.2 (wide compatibility): TLSv1.2 only, including unrecommended legacy ciphers.
• TLS v1.2 (strict): TLSv1.2 only with recommended ciphers.
• TLS v1.3: TLSv1.3 ciphers only.

Check client support before selection; for example, IE 8 or earlier and Windows XP cannot connect with TLS 1.2. Do not achieve legacy compatibility by indiscriminately weakening security. Test a strict profile first with the clients actually required and all published applications.

With Custom TLS, Protocols, Cipher suite, and TLS v1.3 cipher suite only use OpenSSL syntax. TLSv1.3 ciphers belong only in the separate TLSv1.3 field, not in Cipher suite. Invalid protocols or ciphers can prevent Apache from starting and impair WAF. Do not experiment with production Custom TLS without validated settings; if it fails, restore saved values and check service status and HTTPS access to all affected portals.

SFOS 23 – Worker customization: The firewall calculates WAF capacity from CPU and RAM. Calculated values are hardware-optimized; most deployments need no changes. Higher values can worsen WAF performance and system resource usage. Enable Use custom worker profile only after careful capacity and impact assessment, not as a generic login fix:

• Start servers: worker processes at web server startup.
• Server limit: maximum worker process count.
• Minimum spare threads: minimum idle threads kept available.
• Maximum spare threads: idle thread threshold above which excess threads are removed.
• Threads per child: maximum threads per worker process.
• Asynchronous request worker factor: controls process scaling for asynchronous connections and requests.

Do not copy universal numbers from other systems. Save baseline values, observe representative load and resources, and retest login, OTP, sessions, and backend access after each justified change. If performance worsens, restore the saved baseline configuration; successful rollback is not claimed here.

Automating WAF authentication via the XML API

Automation involves three separate objects: FormTemplate provides the login form, ReverseAuthentication defines client and backend authentication, and FirewallRule binds the policy to the published service or its paths. First, back up the working template, policy, and all rules that use them. Access, explicit write operations, response evaluation, and safe retries are explained in Securing Sophos Firewall XML API access. The following information describes the SFOS-22/23 references, not a write procedure tested on an appliance. Before making changes, check the API help for the installed build; do not write if fields or upload bindings remain unresolved.

Distinguishing client mode, backend, and sessions

In the ReverseAuthentication object, Name, VirtualWebserverMode, and RealWebserverMode are described as required fields. Name allows a maximum of 60 characters. VirtualWebserverMode selects Basic or Form for the client; the documented default Basic is not an MFA recommendation. Form remains required for WAF MFA. BasicPrompt is the optional Basic prompt text, with a maximum of 255 characters. In Form mode, FormTemplate references the saved template. UserGroupList contains repeatable UserGroup entries for existing users or groups; this selection must still match the MFA group. The word Mode in applicability notes is not an additional documented XML tag.

RealWebserverMode independently selects Basic or None for the backend; here, too, the table lists Basic as the default. With Basic, UsernameAffix is part of the backend login. Prefix and Suffix are optional text values, each with a maximum of 255 characters, and are intended only for the corresponding affix selection. With None, RemoveBasicHeader with Enable or Disable is relevant instead. The default ON noted there is not itself a valid input value; use explicit values only after checking the build. The existing HTTPS, backend, and username checks remain necessary.

Do not carry contradictions over into a payload: For UsernameAffix, the XML example shows None/Prefix/Suffix/PrefixAndSuffix, whereas the table lists Basic, Prefix, Suffix, PrefixandSuffix, and at the same time the default None. Do not guess either the spelling or additional selection values. Likewise, the example shows SessionTimeout and SessionLifetime as switches, their respective Limit fields as integers, and the Scope fields as Hours/Minutes/Days. The table confirms the range 1 to 9999 for SessionTimeoutLimit, but swaps integer and switch for SessionLifetime and SessionLifetimeLimit; values such as ON and 8 Hours do not consistently match the data types. These inconsistencies do not establish reliable defaults or an executable session configuration. Confirm the desired inactivity limit and maximum lifetime in the installed build, read back the saved state, and perform the existing session, logout, and repeat-login tests. The SFOS-23 addition RedirectToRequestedURL and its separate redirect test remain independent of this.

Associating the template and supporting files

The FormTemplate reference shows FormTemplate as an object with Name, Description, Template, and Assets, including repeatable Asset entries. Name and Template are required fields: the name allows a maximum of 60 characters, and Template is a string with a maximum of 255 characters for selecting and uploading the HTML template. Description is optional. The optional Asset strings each allow a maximum of 255 characters and multiple values for images, stylesheets, or JavaScript files used.

The example leaves Template and Asset empty. It therefore specifies neither multipart part names nor file paths, Base64 encoding, or directly transferable HTML content. Do not apply a certificate upload binding to FormTemplates. Without a confirmed upload contract, use the existing GUI sequence Upload > Save, then select the saved template via FormTemplate in the Form policy. The required form fields and permitted asset file types from the previous section still apply. Test the rendered form, assets, and OTP login with a test user; successful object storage alone does not prove that the form works.

Binding the Authentication Policy to the rule

For FirewallRule, this association concerns the WAF branch HTTPBasedPolicy, not NetworkPolicy or UserPolicy. The parameter table describes Authentication as an optional scalar string for an Authentication Policy. In the path example, the corresponding association appears as AccessPaths > AccessPath > auth_profile. The example comment separates the rule-wide variant with Authentication and source controls from AccessPaths; it does not establish arbitrary combinations or automatic inheritance. Do not mix rule-wide and path-specific syntax without checking it, and do not assume that a policy present on the firewall already protects every path.

In SFOS 23, the table describes path as a required array of strings with multiple values, a maximum of 63 characters, no commas, and UTF-8 support; SFOS 22 specifies a scalar here. The example uses both path and Path. backend is optional in the SFOS-23 table; this is not a guarantee that a protected portal will work without a backend. The new path-specific action literally shows 0/1/2/3, without a reliable mapping to the GUI actions. Do not guess a numeric mapping or equate these values with the network field Action. Routing, backend, and protection profile are explained in WAF: Publishing web servers securely.

For the authentication change, first read the actual hostnames and paths of the target rule, associate the desired Form policy with each protected path, and then compare the saved state with the intended state. Test all alternative paths, hostnames, and rules, as well as incorrect OTPs and users outside the group. The previously described Protect controls, the Passthrough documentation limitation, and the change window for WAF rules continue to apply unchanged.

Evaluating object responses before a retry

The following mappings are XML status values and literal, unresolved Message.* symbols from the reference, not HTTP status codes or verified runtime message texts. For the FirewallRule binding, the differences between Add and Edit are particularly important:

• Add firewall rule: 200 / Message.FWRuleAddSuccess, 500 / Message.FWRuleAddFail, 502 / Message.FWRuleRecordExists.
• Edit firewall rule: 200 / Message.FWRuleEditSuccess, 202 / Message.FirewallRuleUpdateWithRename, 500 / Message.FWRuleEditFail, 502 / Message.FWRuleUpdateRecordExist. For 202, also read back the actual name and all associations.
• Different mappings: Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. The same code alone is not sufficient for interpretation.
• Additional distinguishing rows: Edit 552 / Message.CannotImportDiffPolicytypeWithSameName; Add 554 / Message.CannotUseFQDNWildCardAsProtectedServer, Edit 554 / Message.CannotUpdateFQDNWildCardAsProtectedServer.
• Delete firewall rule: 200 / Message.FWDelSuccess, 500 / Message.FWRuleDeleteFail, 596 / Message.CMLOCALOperationrestriction. 596 also appears for Add and Edit; clarify the actual permission and management state rather than bypassing it through blind retries or deletion. Deleting a rule is not a way to repair a missing authentication binding.

The two preceding objects also have their own responses:

• Add Authentication Policy: 200 / Message.ReverseAuthAddSuccess, 500 / Message.ReverseAuthAddFail, 502 / Message.ReverseAuthRecodExist.
• Edit Authentication Policy: 200 / Message.ReverseAuthUpdateSuccess, 500 / Message.ReverseAuthUpdateFail.
• Add FormTemplate: 200 / Message.FormTemplateAddSuccess, 500 / Message.FormTemplateAddFail.
• Edit FormTemplate: 200 / Message.FormTemplateUpdateSuccess, 500 / Message.FormTemplateUpdateFail, 502 / Message.FormTemplateRecodExist. The spelling Recod in these symbols is preserved literally; do not infer an additional status for another operation from it.

Record the operation, code, actual response, and saved state of the template, policy, and target rule together. In the event of errors, warnings, or an unclear response, first check what was actually applied; do not bypass the issue by using a second name, a broader group, or an unprotected path. If syntax or upload mapping remains unresolved, stop and involve Support with sanitized data. Only after storage has been confirmed should the existing positive and negative MFA, backend, session, logout, redirect, and alternative-path tests follow. A documentation review does not replace acceptance testing on your own firewall.

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.
• Changes to the token timestep apply only to newly generated tokens and must match the app used.

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

If a user loses the app or the algorithm is changed, repeating the user communication is often not enough. Under Authentication > Multi-factor authentication > Issued tokens, tokens can be reset or additional one-time codes can be generated. This process should be governed internally because it has a strong security impact.

Validation and operation

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.
9. Check logout, re-login, and session expiration with the same browser.
10. Test with a second hostname or alternative path if the application uses multiple WAF rules.

To additionally test the return to the requested URL on SFOS 23, open an actually protected URL with a path other than /, without a valid WAF session. After successful login with password and OTP, with RedirectToRequestedURL set to Enable, check that the exact originally requested URL is reached and that backend access respects the intended permissions. Successful redirection alone is not proof of MFA or authorization; all the negative, backend, session, logout, re-login, and alternative-path tests above remain required.

For log files, see Sophos Firewall Troubleshooting: Services and Logs. WAF events are typically associated with the reverse proxy and also appear in the Log Viewer.

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

• User: The firewall login appears, the OTP is requested, and then the expected application opens.
• Sophos Firewall: Log Viewer and reverseproxy.log show an allowed or denied WAF authentication attempt.
• Authentication source: AD, LDAP, RADIUS, or the local user source shows the expected successful or failed login.
• Backend: The application reaches the correct user or guest state and does not show an unexpected second error page.

If only the browser appears successful but no corresponding logs are visible, the acceptance is incomplete. Check whether the correct WAF rule is being applied, whether the authentication policy is really active, and whether the logs are written to the expected location.

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:

• Rollout group: Start with the pilot group, then add further user groups.
• Support window: Keep the helpdesk or responsible administrators available during the first logins.
• Monitoring: Monitor Log Viewer, reverseproxy.log, and the authentication source.
• Token reset: Define a clear procedure for lost or incorrectly configured OTP tokens.
• Session behaviour: Check session timeout and session lifetime after real-world use.
• Fallback path: Keep the WAF rule, authentication policy, and change steps documented.

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.

Troubleshooting

Other common errors

• Authentication policy does not use Form: MFA behaviour does not match the expected WAF configuration.
• Sophos Authenticator planned as the new standard app: The app is EOL and should no longer be used as the basis for a new rollout.
• Fallback access depends on the same WAF rule: Administrators cannot properly revert the change in case of an error.
• Token rollout was not tested: Users fail during their first login even though the WAF rule is technically correct.
• A second URL or WAF rule remains active without MFA: Users unintentionally bypass the preliminary MFA.
• Temporary pilot exceptions are not removed: Production protection is inconsistent and difficult to audit.

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.

Backend asks for login again after successful MFA

On SFOS 22.0 GA Respin Build 411, NC-177509 can occur: form-based WAF-MFA succeeds, but the backend then requests another login that cannot be bypassed. The OTP code is not stripped from the password before the firewall forwards the credentials to the backend. This issue is fixed in SFOS 22.0 MR1 Build 490 and later.

The correction for the unstripped OTP code also has the reference NC-177201. The IDs aren’t interchangeable: NC-177509 maps affected and fixed builds, while NC-177201 identifies the specific fix text. Include the symptom, build, and both references in a support case.

Check:

• WAF Authentication Policy uses Form.
• Authentication forwarding mode is active and matches the backend application.
• The affected WAF rule uses exactly this Authentication Policy.
• The error occurs after successful MFA, not already during firewall login.
• reverseproxy.log, Log Viewer and backend access log cover the same test time.
• The deployed SFOS version has been checked.

On an affected GA system, preserve reverseproxy.log, Log Viewer, and the backend log, and plan an update to MR1 Build 490 or later. If a prompt update isn’t possible, don’t make unverified changes to the authentication flow; use the preserved data to open a Sophos support case. Do not weaken MFA or change Authentication forwarding indiscriminately: None is appropriate only when the backend doesn’t require forwarded credentials. For production portals, include test users, rollback, and user communication in the plan.

Too many or old sessions

Check session timeout, session lifetime, and the global WAF session settings. In production 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