Protect Sophos Firewall VPN Portal against brute force

Many failed logins to the Sophos Firewall VPN Portal initially show that the portal is accessible from the Internet and is being attacked automatically. They do not yet prove a successful breach. The situation becomes critical when real usernames are targeted, accounts in AD or Microsoft Entra ID are locked, or an unknown successful login appears among the failed attempts.

Use this order for containment:

1. Preserve the time window, users, source IPs, and authentication methods in the logs.
2. Check successful logins and identity events during the same period.
3. Restrict the VPN Portal to required sources or countries with a Local Service ACL.
4. Enable Block login and rule out port sharing between VPN Portal and SSL VPN.
5. Remove authentication methods that are not needed and check MFA or Entra protection.
6. Additionally block known malicious IPv4 sources with Threat Feeds and monitor the effect.

⚠️ Do not disable the VPN Portal without preparation. Sophos Connect Provisioning and Microsoft Entra ID SSO use the VPN Portal port. Before changing Device Access or ports, provide a tested secondary administrative path and a plan for client profiles, Redirect URIs, and rollback.

Confirm the attack in Log Viewer

In Log Viewer, open the authentication events and filter for:

• Log component: VPN Portal Authentication
• Status: Failed

For each match, the time, Source IP, Source country, Username, Authentication mechanism, and Reason are relevant. In a SIEM, use the Syslog field log_component with the value VPN Portal Authentication and status with the value Failed; the exact query syntax depends on the SIEM in use.

Then search for Successful for the same usernames and time window. An unknown successful login matters more than the sheer number of failed attempts and must be handled as a potential account incident.

Single source or distributed attack

The distribution determines which protection works:

• Many attempts from one IP address: Block login can temporarily block the source after the threshold is reached.
• Few attempts from many IP addresses: A distributed botnet may remain below the threshold for each source. ACLs, identity protection, and Threat Feeds then become more important.
• Many usernames from the same source: This matches Password Spraying or Credential Stuffing.
• Repeated attempts against the same real user: Check AD, Entra, or RADIUS logs for account lockouts and successful logins.
• Random, nonexistent names: This is often automated scanning, but it still creates load and log noise.

Manually blocking only the source IP rarely solves a distributed attack permanently. First reduce the exposed surface, then automatically add known bad sources.

Check raw logs selectively

If Log Viewer does not provide enough context, download the affected files under Diagnostics > Tools > Troubleshooting logs:

• vpnportal.log for portal access;
• access_server.log for user authentication and authorization;
• oauth_sso_vpn.log additionally for Microsoft Entra ID SSO.

By contrast, sslvpn.log belongs to the SSL VPN service and only becomes relevant when the failure occurs during tunnel establishment rather than portal login. Authentication logs can contain usernames, public IP addresses, and other sensitive request data. Therefore, limit excerpts by time and content, redact them before sharing, and do not copy them unchecked into public tickets. Sophos Firewall services and logs maps additional log files; Save Sophos Firewall logs describes a structured support archive.

Restrict VPN Portal to required sources

The VPN Portal is a local firewall service. Normal firewall or DNAT rules do not control this access; use Administration > Device access instead. The complete principles are described in Device Access and Local Service ACL.

Before making the change, open and actually test an independent access path through the console, management LAN, admin VPN, or Sophos Central. Then create the narrow exception first:

1. Under Administration > Device access > Local service ACL exception rule, click Add.
2. Name: for example vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4; if IPv6 is published, a separate IPv6 rule is also required.
5. Source zone: WAN.
6. Source networks and hosts: fixed partner networks, a maintained IP list, or a Country Group containing the countries actually required.
7. Destination host: the WAN interface or WAN IP configured on the Sophos Firewall where the traffic arrives. Behind an upstream NAT router, this does not mean that router’s public address.
8. Services: only VPN portal.
9. Action: Accept.
10. Save the rule.

In the target state, VPN Portal is not generally enabled for WAN in the Device Access matrix; it is reachable only through the required ACL exceptions. Device Access changes take effect immediately, so the safe cutover with a positive test, negative test, and rollback is deliberately covered in the detailed Device Access guide.

Then test the exception from one allowed and one disallowed external source. As long as broad WAN access remains enabled, a successful positive test alone does not prove that the exception restricts access as expected.

