Start Sophos Firewall Configuration With a Network Plan

Before connecting production networks, document the intended traffic paths. Identify every LAN, server, guest, voice, management, DMZ, cloud, and branch network; define their IP ranges; and decide which interfaces or VLANs will carry each segment. A flat network may be fast to deploy, but it turns one compromised endpoint into a wider operational incident.

The initial setup should also establish management discipline. Change default administrative credentials, restrict web administration to a management VLAN or named administrator networks, use multifactor authentication where supported by the chosen identity workflow, set NTP, and configure DNS deliberately. Accurate time is not cosmetic. It is required to correlate firewall, endpoint, identity, and SIEM events during an investigation.

Use meaningful interface, zone, host, and rule names from day one. “Allow_Any_1” creates needless risk during a future audit or incident. “FIN-Users_to_M365_HTTPS” states the source, destination, and intended service in terms another administrator can validate.

A clean baseline normally includes these principles:

• Separate users, servers, guest devices, voice systems, and firewall management.
• Use least-privilege rules between internal zones, not only at the internet edge.
• Define DNS, NTP, directory, backup, and monitoring dependencies before blocking broad outbound traffic.
• Send logs to a retained central platform so events survive a local appliance failure.

Build Firewall Rules Before Adding Exceptions

Sophos Firewall processes rules in order, so policy design has a direct effect on both security and troubleshooting. Create specific allow rules for defined source zones, destinations, services, and users where identity-based control is appropriate. Place explicit deny rules and cleanup controls below approved traffic, then review rules that have no observed use.

Avoid treating an internal network as inherently trusted. A user VLAN may need HTTPS access to a business application on a server VLAN, but it usually does not need unrestricted SMB, RDP, database, or management access. Segmenting these flows can reduce ransomware propagation and make alerts more meaningful.

There is a trade-off. Very granular rules create better control, but they can become difficult to operate if the organization has no ownership process for application changes. The practical answer is not a broad “any” rule. It is a rule standard, a documented application owner, and periodic recertification of high-risk access.

NAT Design: Translate Only What You Intend to Publish

Network address translation is often confused with access control. NAT changes addressing. Firewall rules decide whether traffic is allowed. A DNAT rule that forwards a public address to an internal application does not replace a tightly scoped inbound firewall rule.

For outbound traffic, use source NAT or masquerading only where it is required for internet access. For inbound publishing, create individual DNAT definitions for each public service, map only the required port or ports, and limit source addresses when a partner or supplier has known fixed IP ranges. Publicly exposing RDP, SMB, database listeners, or appliance administration is rarely justified. Use VPN, ZTNA, a hardened jump host, or a purpose-built application access method instead.

Be deliberate about hairpin NAT, sometimes called NAT reflection. Internal users may need to reach a public service name that resolves to an address hosted behind the same firewall. Hairpin NAT can make this work, but split DNS is often clearer and avoids sending internal application traffic out to the firewall only to return inside. The right choice depends on application behavior, certificate requirements, and whether users must receive the same address internally and externally.

After every NAT change, test from the intended source network and from an unauthorized source. A successful connection proves availability. A blocked connection from the wrong location proves the security boundary works.

Configure IPS for Risk, Not Maximum Noise

Intrusion Prevention System policy should protect exposed services and high-value internal paths without making normal business traffic unpredictable. Start with current firmware, current IPS signatures, and a protection policy associated with the appropriate firewall rules. Internet-facing web services, remote-access entry points, and traffic headed to critical server zones generally deserve stronger inspection than a low-risk guest network.

The temptation is to enable every detection in block mode immediately. That can create false positives, particularly for specialized applications, encrypted traffic inspection, legacy protocols, or custom APIs. A staged approach is more defensible: monitor, review events, validate business impact, then block confirmed malicious or irrelevant traffic. Keep exceptions as narrow as possible and record why they exist, who approved them, and when they will be reviewed.

IPS does not replace patching, endpoint detection and response, vulnerability management, or secure application design. It is a compensating and detection layer that can stop known attack patterns and suspicious protocol behavior. It cannot make an unsupported server safe.

SSL/TLS Inspection Requires Governance

Many attacks use encrypted web traffic, but decrypting that traffic has consequences. SSL/TLS inspection can improve visibility and IPS coverage, yet it requires a trusted certificate deployed to managed endpoints and careful exclusions for applications that use certificate pinning, health care portals, banking sites, or other sensitive services.

