Properly Configure Sophos Firewall After the Setup Wizard

After the Setup Wizard, a Sophos Firewall is accessible, registered, and basically operational. However, it is not yet securely operated. The wizard handles the start, not the productive architecture.

This article consolidates the points that should be checked after the initial setup: internet access, registration, license status, firmware, backup, zones, Device Access, DNS, DHCP, firewall rules, NAT, logging, and initial hardening measures. It is intended as a practical checklist for new XGS hardware, virtual firewalls, and small migrations.

If it involves a migration from XG to XGS, hardware to virtual, or a restore to a replacement device, you should also check Create or Restore Sophos Firewall Backup and Sophos XG vs. XGS: Differences, EOL, and Migration.

Quick Path After First Login

When the firewall just comes out of the wizard, not every detail is immediately urgent. In the first 30 minutes, it’s mainly about not losing access, securing the state, and recognizing the most significant operational risks.

This order is sensible for most new installations:

1. Secure admin access: Document password, Secure Storage Master Key, and a second admin or break-glass access.
2. Check license and registration: Under Administration > Licensing, verify that model, serial number, base license, and subscriptions are correct.
3. Create a backup: Download a manual backup and store it externally before making further changes.
4. Check firmware and patterns: Verify firmware version, hotfixes, and pattern updates, but only install updates with a maintenance window and rollback plan.
5. Limit Device Access: Do not leave WebAdmin and SSH broadly accessible from client, guest, IoT, or WAN zones.
6. Validate zones and interfaces: Check WAN, LAN, VLANs, bridges, management network, and future security zones against the network plan.
7. Evaluate default rules: Do not adopt initial firewall and NAT rules as a finished security design.
8. Enable logging: Turn on Log firewall traffic for important rules so that later tests are traceable in the Log Viewer.

Only when these points are clean should productive traffic, remote access, WAF, SD-WAN, RED, or TLS Inspection be set up. Otherwise, troubleshooting later becomes unnecessarily difficult because it’s unclear whether a problem stems from the basic configuration, a security function, or an application.

Setup Paths by Situation

After the wizard, work quickly branches into several areas. For new firewalls, this order is sensible:

• Central connection: If the firewall should be connected to Sophos Central or the limits of Central should be understood, Connect Sophos Firewall with Sophos Central fits.
• Licence status: For Base License, support and subscriptions, Understand Sophos Firewall Base License helps.
• Backup and restore: Before the first change, Create or restore Sophos Firewall backup should be prepared.
• Management access: WebAdmin, SSH, User Portal or VPN Portal are hardened through Secure Sophos Firewall access: configure Device Access properly.
• Network design: For zones, interfaces, VLANs or bridges, Configure Sophos Firewall zones and interfaces is the better starting point.
• First rules: For firewall and NAT basics, Understand and configure Sophos Firewall rules properly fits.
• DNS and DHCP: Internal name resolution becomes cleaner with Configure DNS Request Routes on Sophos Firewall.
• Reporting: For logs, reports and longer retention, Activate Central Firewall Reporting helps.
• Health Check: Security findings after SFOS 22 can be prioritised with Use Sophos Firewall Health Check properly.
• Upgrade planning: For firmware updates or SFOS 22 upgrades, Check Sophos Firewall before SFOS 22 upgrade fits.

This separation is important because a successful wizard does not mean a finished security architecture. Before productive traffic, management access, backup, license, zones, rules, logging, and protection functions should be consciously checked.

Prepare Before Setup

Before starting the wizard, access, WAN connectivity, management network, and licensing context should be clear. This prevents improvisation during setup and avoids having to correct unclear assumptions later.

Prerequisites for Setup

Before setup, it should be clear how the firewall will be integrated into the network. Many later problems do not arise in the wizard itself but because WAN, LAN, DNS, management access, or license data are improvised.

Have ready before starting:

• Firewall model, serial number, and planned location.
• WAN access data or provider information, such as DHCP, static IP, PPPoE, VLAN, or upstream router.
• Internal target network for the first LAN or management access.
• DNS servers that function during setup.
• Sophos Central access or a person who can generate an OTP for registration.
• Planned admin password and storage location in the password manager.
• Decision whether the firewall will be newly set up directly or restored via backup.

The firewall needs a functioning internet connection for registration, license synchronization, pattern updates, and Central connection. If an upstream device filters outgoing traffic, at least the necessary HTTPS access must work. For more complex provider setups, the WAN access should be consciously planned first, rather than guessed during the wizard.

Connections and Network Configuration

Depending on the model, port names and default assignments differ. For many hardware appliances, the first LAN access is possible via the standard address, while larger models may also have a dedicated management port.

Typical initial accesses:

• LAN port with https://172.16.16.16:4444: Initial setup through the local setup network.
• MGMT port with https://10.0.1.1:4444: Dedicated management access for models with an MGMT port.
• Serial console or local access: Emergency or reimage scenarios.

The client for the initial setup should be connected directly or via a controlled setup network. Old DHCP servers, incorrect VLANs, or a productive switch port with unexpected port configuration can unnecessarily complicate the initial setup.

Accessing the Web Interface

To configure, access the WebAdmin Console via a web browser. Depending on the interface, one of these addresses is used:

• LAN port: https://172.16.16.16:4444
• Management port: https://10.0.1.1:4444

On first access, the firewall uses a locally signed certificate. The browser warning is normal at this moment but should not be ignored later. For productive WebAdmin access, a suitable certificate should be planned, especially if multiple admins, Central Management, or a management FQDN are used.

As long as the default admin user with the default password is still used, additional restrictions apply. SSH from the WAN zone is not rejected normally; the firewall closes the connection silently. WebAdmin from the WAN zone shows a Forbidden message. SCP with the default credentials is not usable in the LAN or WAN zone. Treat this as an installation phase, not an operating model.

Run the Setup Wizard

The Setup Wizard configures the firewall at a basic level. In this phase, the goal is not the final security design, but to bring the firewall online, registered, and manageable in a controlled way.

Initial Setup with the Setup Wizard

The Setup Wizard queries basic data and brings the firewall to a start-ready state. These points should be consciously set:

1. Accept Sophos End User Terms of Use.
2. Start setup.
3. Set and securely store the admin password.
4. Set firewall name and time zone.
5. Enter serial number or existing license data.
6. Only allow automatic firmware updates during setup if internet access and maintenance window fit.
7. Create Secure Storage Master Key and document it in the password manager.
8. Perform registration and license synchronization or consciously postpone it.

The Secure Storage Master Key is important for protected data and restore scenarios. It should not be in a local text file on the admin notebook but in a controlled password or recovery procedure. If lost, it can be technically reset, but existing protected backups or data cannot be automatically decrypted.

Internet Connection and DNS Check

The wizard checks if the firewall reaches the internet. If the check fails, do not just enter “any DNS.” A clean delimitation is better:

• Does the WAN interface have a valid IP address?
• Is the default gateway correct?
• Is PPPoE, VLAN, or static routing needed?
• Can the firewall resolve DNS?
• Is outgoing HTTPS traffic blocked by an upstream device?
• Are date, time, and time zone correct?

For productive environments, DNS should not be randomly set to public resolvers if internal name resolution is needed. After initial setup, internal domains should be cleanly forwarded to internal DNS servers via DNS request routes on Sophos Firewall.

Registration of the Sophos Firewall

Registration connects the firewall with the Sophos license and Central context. It can be done directly in the wizard or later during operation. For productive firewalls, this step should not remain open unnecessarily long because license status, support, subscriptions, and Central functions depend on it.

Sophos supports several ways for registration. In partner or customer environments, OTP is particularly practical because not every admin needs to know the Sophos Central super admin credentials.

