Secure Sophos Firewall Access with Device Access

Under Administration > Device access, you define from which zones local services of the Sophos Firewall are accessible. These include HTTPS for the WebAdmin Console, SSH for the CLI, Ping, DNS, User Portal, VPN Portal, and other services.

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

This area is security-critical. Normal firewall rules control traffic through the firewall. Device access controls traffic to the firewall itself. If WebAdmin or SSH is accessible from an insecure zone, it creates direct management access to the security device.

The API is also important: the Device Access permission for HTTPS/WebAdmin also affects API access. Since SFOS 22, API access sources are additionally maintained under Administration > API access, but an allowed API host does not help if Device Access blocks local HTTPS access from that zone.

⚠️ WebAdmin, SSH, and portals should only be accessible from trusted networks. For production environments, it is better to restrict access to a management network, a fixed admin IP, VPN, or Sophos Central Firewall Management.

For everyday operations, this distinction helps:

• Device Access zone table: Allow or block a service generally per zone, for example DNS for LAN, Ping for a monitoring zone, or SSL VPN for a required Remote Access zone.
• Local Service ACL Exception Rule: Control access more tightly by source, destination, and service, for example WebAdmin only from the management network, SSH only from a support IP, or SNMP only from the monitoring system.
• Normal firewall rule: Allow or block traffic through the firewall, for example when a client from LAN accesses a server in DMZ or an internet service.

This makes it clear: a firewall rule does not replace Device Access hardening. If HTTPS or SSH is reachable too broadly through Device Access, a client reaches the firewall’s local service before a classic transit rule would even be the right inspection point.

Why Device Access Doesn’t Work Like a Firewall Rule

A typical firewall rule allows or blocks connections between zones, for example, LAN to WAN or VPN to Server. Device Access is different: it concerns services running directly on the Sophos Firewall.

Examples:

• An admin opens https://172.16.16.16:4444.
• A client uses the firewall as a DNS server.
• A monitoring system pings the firewall.
• A user opens the User Portal or VPN Portal.
• An admin connects to the firewall via SSH.

Such traffic targets not a server behind the firewall but the firewall itself. Therefore, it is controlled via the local Service ACL.

This is also why Device Access is part of the basic hardening of every Sophos Firewall. A clean rule set for LAN-to-WAN does not automatically protect the management and portal services of the firewall itself. These services must be checked separately and consciously restricted.

Understanding Zone Permissions

In the upper section of Administration > Device access, you see a table with zones and services. If a service is enabled for a zone, access to this local service is generally allowed from that zone.

The zone table is practical but coarse and suitable for clear internal zones, such as LAN, Management, or VPN. When a service should only be accessible for individual admin IP addresses, locations, countries, or support targets, Local service ACL exception rules are the better choice.

For Custom Zones, the zone settings should also be checked. Local services can be influenced there as well. Even so, Administration > Device access remains the central place for deliberately allowing or restricting local firewall services.

Typical examples:

• HTTPS: WebAdmin access from the management network. Do not allow broadly from WAN.
• SSH: CLI access for admins or support. Allow only selectively, preferably with a public key.
• Ping/Ping6: Monitoring and simple reachability tests. Do not activate unnecessarily from insecure zones.
• DNS: Clients use the firewall as a DNS resolver. Activate only for internal client zones.
• SSL VPN: SSL VPN users establish a connection to the firewall. Open externally only as far as needed and secure with MFA; check the port separately in the Remote Access area.
• User Portal: Users download VPN configurations or tokens. Preferably access externally via VPN/ZTNA or with tight restrictions.
• VPN Portal: Remote Access VPN users. Only if really needed and secure with MFA.
• RED: RED appliances connect to the firewall. Allow only for real RED locations or defined sources.
• SMTP Relay: Internal systems use the firewall as an SMTP relay. Do not allow as an open relay from insecure zones.
• SNMP: Monitoring queries firewall values. Allow only from the monitoring system; details are available in SNMP Hardware Monitoring.
• Dynamic Routing: Routing protocols between routers and firewall. Activate only in designated network segments.