Organizations should make this a policy and privacy decision as well as a technical one. Define which categories of traffic are inspected, what is excluded, how logs are retained, and who can access them. Test with representative user groups before broad enforcement.

Routing Must Have One Clear Return Path

Routing issues frequently appear as intermittent application failures rather than obvious outages. Sophos Firewall can use static routes, policy routes, SD-WAN routing, and dynamic routing protocols depending on the design. The key requirement is that each flow has a predictable forward and return path.

Static routes work well for smaller, stable environments. They are simple to audit and often sufficient for a primary site, a few private cloud subnets, and a default route to the internet. Dynamic routing can be justified where multiple sites, cloud networks, redundant paths, or frequent route changes would make static maintenance error-prone. It also introduces more operational complexity, authentication requirements, route filtering, and a greater need for monitoring.

Policy-based routing is useful when traffic must leave through a specific WAN connection, such as a voice provider, a partner network, or a SaaS application with controlled egress. Use it carefully with VPN and NAT rules. If policy routing sends a reply through a different interface than the original request arrived on, stateful inspection may drop the session or remote systems may reject the response.

Document gateway health checks and failover behavior. A WAN interface that has link but no usable internet path should not remain the preferred route simply because its Ethernet carrier is up.

High Availability Is More Than Two Appliances

High availability protects against a firewall appliance failure. It does not protect against a poorly designed policy, a shared power problem, a failed upstream switch, a bad firmware change, or an ISP outage. Those distinctions should drive expectations and testing.

For an HA pair, use compatible appliances, appropriate firmware alignment, dedicated synchronization links, and a clear active-passive or active-active design based on the supported operating mode and traffic requirements. Active-passive is commonly simpler to operate and troubleshoot. Active-active can offer capacity benefits in specific designs, but its value depends on traffic patterns and operational skill, not merely the presence of a second appliance.

Connect each unit to redundant switching and power wherever the design supports it. Then test failover during an approved maintenance window. Confirm that internet access, critical inbound services, site-to-site VPNs, remote-access VPN, logging, and administrative access recover as expected. Record actual failover results rather than relying on status indicators alone.

VPN Access Should Be Segmented and Verified

Site-to-site IPsec VPNs are well suited for branch offices, cloud networks, and approved third parties. Define local and remote subnets precisely, use current cryptographic proposals supported by both ends, and avoid overlapping address ranges. Overlapping networks are manageable in some cases with translation or redesign, but they make support and visibility materially harder.

Remote-access VPN requires a different lens. Authenticate users through a managed identity source, require MFA, assign least-privilege access, and limit users to the applications and segments they need. A remote user who only needs an accounting web application should not automatically gain unrestricted access to the server network.

Operationally, test VPN behavior from external networks, not only from inside the office. Validate DNS resolution, split-tunnel versus full-tunnel requirements, access to SaaS services, endpoint posture expectations, and log visibility. Full tunneling provides greater control over remote web traffic but consumes more bandwidth and can affect user experience. Split tunneling reduces load but requires confidence in endpoint security and carefully defined routes.

Operate the Firewall as a Managed Security Control

A well-configured Sophos Firewall needs ongoing attention. Review critical rule changes, IPS events, VPN authentication failures, blocked outbound connections, administrator activity, certificate expiry, interface errors, and HA status. Correlating firewall telemetry with endpoint, identity, vulnerability, and SIEM data provides more useful detection than reviewing each tool in isolation.

Configuration backups should be encrypted, access-controlled, and tested for restoration. Firmware updates need a change window, a backup, compatibility checks, and a rollback plan. The right maintenance cadence depends on exposure and business tolerance, but postponing updates indefinitely is not a defensible strategy for an internet-facing security appliance.

For businesses balancing lean internal IT resources with compliance and resilience requirements, AdvisionIT can assess the existing firewall design, identify unnecessary exposure, and establish a support model that covers policy management, monitoring, upgrades, and documented recovery testing. The best outcome is not simply a firewall that passes traffic. It is a security control your team can explain, verify, and rely on when conditions are not normal.

Author: Yavor Y. Zlatev CEO of AdvisionIT

Date: 14.08.2026