Typical procedure:

1. Have the firewall’s serial number ready.
2. Claim the firewall in Sophos Central or have an OTP generated by a Sophos Central Administrator.
3. Enter the OTP in the firewall.
4. Complete registration.
5. Then check under Administration > Licensing if the firewall is correctly registered.

Important: Sophos Central Firewall Management requires a paid subscription or a suitable support/bundle context. The base firewall license alone is not sufficient for all Central management functions.

Activation of Licenses

After registration, the firewall checks its licenses with the Sophos license server. If the firewall has internet access, license information is regularly synchronized. Additionally, synchronization can be manually triggered in the WebAdmin Console.

Under Administration > Licensing, check:

• Is the correct model registered with the correct serial number?
• Is the base license active?
• Are support, Xstream Protection, Standard Protection, or individual subscriptions correctly visible?
• Are expiration dates plausible?
• Has a new license key been truly applied or just stored in the portal?
• Does the firewall show the same status as Sophos Central after Synchronize?

Without a suitable license, many protection functions do not work or only work in a limited way. Depending on the function, this affects IPS, Web Protection, Zero-Day Protection, DNS Protection, Central Orchestration, Active Threat Response, or support services. The basics of support and modules are explained in Understand Sophos Firewall OS Base License and What Sophos Firewall Bundles Are Available?.

Connection to the Sophos Central Platform

For the local operation of a single Sophos Firewall, Sophos Central is not strictly necessary. The firewall can be fully operated via WebAdmin. However, Sophos Central offers advantages if these functions are consciously used:

• Central overview of one or more firewalls,
• Central Firewall Management without direct WebAdmin publication from the internet,
• Central backups,
• Central Firewall Reporting,
• Depending on the license, longer log retention and additional reporting functions,
• Security Heartbeat and Synchronized Application Control in Sophos endpoint environments,
• Integration into further Sophos Central processes.

The right expectation is important: Sophos Central does not replace local operational documentation and a clean admin process. Those who activate Central Management should consciously define roles, MFA, access, backup storage, and reporting retention.

More on this is in the article Connect Sophos Firewall with Sophos Central: Advantages and Limits.

Completion of Setup

After completing the setup, the firewall restarts or redirects to the login screen. After that, you should not start with productive traffic immediately but first check the basic state.

Directly after the first login, check:

• Date, time, and time zone.
• Firmware version and pattern updates.
• License status under Administration > Licensing.
• WAN status and internet access.
• Admin password and Secure Storage Master Key in the password manager.
• Backup configuration.
• Accessibility of the WebAdmin Console only from desired networks.
• Default rules, NAT, and DNS.
• Initial logs in the Log viewer.

Make the Firewall Production-Ready After the Setup Wizard

After the wizard, the real work begins: the firewall must be hardened, integrated into the network architecture, documented, and prepared for troubleshooting. These steps have a greater impact on later operation than the wizard itself.

Why the Setup Wizard Is Not Enough

The wizard creates an initial basic configuration but not a finished security architecture. Interfaces, zones, Device Access, DNS, DHCP, firewall rules, NAT, logs, backups, and protection profiles must be consciously checked.

A Sophos Firewall is not a consumer router where you are done after the wizard. Properly planned, it can secure a network very well, but only if the architecture is correct: Zones must match the security logic, management accesses must be restricted, rules should be consciously and documentedly created, and protection functions like web filter, IPS, Application Control, or TLS Inspection must be deliberately activated and tested. A misconfigured firewall can create a false sense of security.

First, it’s worth looking into the Control Center. There you can see system status, traffic, user and device information, active firewall rules, reports, and notices like new firmware or health check findings. Warnings and notices in this area should not just be clicked away but used as a practical checklist for follow-up work.

Check Firmware, License, and Backup

Under Backup & firmware, check if the active firmware is up to date. Firmware updates are security-relevant because they include bug fixes, stability improvements, and security fixes. Updates should not be postponed indefinitely but also not installed unprepared.

