Sophos Firewall WAF: Securely Publish Web Servers

With Web Server Protection or Web Application Firewall (WAF), you can publish internal or cloud-based web applications via the Sophos Firewall. The firewall acts as a reverse proxy: clients connect to the public address of the firewall, which checks HTTP or HTTPS traffic and forwards the request to the protected web server.

For the broader hardening context, use the hub Sophos Firewall Hardening: best practices for secure configuration.

A WAF rule does not automatically replace secure application development, patching, strong authentication, or server hardening. However, compared to simple port forwarding, it significantly reduces the attack surface because HTTP(S) traffic can be more precisely inspected, restricted, and logged.

WAF is still not automatically the right answer for every publication. The key is whether the application actually works cleanly over HTTP or HTTPS, whether the firewall should evaluate hostnames and paths, and whether the additional reverse proxy layer fits the application.

Decision Before Publishing

When WAF is More Suitable than DNAT

For simple TCP or UDP services, NAT and firewall rules are still used. For web applications, WAF is often the better choice.

• DNAT fits non-HTTP services, simple port forwarding, and special protocols. The firewall then primarily translates and allows the traffic.
• WAF / Web Server Protection fits HTTP and HTTPS applications when hostname, certificate, paths, protection profiles, authentication, or country rules are relevant.
• Reverse Proxy or ZTNA fits complex web platforms, identity integration, and private applications when access should be tightly controlled or not public at all.

If you just want to quickly make an internal web server accessible via port forwarding, the guide Publish Server via DNAT on Sophos Firewall can help. For public web applications, WAF should be considered first.

⚠️ WebDAV is not supported by Sophos WAF. Therefore, applications like Nextcloud should not be blindly published via WAF but planned with appropriate firewall and NAT rules or another publication architecture.

Decision: WAF, DNAT, or Private Access

The most important question is not how quickly a publication is built, but whether it can be operated securely, tested, and rolled back later. This classification helps before technical implementation:

• Public website or simple HTTPS application: WAF is usually the suitable starting point. DNS, certificate, hostname, protection profile, logging, and backend reachability must be tested.
• Customer portal, partner portal, or admin interface: WAF with source limitation and optional MFA can make sense. First clarify whether WAF-MFA, country rules, or fixed source networks are possible.
• Pure TCP or UDP service: DNAT is usually more suitable. Firewall rule, NAT rule, target server, return route, and logging must be checked together.
• Web application with WebDAV or special protocol: Do not automatically use WAF. Test supported functions, client behaviour, and alternative publication.
• Application only for internal users: Check VPN, ZTNA, or heavily restricted WAF. Public accessibility should be critically questioned.

For private applications, a globally accessible WAF rule often presents too much of an attack surface. If only a few people need access, fixed source networks, VPN, ZTNA, or another private access architecture are often cleaner than a public web publication.

Planning and Prerequisites

Prerequisites

Before the first WAF rule, clarify these points:

• Public DNS name, for example, portal.example.com
• Public IP address or alias on the WAN interface
• Certificate for the published hostname
• Internal IP address or FQDN of the web server
• Internal target port of the web server
• Decision whether HTTP is redirected to HTTPS
• Allowed source networks, countries, or user groups
• Suitable protection profile and optional IPS policy
• Enabled logging for later analysis
• External test access outside your own LAN

The public DNS name must point to the address used as the Hosted address in the WAF rule. For HTTPS, the certificate must match the published hostname.

The firewall also needs a web server object under Web server > Web servers. This defines the internal or external target server with host, protocol, and port. The host is an IP or FQDN host object. HTTP or HTTPS can be used for backends; standard ports are 80 and 443. If the backend web server delivers long responses or needs keep-alive, Keep alive and Timeout should be checked deliberately instead of inherited by chance.

In addition, consider the limits of Web Server Protection early. Sophos states, among other things, a limit of 60 WAF rules per firewall. That is enough for many environments, but can become relevant faster than expected with many customer portals, tenants, test systems, or separate hostnames. In that case, do not blindly build more individual rules; review naming concept, paths, virtual web servers, and alternative publication methods.

