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.

Before each change, record the current settings or save a configuration backup. Include the WAN selection for VPN portal, every field and the order of existing Local Service ACL exceptions, the enabled state and three values of Block login, the ports and protocols of VPN Portal and SSL VPN, and the selected authentication servers in their current order. For provisioning or Entra SSO, also record vpn_portal_port, the portal URL, and the Redirect URI. For changed Threat Feeds, preserve the URL, indicator type, action, enabled state, and other custom options. Rollback must restore these values rather than assumed defaults.

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. Not every item appears as a standard column in every view; Detailed view and additional columns show the details available for that event. If context is missing, continue with the raw logs and Identity Provider logs. In a SIEM, filter the Syslog field log_component for VPN Portal Authentication and status for 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 Fusion (formerly Sophos Central). Then create the narrow exception first:

1. Under Administration > Device access > Local service ACL exception rule, click Add.
2. Rule 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.

After saving, first test the exception from an allowed external source. Using the verified secondary administrative path, clear the general WAN selection for VPN portal in the Device Access matrix and save the change. Device Access changes take effect immediately. Now run two tests: the allowed source must still reach the portal, while a disallowed external source must not. If the positive test fails, restore the previous WAN selection through the secondary administrative path. The Device Access guide covers additional cutover variants.

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.

The firewall’s configured web proxy is an important exception. SFOS treats its HTTP and HTTPS requests as internal traffic rather than traffic from a zone. Users with proxy access may therefore reach VPN Portal and other HTTP services on the firewall even when Device Access disables them for the users’ zone. If the web proxy is in use, perform the negative portal test once directly and once demonstrably through the explicit or transparent web proxy. Device Access cannot block this internal proxy path by zone; restrict proxy access itself if the result is unwanted.

Configure Login Security and ports correctly

Under Administration > Admin and user settings > Login security, enable Block login and fill in the three fields for failed-attempt count, time window, and block duration. Five failed attempts within 60 seconds followed by a five-minute block is only a configuration example; it is neither a universal Sophos default nor a production value to adopt without a pilot. Select production values based on user count, helpdesk procedures, and shared NAT sources. Run the block test from a controlled source IP while the secondary administrative path remains open.

The block operates per source IP and applies to all services after the threshold is reached; examples include WebAdmin, CLI, VPN Portal, and User Portal. Behind an office, hotel, or provider NAT, it can affect several legitimate users and an administrator at the same time. Never perform a negative test through the only available administrative path.

For a distributed attack, Block login is only one protection layer. Many bots can each remain below the threshold. Failed CAPTCHA entries are not counted as failed sign-ins and do not trigger the block.

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 requires. An unused local, AD, LDAP, or RADIUS path provides no benefit and permits unnecessary sign-in attempts against another user directory. At least one server must remain selected. VPN Portal does not support RADIUS with challenge-based MFA, so do not plan that flow as portal MFA.

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. .pro provisioning connects through vpn_portal_port. With Entra SSO, the URL used for VPN Portal and Remote Access and the registered Redirect URI must match the published gateway and port. Manually distributed .ovpn files may allow tighter publication, but profile changes still require controlled distribution and testing.

Add Threat Feeds for known sources

Sophos Firewall can also match known malicious source IP addresses in traffic to services on the firewall itself, including VPN Portal, WebAdmin, and VPN. According to the SFOS 22 help, this source-IP match applies to MDR, NDR Essentials, and Third-Party Threat Feeds, but not to Sophos X-Ops Threat Feeds. A maintained Third-Party Feed containing IPv4 addresses is therefore suitable as an additional layer for known brute-force sources.

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 locally in Log Viewer, enable Local reporting for Active threat response under System services > Log settings. XGS 87/87w and 107/107w do not support local reporting; use Sophos Fusion or a Syslog server as the log destination on these models.

Threat Feeds replace neither an ACL nor strong authentication. They match only listed addresses. Third-Party Feeds currently accept individual IPv4 addresses as IP indicators, but not IPv6 addresses, IP ranges, or network addresses; new or unlisted bot addresses remain reachable. Conversely, a False Positive can block legitimate users. Start a new feed in Monitor, check retrieval errors and unexpected matches, and only then move it to Block. A Threat Exclusion applies to all Active Threat Response modules, so keep it narrow, justified, and time-limited, and review matches and exceptions regularly.

For rollback, return a changed feed to its recorded previous action; disable a newly added feed rather than deleting it without review. Then verify that a previously false-positive source can reach the portal again and that the remaining protection layers still work.

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 at the configured log destination if this protection layer is used.
7. No new AD or Entra account lockouts or unknown successful logins occur during the defined observation period.

If a test fails, first restore only the most recent change to its documented previous value. This may involve the feed action, authentication server, Block login, port and Redirect URI, or Device Access configuration. For Device Access rollback, restore the old WAN selection through the secondary administrative path before removing the new ACL exception. A port rollback restores port and protocol, .pro, portal URL, and Redirect URI together. Then repeat the allowed and disallowed access tests.

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