Sophos Firewall works with two firmware slots. This allows booting back to a previous firmware in case of problems. Nevertheless, a manual backup should be created before each major change. For productive firewalls, plan a maintenance window, check release notes, HA status, free space, VPN dependencies, and external accessibility.

Under Backup & firmware, a regular backup should also be set up. For encrypted backups, a backup password is needed. For restoring sensitive data, the Secure Storage Master Key is also relevant. This key absolutely belongs in a password manager. If lost, it can be reset via the console, but existing protected backups can no longer be normally restored.

Then check under Administration > Licensing if registration, base license, and booked subscriptions are correctly displayed. For the update topic, the articles Sophos Firewall Firmware Update: Preparation and Best Practices and Updating Firmware on Sophos Firewall are helpful. Backups are explained in more detail in the article Create or Restore Sophos Firewall Backup.

Plan Zones and Interfaces Cleanly

The wizard can combine multiple LAN ports into a bridge on hardware appliances. This is practical for a quick start but not always the best target architecture. Under Network > Interfaces, check which ports, VLANs, bridges, or LAGs are really needed.

Each interface is assigned to exactly one zone. This assignment later determines how firewall rules, Device Access, and protection profiles apply. Typical productive zones are, for example, LAN, Server, DMZ, Guest, VoIP, Management, or VPN. Not every VLAN necessarily needs its own zone, but each zone should have a clear security meaning.

More on this is in the article Plan and Configure Sophos Firewall Zones and Interfaces.

Secure Device Access

A common mistake after initial setup is too much management access. Accesses to local services of the firewall, such as WebAdmin, SSH, User Portal, VPN Portal, DNS, or Ping, are not controlled by normal firewall rules. Administration > Device access is responsible for this.

⚠️ WebAdmin, SSH, User Portal and VPN Portal should never be reachable just because the firewall rule base looks clean. These services depend on Device Access and Local Service ACLs. After every change, actively test from which zones and source networks access is really possible.

For productive systems, HTTPS and SSH should not be broadly allowed from insecure zones. If external access is necessary, work with a Local service ACL exception rule and limit access to fixed IP addresses or defined management networks. Alternatively, Sophos Central Firewall Management is often the cleaner solution.

More on this is in the article Secure Sophos Firewall Access: Properly Configure Device Access.

Set Admin Accounts, MFA, and Fallback

After the first login, do not work permanently with a shared admin access. For everyday use, own administrators, clear roles, and a documented emergency access are better. This way, it can later be traced who made a change, and a single compromised password does not automatically lead to full access to the firewall.

For new firewalls, this order is sensible:

1. Test at least one second administrative access before broadly activating MFA.
2. Treat the local default user admin as a break-glass account and do not use it as a daily user.
3. Plan to activate MFA for WebAdmin, VPN Portal, and Remote Access.
4. Document roles and responsibilities, especially if Sophos Central Firewall Management is used.
5. Define token reset, password storage, and access outside office hours.

MFA reduces the risk of stolen credentials but does not replace access restriction. Therefore, MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access and Device Access belong together. If multiple people work via Sophos Central, the Sophos Central Administrative Roles should also be checked.

Check DNS, DHCP, and Internal Name Resolution

Under Network > DNS, it is defined how the firewall receives DNS servers: via DHCP, through PPPoE information from the provider, or statically. For internal domains, DNS request routes should be used so that requests for internal zones go to the correct internal DNS server.

In new installations, DNS should be tested with real internal and external names. A test only with google.com is not enough if Active Directory, file servers, printers, management systems, or internal applications are used later. It is especially important whether clients receive the correct DNS servers and whether the firewall does not inadvertently forward internal domains to public resolvers.

Practical DNS check:

• Firewall resolves external names: Registration, licence synchronisation, updates and Central connection work.
• Client resolves external names: DHCP, DNS server and firewall rule match.
• Client resolves internal names: Internal DNS or DNS request route works.
• VPN or VLAN client resolves internal names: DNS server, search domain and zone rule also fit outside the first LAN.

DHCP is set up per interface under Network > DHCP. It is important to cleanly adapt DHCP ranges to the interface and VLAN structure. The DHCP server should not assign addresses that are already statically used for servers, switches, access points, printers, or management devices. Additionally, gateway, DNS server, domain name, and lease time should be consciously set so that clients do not just receive any IP address after the first connection but really work in the intended network.

If DHCP is to be forwarded over VPN routes, the firewall can also work as a DHCP relay. For DHCP special options, there is Configure Sophos Firewall DHCP Options.

Check Initial Firewall and NAT Rules

The default outbound rule created by the wizard should not be blindly adopted. Under Rules and policies > Firewall rules, check which source zones are allowed, which destinations should be reachable, and which security features are active. Rules are processed from top to bottom; the first matching rule wins.

For the start, at least one consciously named client-to-internet rule should exist. This rule should not simply allow Any to Any but clearly show source zone, source network, destinations, services, logging, and security features. If the rule is expanded later, it should remain traceable whether it is intended for normal clients, servers, guests, IoT, or management devices.

An initial rule check can look like this:

1. Connect a test client in the intended zone.
2. Check IP address, gateway, and DNS on the client.
3. Generate an external HTTPS call.
4. Search in the Log viewer for source IP, destination, service, and rule ID.
5. Check if the expected firewall rule and NAT rule were hit.
6. Conduct an intentionally not allowed test, for example, from a guest or management zone.
7. Document which rule remains productive and which wizard or test rule is removed.

For NAT: NAT does not allow traffic by itself. It always needs a matching firewall rule. For normal clients to the internet, a source NAT rule with MASQ is usually relevant. For published servers, DNAT plus a matching firewall rule, logging, and an external test from outside your own LAN are needed. For new configurations, standalone NAT rules are usually clearer than linked NAT rules. The basics are in Understand and Properly Configure Sophos Firewall Rules and Understand NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT. If an internal server is to be published, the article Publish Server via DNAT on Sophos Firewall fits.

Consciously Activate Protection Functions

A firewall rule is not automatically a complete protection rule. Depending on the license and target, IPS, Web Protection, Application Control, Malware Scanning, TLS Inspection, Zero-Day Protection, or Threat Feeds should be consciously activated, tested, and documented.

Practical order:

1. Create clean zones and rules.
2. Activate logging for important rules.
3. Activate IPS and Web Protection where they fit technically.
4. Add Application Control for risky or unwanted applications.
5. Introduce TLS Inspection only with a planned approach, test group, CA distribution, and exceptions.
6. Activate Threat Feeds, NDR, or Active Threat Response only when monitoring and false-positive processes are clarified.

For the broader hardening context, Sophos Firewall Best Practices: Network, Rules, and Security fits. For Zero-Day Protection, there is Understand and Operate Sophos Firewall Zero-Day Protection, for TLS Inspection Introduce Sophos Firewall TLS Inspection.

Prepare Logging and Troubleshooting

In important firewall rules, Log firewall traffic should be activated, otherwise, the information needed for troubleshooting is often missing later. Many are not aware of this: If a firewall rule does not log, the corresponding traffic does not appear meaningfully in the Log Viewer. You may see other system events, but not the specific rule decision you are actually looking for.

Under System services > Log settings, you can define which log types are sent locally, to Syslog servers, or to Sophos Central. The firewall has local log files and an internal reporting database, but these are not intended as a long-term archive for weeks, months, or years. If logs are to be retained permanently or searched centrally, either an external Syslog server or Sophos Central Firewall Reporting is needed.