WAF rules are also designed for IPv4 publication. If an application must be published via IPv6, the design must be checked separately. The Exchange templates are also not a blank cheque for modern Exchange environments: Sophos documents that WAF rules currently do not support Exchange versions after 2013.

Plan WAF Release Before Configuration

A WAF rule should not be planned only in the interface. It must be clear beforehand whether the Sophos Firewall should only publish or also handle authentication, protection profiles, country rules, and logging.

These questions are important before a productive publication:

• Is it really an HTTP or HTTPS application? For other protocols, DNAT is usually more suitable.
• Does the application need to be publicly accessible? Private admin portals often fit better with VPN, ZTNA, or restricted source networks.
• Which hostname and certificate are used? DNS, SNI, certificate, and WAF domains must match.
• How many publications are planned? The WAF rule limit and later operability influence the design.
• Should the firewall authenticate users? For portals, WAF-MFA can be useful.
• Which protection profiles are active? Too broad exceptions weaken the WAF, too strict profiles can break applications.
• How is logging and testing done? Log Viewer, reverseproxy.log, and backend logs must be known before go-live.

For certificates, clarify early whether an existing certificate will be imported, whether the firewall itself should create and renew a Let’s Encrypt certificate, or whether an externally generated certificate is needed. There is a separate guide for wildcard certificates: Create Let’s Encrypt Wildcard Certificate.

Configure WAF Rule

Basic Structure of a WAF Rule

A WAF publication consists of several components:

• Hosted address: Public IP address or alias where clients reach the application.
• Listening port: Public port, usually 80 or 443.
• Domains: Hostnames that should match the WAF rule.
• HTTPS certificate: Certificate for the published hostname.
• Web server: Previously created web server object with host, protocol, port, and connection settings.
• Allowed client networks: Source networks allowed to access.
• Blocked client networks / countries: Sources or countries to be blocked.
• Protection policy: WAF protection against typical web attacks.
• Authentication: Optional pre-authentication via the firewall.

Sophos creates WAF rules in the firewall rules section. The action is called Protect with web server protection.

Important: a WAF rule is not a normal firewall rule with NAT behind it. It creates a reverse proxy publication. Therefore, Hosted address, Listening port, Domains, certificate, Protected server, and Allowed client networks must fit together. If one of these fields does not fit, the error often looks like a certificate, DNS, or backend problem.

Create a WAF Rule

The menu path is:

Rules and policies > Firewall rules

Procedure:

1. Select IPv4.
2. Open Add firewall rule.
3. Select New firewall rule.
4. Assign a descriptive rule name.
5. Set Rule position deliberately, especially if more general WAF rules or old publications already exist.
6. Choose Protect with web server protection for Action.
7. If no special template is needed, leave Preconfigured template as None.
8. Enable Log firewall traffic if the rule should be visible in Log Viewer and reports.
9. Under Hosted server details, define the public address, listening port, HTTPS, certificate, and domains.
10. Under Protected servers, select the matching web server object or create it first under Web server > Web servers.
11. Set Allowed client networks consciously. For public websites, Any IPv4 may be necessary; for portals, a restriction is usually better.
12. Set Blocked client networks or Blocked countries if needed.
13. Check protection profile, IPS, and advanced options.
14. Save the rule and test externally.

When the rule is saved, Sophos restarts the Web Server Protection rules. Existing live connections over these rules may be interrupted. Therefore, changes to productive WAF rules should be made during a maintenance window or at least consciously.

If Allowed client networks remains empty, the WAF rule does not work correctly; the browser can then receive a 400 Bad Request. For a public application, Any IPv4 is possible, but not automatically right. For admin portals, partner portals, or internal tools, first check fixed source networks, country restriction, WAF-MFA, VPN, or ZTNA.

Port conflicts should be clarified before saving. Depending on the Hosted address, WAF can use the same port as SSL VPN, but not the same port as the User Portal. If WebAdmin, VPN Portal, User Portal, or an old DNAT publication is already listening on a public IP, the assignment must be unambiguous. Otherwise, the later error looks like a WAF problem even though another function is responding.

Go-live and Acceptance

Plan Go-live and Rollback