In SFOS 22, WebAdmin, VPN Portal, and User Portal support TLS 1.3. This is good for encryption, but it does not change the basic principle: a service that is reachable from too many sources remains an unnecessary attack surface. Transport encryption does not replace a clean ACL.

Which Services Can Be Restricted by ACL Rules?

Local Service ACL and ACL Exception Rules allow very fine control over local firewall services. These services are particularly relevant:

• DNS: The firewall answers DNS queries from networks it should not serve.
• Dynamic Routing: Routing protocols are accessible from incorrect segments.
• HTTPS: The WebAdmin Console is accessible from too many sources.
• Ping/Ping6: The firewall is unnecessarily visible and scannable.
• RED: RED services are accessible from too broad source ranges.
• SMTP Relay: Misconfigurations can facilitate relay abuse.
• SNMP: Monitoring data can be queried from incorrect networks.
• SSH: Direct CLI access to the firewall is too open.
• SSL VPN: VPN login points are globally accessible and scanned.
• User Portal: Portal login and VPN downloads are unnecessarily exposed.
• VPN Portal: Remote Access portal is a target for bots and brute-force attempts.

The more these services are accessible from WAN, guest networks, IoT networks, or vaguely defined zones, the larger the attack surface becomes. The goal is not to deactivate everything but to make each service accessible only where it is truly needed.

Define Access Sources as Narrowly as Possible

An ACL Rule does not have to simply allow Any. As a source, you can work very finely, for example, with:

• individual admin IP addresses
• management networks
• IP ranges
• IP lists
• FQDN hosts
• FQDN host groups
• DNS hosts or DNS groups
• country objects or country groups
• dedicated VPN or support networks

This allows access to be significantly better limited. An example: If an external support service comes only from a fixed FQDN or a defined IP range, the entire WAN zone should not have access to HTTPS or SSH. If a monitoring system requires SNMP, a complete server network should not be allowed to query SNMP on the firewall.

In global remote access scenarios, the demarcation is more difficult. Some companies cannot simply allow SSL VPN or VPN Portal only for Switzerland, Germany, or a single country because employees are travelling worldwide. In such cases, additional measures such as MFA, logging, restrictive portal settings, and threat feeds should be used.

Decision Model for Local Services

For each local service, a conscious decision should be made about the appropriate level of access. It is rarely sensible to treat WebAdmin, SSH, User Portal, VPN Portal, DNS, and SNMP the same.

• Disabled: Appropriate when the service is not needed in the environment. Example: SSH permanently off if no CLI access is intended.
• Internal zone only: Appropriate when the service is needed by many internal clients. Example: DNS from LAN if clients use the firewall as a DNS resolver.
• Management network: Appropriate for administrative or monitoring-related services. Example: HTTPS, SSH, and SNMP only from Management.
• Admin VPN: Appropriate when admins should work externally but not directly from the internet. Example: WebAdmin only accessible via VPN.
• ACL Exception Rule: Appropriate when access should come from a very specific source. Example: a support IP may temporarily access HTTPS or SSH.
• Broadly accessible from WAN: Only for genuine Remote Access services and with additional protection. Example: SSL VPN for mobile users with MFA, logging, and Threat Feeds.

This decision should be documented. Especially for exceptions from WAN, it must later be traceable why the service is accessible, who needs it, and when the exception will be reviewed again.

WAN Access is an Exception

WAN is not just another zone. Anything accessible from WAN is found by scanners, bots, and brute-force tools. Therefore, WebAdmin from WAN should not be planned as a normal operational variant.

If external management access is needed, these variants are usually safer:

• Sophos Central Firewall Management for administrative tasks.
• Admin VPN with MFA and a clear user group.
• A temporary ACL Exception Rule for a fixed source IP.
• A dedicated management network via site-to-site VPN.

For the overall hardening picture, Sophos Firewall Health Check is additionally suitable, as it evaluates management access, MFA, backups, and rule hygiene together.