Country restrictions are useful when the user base has a clearly defined geographic scope. However, they are not identity controls: travelers, mobile networks, VPN providers, and incorrectly assigned IP geolocations can lock out legitimate users. Worldwide access therefore requires particularly strong identity protection, MFA, logging, and a review process.

Configure Login Security and ports correctly

Under Administration > Admin and user settings > Login security, enable Block login. The Sophos Firewall Health Check uses five failed logins within 60 seconds and a five-minute block duration as its baseline. The appropriate production value still depends on the number of users, the helpdesk process, and shared NAT sources.

The block operates per source IP and, after the threshold is reached, affects more than just VPN Portal. WebAdmin, CLI, VPN Portal, and User Portal will also stop opening from that source. An office, hotel, or provider NAT can therefore affect several legitimate users and an administrator at the same time. Never perform a negative test from the only available administrative path.

For a distributed attack, Block login is only one protection layer. Many bots can each remain below the threshold.

Rule out port sharing

Compare these two values:

• Administration > Admin and user settings > VPN portal HTTPS port, TCP 443 by default
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, 8443 by default with TCP or UDP

If VPN Portal and SSL VPN use the same port and the same protocol, the Login Security settings do not apply. VPN Portal also becomes reachable from the zones allowed for SSL VPN, even if it is disabled there in Device Access.

The combination must therefore be unique. Moving to a random port alone does not prevent an attack. If the VPN Portal port changes, update the portal URL, Entra Redirect URI, and the vpn_portal_port value for Sophos Connect Provisioning, then retest with a pilot user.

Protect authentication and affected accounts

Under Authentication > Services > VPN portal authentication methods, leave active only the servers that the current Remote Access design genuinely requires. An unused local, AD, LDAP, or RADIUS path provides no benefit but can expose additional credentials to checks against the public portal.

MFA does not prevent every failed attempt, but it reduces the risk that a known or guessed password alone is sufficient. MFA for VPN Portal and Remote Access explains the setup for local and directory users. With Microsoft Entra ID SSO, also check Entra MFA, Conditional Access, Sign-in Logs, and Risk Events.

A real user with suspicious failed attempts must be investigated beyond the firewall:

1. Check account lockouts and successful logins in the responsible Identity Provider.
2. Terminate unknown successful sessions according to the incident process.
3. Reset the password and registered MFA methods if compromise is suspected.
4. Check group membership and Remote Access authorization.
5. Only then use a documented pilot login to verify that legitimate access works again.

VPN Portal can be removed completely from WAN only if no required process depends on it. Entra SSO and .pro provisioning use the portal port. With manually distributed .ovpn files, a more restrictive publication process may be possible, but profile changes must then be distributed and tested in a controlled manner.

Add Threat Feeds for known sources

Sophos Firewall can also match known malicious source IP addresses for system-directed traffic to services such as VPN Portal, WebAdmin, and VPN. Maintained IPv4 feeds are suitable as an additional protection layer.

Configure Sophos Firewall Threat Feeds explains the full setup, licensing requirements, a Monitor pilot, Block operation, False Positives, and the Cybora feeds tested by Avanet. For a new feed, continue to verify retrieval and IoC content, observe its effect first, and only then enable controlled blocking.

For Active Threat Response matches to appear in Log Viewer, Local reporting must be enabled for Active threat response under System services > Log settings.

Threat Feeds do not replace an ACL or strong identity protection. They detect only indicators contained in the feeds, Third-Party Feeds currently support IPv4 for source-IP IoCs, and a new or unlisted bot IP remains reachable. Conversely, a False Positive can block a legitimate user, so a documented exception and review process is required.

Verify the effect and continue monitoring

Repeat the same defined test after every change:

1. An allowed external source can reach VPN Portal, and a pilot user can log in.
2. A disallowed source can no longer reach the portal.
3. VPN Portal and SSL VPN use a unique port-protocol combination.
4. A controlled failed attempt appears in Log Viewer with the expected source IP and authentication method.
5. Sophos Connect Provisioning, Entra SSO, and the actual VPN tunnel continue to work.
6. Threat Feed matches appear in the Active Threat Response log if this protection layer is used.
7. AD or Entra account lockouts and unknown successful logins do not occur.

For long-term detection, send authentication logs to a SIEM. Useful alerts consider not only the number of failures, but also many different sources targeting the same user, many usernames from one source, and successful logins after a sequence of failed attempts.

FAQ