A WAF publication should not be considered complete just by saving the rule. The key is whether DNS, certificate, hosted address, backend, protection profile, and logging work together. Especially with existing port forwarding, treat the switch like a small publication.

Before go-live, check:

• Document the current firewall configuration or at least the affected rule and certificate settings.
• Identify previous DNAT or firewall rules affecting the same port, public IP, or hostname.
• Deactivate old DNAT rules or clearly document why they do not compete with the WAF rule.
• Reduce DNS TTL before a switch if the public hostname changes from an old publication to the WAF.
• Provide external test access, not just test from the internal LAN.
• Define test cases: homepage, login, upload, download, API path, WebSocket, logout, and error message.
• Set expected log points: Log Viewer, reverseproxy.log, backend access log, and backend error log.
• Define rollback criteria, such as login not possible, backend not reachable, wrong certificate, high error rate, or critical application parts defective.

During the switch, only one publication should be active at a time. If an old DNAT rule and a new WAF rule use the same public IP and port, the behavior is difficult to understand. Before switching to production, it should be clear which rule actually processes the traffic.

A simple rollback often involves deactivating the new WAF rule and reactivating the previous publication. If DNS was also changed, the DNS TTL must be considered. In cases of certificate or hostname issues, a rollback via DNS alone is often too slow; in such cases, the old rule should be reactivatable on the same hosted address or an alternative access should be available.

After go-live, the first accesses should be actively monitored. Important are not only successful HTTP status codes but also WAF blocks, backend errors, unexpected redirects, session problems, and missing client IP information in the backend logs.

Acceptance Test After Go-live

A WAF test is only complete when the same request is traceable from three perspectives: client, firewall, and backend. This helps quickly identify whether a problem lies with DNS, certificate, WAF matching, protection profile, or application.

• External client: Check DNS resolution, certificate, HTTP status, login, and important paths. The application should open via the public hostname without certificate warning.
• Sophos Firewall: Check Log Viewer, WAF rule, reverseproxy.log, and blocked signatures. The correct WAF rule should process the access and logs should show allowed or justifiably blocked requests.
• Backend web server: Check access log, error log, application session, and X-Forwarded-For. The request should reach the correct vHost or path, and the client IP logic must be understood.

For productive applications, at least these cases should be tested:

• Access via the correct hostname and via a non-matching domain.
• Login with valid and invalid user if the application or WAF authenticates.
• Upload, download, API, or WebSocket function if the application uses such functions.
• Access from an allowed source and, if possible, from a deliberately not allowed source.
• Behavior of a known harmless WAF test request to make logging and block path visible.

If the application seems to work after go-live but no matching logs are visible, the test is not yet complete. It may be that another publication matches, logging is missing, or access does not run through the expected path.

Secure Protection and Access

Certificates and Hostnames

For HTTPS, the WAF rule must use a certificate that matches the public hostname. The certificate is imported or created under Certificates > Certificates and then selected in the WAF rule.

Important points:

• The DNS name must match the certificate.
• The selected HTTPS certificate can automatically fill the domain list in the WAF rule or overwrite existing domain entries.
• For multiple hostnames on the same IP, the firewall uses SNI.
• Wildcard certificates are possible but should be well documented.
• Wildcard domains are only used after more specific domain rules.
• Underscores in the left-hand domain label are not a clean DNS name and should be avoided for WAF domains.
• The backend can use a different internal name if host headers and the application can handle it.
• For problems with absolute links, Rewrite HTML may become relevant.

When multiple virtual web servers run on the same IP and port, the firewall decides which WAF rule fits based on SNI and hostname for HTTPS.

The domains in the WAF rule should therefore match DNS and certificate exactly. Wildcards can be helpful, but they should not replace a clean publication concept. If several applications run under similar hostnames, clear rule and certificate documentation is needed; otherwise, it later becomes hard to trace which WAF rule actually matched. A test with a deliberately non-matching subdomain is useful: it shows whether the specific rule, a wildcard rule, or no matching virtual web server responds.

Plan Client IP and Backend Logs

In WAF publications, the internal web server often does not see the real client IP as the direct source address. The Sophos Firewall acts as a reverse proxy and establishes the connection to the backend itself. Therefore, the firewall address may be visible first for the application and web server logs.