Sophos additionally protects WebAdmin from being allowed for all WAN sources. If WAN access is really necessary, it must be limited to specific sources such as individual IPs, networks, or FQDN objects. Existing legacy permissions from older configurations should be reviewed regularly: Sophos can automatically deactivate certain broad WAN permissions for WebAdmin or User Portal after longer inactivity, while targeted ACL exceptions for specific WAN sources can continue to apply.

Local Service ACL Exception Rule

If a service should not be allowed for an entire zone, a Local service ACL exception rule is used. This allows you to define very precisely who can access which local service.

Path:

1. Open Administration.
2. Select Device access.
3. Scroll to Local service ACL exception rule.
4. Click Add.

Typical procedure for a narrow admin exception from the WAN:

1. Set Rule name, for example admin-https-from-support-ip.
2. Set Rule position to Top if an existing drop or allow rule might otherwise match first.
3. Select the IP version matching the source, usually IPv4.
4. Set Source zone to WAN.
5. Set Source Network / Host to the concrete admin IP, a small admin network, or a maintained FQDN/IP object.
6. Limit Destination host to the affected firewall address or interface unless all local destinations are deliberately intended.
7. Set Services to the required local service, for example HTTPS for WebAdmin or API, not both HTTPS and SSH for convenience.
8. Set Action to Accept.
9. Save and immediately test from an allowed and a disallowed source.

An ACL Exception Rule essentially consists of these fields:

• Rule name: Unique name, for example, admin-https-from-mgmt.
• Rule position: Order of the ACL rules.
• Source zone: Zone from which access comes, for example, WAN, LAN, or VPN.
• Source Network / Host: Allowed admin IP, management network, FQDN host, or IP list.
• Destination host: Firewall IP or interface being accessed.
• Services: Local service, for example, HTTPS, SSH, Ping, or DNS.
• Action: Accept or Drop.

For WebAdmin access from the internet, you should never use Any as the source. Sophos deliberately prevents WebAdmin access from the WAN zone for all sources because this would be a high risk. If WAN access is really necessary, it should only be allowed via specific source IP addresses, defined networks, FQDN objects, or other narrow sources.

The same logic applies to API automation. A host can be allowed under Administration > API access and still fail if HTTPS access is missing under Device Access. Conversely, HTTPS access should not become broader only because an API tool is connected. For API details, see limit Sophos Firewall API access securely.

The order is also important. ACL Exception Rules are evaluated from top to bottom. A higher Drop rule can render a later Accept rule ineffective. Conversely, a too broadly formulated Accept rule can undermine later planned restrictions. Therefore, the rule order should be checked as consciously as with firewall rules.

The Destination host is especially important if the firewall has multiple interfaces, alias addresses, VPN addresses, or separate portal/admin targets. A rule should point as precisely as possible to the firewall address that will actually be administered or used. Otherwise, a source permission that looks narrow can suddenly apply to more local services or interfaces than planned.

Avoid Lockout Before Making Changes

Device access changes directly affect management and portal access. Therefore, before any restriction, it should be clear how to regain access to the firewall if a rule is incorrectly applied.

Before saving a risky change, check:

• Is a second admin with the appropriate rights profile available?
• Is there access via another network, such as management LAN, admin VPN, or Sophos Central?
• Is local console or out-of-band accessibility available if WebAdmin is no longer reachable?
• Is work being done on an HA cluster where a role change can alter the access path?
• Are current backup files, Secure Storage Master Key, and emergency access documented?
• Is there a short maintenance window where access issues can be immediately noticed?

Especially at remote locations, you should not first remove broad access and then test. It is safer to follow the reverse process: create a new narrow ACL Exception Rule, test allowed access, confirm a second admin path, and only then reduce the old broad zone access.

Safely Rolling Out Changes

Device access changes can lock out admins. Therefore, they should not be changed casually but treated like a management change.

Proven procedure:

1. Document current access: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP, and Ping.
2. Ensure a second admin path is available, such as local console, admin VPN, or Sophos Central.
3. Create a backup before implementing major ACL changes.
4. Create a new ACL Exception Rule as specifically as possible.
5. Test access from the allowed source.
6. Test access from a disallowed source.
7. Check Log Viewer to see if the expected events are visible.
8. Only remove the old broad zone access once the new access is confirmed.
9. Document the change with date, source, service, and responsible person.