For Sophos Central, roughly: With an active firewall subscription, Central Firewall Reports are available for a limited period. With Xstream Protection or Central Orchestration, longer evaluations are possible. With Sophos Central Firewall Reporting Advanced, you get additional storage and significantly longer retention. The details are described in Activate Central Firewall Reporting.

For initial analyses, Log viewer, Policy tester, and Packet capture are usually sufficient. For deeper analyses, you can additionally secure CLI logs, activate debug logs, or use tcpdump. Debug logs should only be turned on selectively and for a limited time because they generate significantly more data. How to test rules is shown in Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture. For Packet Capture, service names, and log files, there are the articles Use Packet Capture Tool in WebAdmin and Sophos Firewall Troubleshooting: Services and Logs. If logs are to be collected for support or external analysis, Secure Sophos Firewall Logs for External Analysis helps.

Acceptance Test Before Productive Traffic

Before going live, do not just check if “the internet works.” A small, documented acceptance test prevents many later support cases.

Sensible tests:

• Admin login from management network: WebAdmin is reachable but not open from unwanted zones.
• Admin login from client, guest or WAN zone: Access is blocked if no deliberate management network is planned there.
• Second admin or break-glass access: Access remains possible if MFA, SSO or a user account fails.
• Client from LAN to internet: Firewall rule, NAT, DNS and security policy work as expected.
• Internal DNS name: DNS request routes or internal resolvers work.
• Blocked test traffic: Log Viewer shows the matching rule or the expected drop.
• Backup download and storage: The backup is not only created but also findable.
• Central or Syslog target: Logs and reports arrive outside the firewall, if planned.

The test should be briefly documented: date, firmware version, location, tested source IP, destination, expected result, and open points. This seems unspectacular but saves time when a VPN, a NAT rule, or a DNS problem needs to be investigated days later.

Checklist After Initial Setup

Check Immediately

• Admin password and Secure Storage Master Key securely stored.
• Firewall registered and license status checked.
• Firmware version and pattern updates verified.
• Manual backup created and stored externally.
• WebAdmin and SSH accessible only from desired networks.
• Actively negative-tested WebAdmin and SSH from unwanted zones.
• Second admin access and break-glass concept tested.
• WAN, DNS, and time zone checked.
• Default firewall rule consciously evaluated.

Check in the First Days

• Zones, VLANs, bridges, and LAGs cleanly planned.
• DNS request routes and DHCP ranges checked.
• Firewall rules and NAT rules documented.
• Logging activated on important rules.
• Central backup or local backup process set up.
• Central reporting, Syslog, or other log target decided.
• First rules validated with Log Viewer, Policy Test, and Packet Capture.

Check Before Productive Operation or Go-live

• Management access hardened.
• MFA and admin roles checked.
• IPS, Web Protection, Application Control, and other protection functions consciously activated.
• TLS Inspection planned only with test and exception process.
• Remote Access, IPsec, WAF, RED, or SD-WAN separately tested, if used.
• Rollback and support path documented.

Common Mistakes

• Wizard configuration is used directly in production: Too broad rules, wrong zones or open management services remain. Work through a dedicated operations checklist after the wizard.
• Secure Storage Master Key not documented: Restore or migration becomes unnecessarily difficult. Store the SSMK in the password manager immediately.
• WebAdmin accessible from WAN or client networks: Bots, brute force and unnecessary attack surface become more likely. Device Access and Local Service ACL Exception Rules should be tight.
• MFA enabled without fallback: Admins can lock themselves out with token, time or group problems. Test second admin, break-glass access and token process beforehand.
• Logging forgotten in rules: Later troubleshooting becomes blind. Log firewall traffic should be active on important rules.
• DNS resolved only with public resolver: Internal names do not work reliably. Plan internal DNS servers and DNS request routes.
• NAT expected without matching firewall rule: Servers or services are not reachable despite NAT. Always check NAT and firewall rule together.
• Firmware update installed without backup: The way back is missing if problems occur. Check backup, release notes and maintenance window before updates.

FAQ