If the application or backend needs the original client IP, check early whether X-Forwarded-For or a comparable header is evaluated. This is important for:

• Application logs and security evaluation
• Rate limits or login protection at the application level
• Error analysis with user or source IP reference
• SIEM or monitoring correlation
• Forensic evaluation after an incident

The trust boundary is important: a backend should only treat such headers as trustworthy if the request really comes from the Sophos Firewall or a defined reverse proxy. Public clients should not be able to set X-Forwarded-For directly as a security proof. In practice, the web server should therefore only trust the firewall IP and ignore or overwrite headers from other sources.

For troubleshooting, this means: Log Viewer, reverseproxy.log, and backend log must cover the same test time. If only the firewall IP is visible in the backend, this is not automatically a WAF error but often normal reverse proxy behavior.

Restrict Client Access

Not every web application needs to be accessible worldwide. Access can already be limited in the WAF rule.

Sensible restrictions:

• Allow only known source IP addresses or partner networks.
• Block unnecessary countries.
• Only block IP addresses of unknown country origin if the risk of self-lockout has been assessed.
• For portals, additionally use WAF-MFA or pre-authentication.
• Block known malicious sources via Threat Feeds.

For country and bad IP blocking, Sophos Firewall: Block Countries and Malicious IPs helps. For dynamic threat lists, Sophos Firewall Threat Feeds is relevant.

Plan Threat Feeds and Active Threat Response

For publicly accessible web applications, you should not only consider the WAF rule itself. Since SFOS 22, Threat Feeds are also more relevant for incoming, forwarded traffic like WAF and DNAT publications. The firewall can match such hits with MDR Threat Feeds, NDR Essentials, and Third-Party Threat Feeds.

For administrators, this means: WAF is the publication layer, Threat Feeds and Active Threat Response can additionally block or make visible known malicious sources. However, this does not replace patch management, clean authentication, and application hardening.

Practically, you should check:

• Is Active Threat Response sensibly configured in the environment?
• Are relevant Threat Feeds used and regularly checked?
• Are WAF events, Active Threat Response logs, and backend logs visible in operation?
• Is there a process for false positives, allowlisting, and emergency approvals?
• Is it clear who responds to hits and whether only logged or actively blocked?

Especially for customer portals, admin interfaces, or partner accesses, this check should happen before go-live. If a feed later blocks productive traffic, operations must know where to see the hit and how to decide cleanly: real attack, false alarm, or incorrectly published application.

Protection Profiles and Exceptions

A WAF rule should not only publish but also protect. For this, use Protection Policies, optional IPS Policies, and exceptions.

Typical protection areas:

• Cookie Manipulation
• URL Hardening
• Form Hardening
• Cross-Site Scripting
• Application Attacks
• Antivirus Scanning
• Bad-Reputation Clients

Additional global Web Server Protection settings are under Web server > General settings, including TLS version control and protection against slow HTTP DoS patterns. These settings do not apply to only one rule. Changes should therefore be planned deliberately and coordinated with existing WAF publications.

For Protection Policies, the mode matters. Reject blocks and creates visible Log Viewer events for WAF rules. Monitor only logs, but these WAF messages do not necessarily appear in Log Viewer; in that case, reverseproxy.log must be checked. Monitor can be useful for a pilot phase, but productive protection requires clarity on whether attacks are only observed or actually rejected.

IPS in a WAF rule should be assessed separately. Sophos only applies IPS for WAF when the communication between firewall and web server uses HTTP. If the backend is connected via HTTPS, do not automatically expect a selected IPS policy to have the same effect.

Exceptions should be set narrowly. If an application does not work because of a single path or a specific source, do not disable the entire protection profile. Better is a targeted exception with path, source, and clear justification.

⚠️ Every exception reduces the protection effect. Path, source, reason, date, and review date should be documented so that temporary workarounds do not remain permanent.

Path-specific Routing, WebSocket, and Load Balancing

WAF can forward requests to different backend servers depending on the path. This is useful if an application has multiple components or a single hostname should be distributed to multiple internal services.

Examples:

• /api/ goes to an API server.
• /shop/ goes to a shop system.
• / goes to the default web server.

Note that the firewall does not simply evaluate paths according to table order. Sophos prioritises longer and therefore more specific paths. Specific paths must therefore be planned and tested cleanly. If WebSocket is needed, WebSocket passthrough can be activated. WebSocket traffic is then passed through without the same WAF inspection because the protocol cannot be inspected like normal HTTP traffic.

The default path / should deliberately remain set. If it is removed, non-matching paths are not forwarded to a default server but rejected with 404 Not Found. That can be intentional, but in a fault case it quickly looks like a backend problem.

With multiple backend servers, sticky sessions or hot standby are possible. This helps with simple high availability or load distribution cases but does not replace a complete application load balancing concept.

If the protected web server is not in the firewall’s local network, routing and SD-WAN should be checked especially deliberately. For backends over site links, MPLS, or route-based IPsec, a matching SD-WAN route may be needed so that the firewall reliably reaches the Protected Server and the return path is correct. With route-based IPsec, also note: WAF over route-based IPsec with Traffic Selectors for subnets is not supported by Sophos; Any-to-Any connections are the documented workaround.

Operation and Troubleshooting

Common Errors

• Public DNS name points to the wrong IP: The WAF rule is never reached.
• Certificate does not match the hostname: Browsers show certificate errors or SNI matching does not fit.
• Wrong Hosted address chosen: The firewall matches another rule or no WAF traffic.
• Allowed client networks empty: The rule does not work as expected.
• WAF rule limit not considered: Further publications can no longer be represented cleanly.
• Exchange version after 2013 planned with WAF template: The template does not fit the supported WAF limit.
• Port conflict with User Portal, VPN Portal, or another service: The application is not reachable or a firewall service responds.
• Backend is not reachable internally: External clients receive errors even though DNS and certificate are correct.
• Backend timeout set incorrectly: Long responses end in errors even though the application is basically reachable.
• Backend is over VPN or SD-WAN without a matching route: The WAF rule matches, but the Protected Server is not reliably reached.
• Route-based IPsec with Traffic Selectors to the backend: WAF over this path is not supported.
• WAF exception set too broadly: The protection effect decreases unnecessarily.
• WebDAV application published via WAF: The application does not work reliably or is not supported.
• Rule change without maintenance window: Existing connections may break when WAF rules restart.
• Old DNAT rule and new WAF rule compete: It is unclear which publication processes the traffic.

Troubleshooting

If a WAF publication does not work, systematically check:

1. Does the public DNS name point to the correct public IP?
2. Is the correct Hosted address selected in the WAF rule?
3. Is the listening port free and not occupied by WebAdmin, User Portal, VPN Portal, or another publication?
4. Does the certificate match the called hostname?
5. Is the internal web server reachable from the firewall?
6. Are Allowed client networks, Blocked client networks, and Blocked countries set correctly?
7. Is the Protected Server behind a route, SD-WAN route, or VPN connection that really fits from the firewall’s perspective?
8. Is there a more general WAF rule that matches first?
9. Is the access shown as allowed, blocked, or dropped in the Log Viewer?
10. Are there any hints in /log/reverseproxy.log?
11. Is the Protection Policy set to Monitor or Reject?
12. Does the timeout of the web server object fit the application?

For initial analysis, the Log Viewer is useful. For deeper troubleshooting, the Web Server Protection logs on the firewall help. An overview of log files and services is available in Sophos Firewall Troubleshooting: Services and Logs.

Checklist for Productive WAF Rules

• Rule name describes application, hostname, and environment.
• Responsible person or system owner is documented.
• DNS, certificate, and hosted address are checked.
• Backend accessibility has been tested from the firewall.
• Previous publication and rollback are documented.
• Old DNAT or firewall rules do not compete with the WAF rule.
• External go-live tests are defined.
• Access is restricted to necessary sources or countries.
• Threat Feeds and Active Threat Response have been evaluated for public applications.
• Logging is active.
• Protection profile is not unnecessarily disabled.
• Exceptions are narrow, justified, and time-limited.
• Change has been tested externally.
• Expiry date or review date is documented.

Frequently Asked Questions