If multiple firewalls or HA clusters are affected, the change should first be tested on a system with good fallback options. For HA environments, Setting Up Sophos Firewall High Availability is additionally suitable, as management access, role changes, and maintenance windows must be considered together.

Post-Change Review of Device Access Changes

After an adjustment, it is not enough to only check your own WebAdmin access. Both allowed and disallowed sources should be tested, otherwise, it remains unclear whether the hardening is really effective.

• WebAdmin from management network: Access works as planned.
• WebAdmin from normal client network: Access is blocked unless explicitly allowed.
• SSH from admin network: Access works only if SSH is deliberately allowed.
• SSH from WAN or guest network: Access is blocked.
• DNS from client network: DNS works only in networks that should use the firewall as a resolver.
• User Portal or VPN Portal: Only needed portals are accessible.
• SNMP from monitoring system: Monitoring works, other sources are blocked.

If access unexpectedly works, not only the ACL Exception Rule should be checked. The zone table in the upper Device Access area, custom zone settings, VPN zone, proxy behaviour, and existing broad Accept rules can also be the cause.

For documentation, a short list per service is often enough:

• HTTPS: allowed source mgmt-net, reason Admin access WebAdmin, review quarterly.
• SSH: allowed source support-ip-temporary, reason Support case, review after ticket closure.
• SNMP: allowed source monitoring-server, reason Hardware and interface monitoring, review semi-annually.
• SSL VPN: allowed source WAN, reason Remote Access, review with monthly log checks.

During every follow-up review, also check whether successful and blocked access attempts are actually visible. For short tests, the Log viewer is often enough. For longer retention or audit questions, Central Reporting or Syslog are better suited because local logs can rotate or be lost during incidents.

Recommended Basic Configuration

For many production environments, the following logic is sensible:

• HTTPS/WebAdmin only allow from Management, admin VPN, or a fixed admin IP.
• API only allow from defined automation or monitoring hosts and additionally limit HTTPS through Device Access appropriately.
• SSH generally deactivate and only allow selectively via ACL when needed.
• DNS activate only in zones where clients actually use the firewall as a DNS server.
• Ping allow for internal monitoring systems, but not broadly from WAN.
• User Portal, VPN Portal, and SSL VPN only activate if they are needed.
• RED allow only for locations or source areas where RED appliances are actually located.
• SNMP allow only for the monitoring system.
• SMTP Relay allow only for defined internal systems.
• Dynamic Routing activate only in routing segments where dynamic routing protocols are actually used.
• MFA for WebAdmin, VPN Portal, and Remote Access; setup is in Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access.
• Use Sophos Central Firewall Management if secure external management access is needed.

For longer traceability, the logging strategy should also be checked. Local logs are sufficient for acute troubleshooting but not for every audit or incident response question. If portal or management access needs to be traceable long-term, Central Firewall Reporting or Send Sophos Firewall Syslog to SIEM are more suitable components.

Handle SSH with Particular Caution

SSH is very useful for troubleshooting and support but should not be permanently broadly open. For SSH, the following applies:

• Only the admin user can log in via SSH.
• Public key authentication is the preferred method.
• Access from WAN should only occur via fixed source IP addresses or VPN.
• After completing an analysis, check whether SSH is still needed.

More on this can be found in the guide Connect to Sophos Firewall via SSH.

Bots, Brute Force, and Threat Feeds

In practice, it is very common for overly open services to be immediately found by bots. WebAdmin, User Portal, VPN Portal, and SSL VPN are particularly affected. Even if a service is protected by password and MFA, public logins generate attack attempts, brute-force traffic, log noise, and unnecessary load on the firewall.

This does not automatically mean that a successful attack is taking place. However, it shows that the service is part of the public attack surface. The fewer sources that can reach the login, the better.

If a portal must be accessible worldwide, country filters or individual source IP addresses are often not enough. In such environments, we additionally recommend Third-Party Threat Feeds. Threat feeds continuously provide the firewall with current indicators of compromise, such as malicious IP addresses, domains, or URLs. Known scanners, botnets, and attackers can thus be blocked before they reach WebAdmin, VPN Portal, SSL VPN, or other published services.

The article Sophos Firewall Threat Feeds explains planning, allowlisting, and operation.

Common Mistakes

Checked Firewall Rule Instead of Device Access

If WebAdmin, SSH, DNS, or Ping to the firewall is not reachable, a normal firewall rule does not help. The traffic does not pass through the firewall but ends on the firewall itself. Therefore, Administration > Device access must be checked.

WebAdmin Allowed from Too Many Zones

WebAdmin should not be accessible from every internal zone. A guest network, IoT network, or VoIP network usually does not need access to firewall management. Even internally, it should be assumed that compromised clients can exist. A separate management network or an admin VPN significantly reduces this risk.

DNS Not Activated for Client Zone

If clients are supposed to use the firewall as a DNS server, DNS must be allowed for the appropriate zone. Otherwise, clients reach the firewall IP but do not receive a DNS response. Conversely, DNS should not be allowed from zones where the firewall is not intended to be used as a DNS resolver.

Confused User Portal and VPN Portal

The User Portal and the VPN Portal are different services. Depending on the remote access concept, it must be checked which portal is really needed. Often a portal is activated because a user needed to download a configuration once, but it remains open for years afterward. Such legacy issues should be regularly removed.

If portals must remain accessible from the internet, the checkbox is not the only thing to check. MFA, user groups, the token/provisioning process, expiry of temporary users, logging, and whether the portal is still permanently needed after rollout are all important.

Overlooked Web Proxy Special Case

When the Web Proxy is used, HTTP and HTTPS requests can appear internal from the proxy’s perspective. This can affect how access to WebAdmin, Captive Portal, VPN Portal, or User Portal is controlled. In environments with a proxy, it is therefore particularly important to test which accesses are really possible.

ACL Rule Too Broadly Formulated

An ACL Exception Rule with Source zone: Any, Source Network / Host: Any, and Services: HTTPS, SSH is almost never a good idea. Such rules bypass the actual security gain of the ACL exception. A better approach is a small, clear rule with a distinct source and exactly the needed services.

Drop Rule in the Wrong Position

If a drop rule is above an accept rule, the allowed access can still be blocked. With ACL Exception Rules, the order is just as important as with firewall rules.

Conversely, a broad accept rule at the top of the list can make later drop rules practically worthless. After every rule change, check not only the new rule but also the match logic of the rules above it.

SSL VPN and VPN Portal Left Too Open

Remote access often needs to be accessible from outside. Nevertheless, it should be checked whether all countries, networks, and user groups really need access. If a narrow source limitation is not possible, MFA, logging, and threat feeds should be used all the more consistently.

Troubleshooting

If a local service is not reachable, this sequence helps:

1. Is the target IP of the firewall correct?
2. Does the client come from the expected zone?
3. Is the service allowed in Administration > Device access for this zone?
4. Is there a suitable Local service ACL exception rule?
5. Does a higher ACL rule with Drop apply?
6. Is the service configured on a different port?
7. Is access seen differently via VPN, proxy, or NAT than expected?
8. Does the Log Viewer show a hint?
9. Can Packet Capture see the connection attempt on the interface?

For support access, it may be useful to create a targeted ACL Exception Rule and remove or deactivate it after completion.

Operational Checklist

• WebAdmin not broadly accessible from WAN.
• SSH only temporarily or allowed from management/admin networks.
• DNS only active for client zones that actually use the firewall as a resolver.
• SNMP only allowed from the monitoring system or monitoring network.
• User Portal, VPN Portal, and SSL VPN only active if needed in the remote access concept.
• MFA checked for WebAdmin, VPN Portal, and Remote Access.
• ACL Exception Rules named with clear source, service, and purpose.
• Temporary support rules documented with expiration date.
• Access tested from allowed and disallowed sources.
• Logging, Central Reporting, or Syslog checked for relevant portal and management access.
• Quarterly review planned for WebAdmin, SSH, SNMP, User Portal, VPN Portal, and SSL VPN.

FAQ