Sophos XGS High CPU & Intermittent Latency Pinpointed to VPN Portal Attack

[Jaan]

 

Hey everyone,

 

I wanted to share a recent head-scratcher that might save some of you a lot of grief. I've been battling internet latency episodes—specifically, 20-30 second periods of high lag—and I've struggled to pinpoint the root cause.

 

Today, I finally caught an episode in the act. Coincidentally, I was logged into our Sophos XGS firewall making a minor Wi-Fi AP change when the problems started. I immediately noticed the Sophos's CPU load spiked to a very high level. My first thought was, "Changing an SSID shouldn't cause this! What is going on?"

 

Digging into the logs, I found the culprit: a dictionary attack actively hammering our VPN Portal (on the WAN interface).

Only two specific users should ever be accessing the VPN, yet I saw a flood of unfamiliar usernames in the authentication logs—an instant red flag.

 

While we use 2FA with a 30-second rotating password, the sheer volume of connection attempts was clearly overwhelming the firewall resources.

As soon as I removed the VPN Portal from being accessible (disabled it), the high CPU load vanished, and all network latency issues immediately stopped.

 

If you have a Sophos XGS or similar device with the VPN Portal enabled on the WAN, I strongly recommend you:

1.  Check your Authentication/System logs immediately for signs of a sustained dictionary attack.
2.  Consider restricting access to the VPN Portal to specific source IP addresses (if possible) or moving it behind a proxy/filter if you need to keep it WAN-facing.

Hopefully, this helps anyone else seeing similar mysterious latency issues!

 

Cheers, and happy weekend! 

[colly72]

We experience brute force attacks on our VPN portal, although we don't get latency issues.  We had MFA with rotating PIN code but we've recently moved to Entra ID MFA, which has the added benefit of all the conditional access policies that go along with it for extra protection.  The downside is that it requires exposing the VPN portal to the WAN.  If the brute force attacks are still a concern, it's possible to maintain a list of IP addresses using third party threat feeds and block traffic that way, although that's obviously a bit of a moving target as the IP addresses do change.  V22 is adding a more granular logging, so that it's possible to reduce noise from these types of brute force attacks.

[Davit2005]

Any DoS availability on the Sophos i.e. blocking IP addresses during sustained attacks, Sophos updated to recommended?

 

I frequently see random usernames on our FW for VPN including using admin, lol.

[Jaan]

The IPs came from around the world from at least 4 /16 ranges.... so that's a lot of IPs and countries. We've disabled the Webfacing VPN portal now. we had no need for it. Just reduced the attack footprint.

[colly72]

4 minutes ago, Jaan said:

The IPs came from around the world from at least 4 /16 ranges.... so that's a lot of IPs and countries. We've disabled the Webfacing VPN portal now. we had no need for it. Just reduced the attack footprint.

That's definitely the way to go if you don't need it, or Entra authentication.  For me, the benefits of Entra MFA to our staff and students (which include captive portal SSO), make it worthwhile and I'm looking to reduce the noise when v22 goes GA.

[Davit2005]

59 minutes ago, Jaan said:

The IPs came from around the world from at least 4 /16 ranges.... so that's a lot of IPs and countries. We've disabled the Webfacing VPN portal now. we had no need for it. Just reduced the attack footprint.

Our firewall blocks DoS automatically on specific parameters but we can exclude IPs if we want i.e. for known vulnerability scanning.

[drutt]

I think we had the VPN portal enabled via WAN when we first setup the firewall, but then during a firmware update they added recommended setting warnings to some parts of the GUI and one of those was to disable the VPN portal via WAN.

 

We have basically nobody use our VPN any more since migrating our MIS/FMS to Bromcom and pushing staff to store documents in OneDrive, eventually I want to disable it completely. 

Edited November 24, 2025 by drutt

[mavhc]

Can you ban any single ip that fails to authenticate automatically for 10 mins?

[colly72]

16 minutes ago, mavhc said:

Can you ban any single ip that fails to authenticate automatically for 10 mins?

I don't think that's possible.  AFAIK the only way to mitigate it if you expose the VPN portal to the WAN, is by using third party feeds, which either monitor or block the traffic. Or, just implement MFA in some form (we use Entra ID which you can restrict further with Conditional Access) and then monitor the logs.

[tdk1069]

We had so many I even made a GrayLog dashboard to keep an eye on it. We have migrated everyone off it now so logs are nice and quiet now.

 

~200,000 attempts a week.

 

[Davit2005]

55 minutes ago, colly72 said:

I don't think that's possible.  AFAIK the only way to mitigate it if you expose the VPN portal to the WAN, is by using third party feeds, which either monitor or block the traffic. Or, just implement MFA in some form (we use Entra ID which you can restrict further with Conditional Access) and then monitor the logs.

Not sure how that helps as the client surely has to access the portal/VPN first so the MFA can kick in???? Unless you hide it behind a proxy of some sort which deals with the initial request, i.e. Cloudflare.

[colly72]

Actually, I think it might be possible to block login after a set number of failed attempts for a period of time, in Administration -> Admin and User Settings:

 

 

I've not tested this.......

[colly72]

4 minutes ago, Davit2005 said:

Not sure how that helps as the client surely has to access the portal/VPN first so the MFA can kick in???? Unless you hide it behind a proxy of some sort which deals with the initial request, i.e. Cloudflare.

It doesn't stop the portal being exposed but it provides all the usual Entra MFA/Conditional Access protections (which most of us rely on for dozens of other apps and services).

[Jaan]

20 minutes ago, colly72 said:

Actually, I think it might be possible to block login after a set number of failed attempts for a period of time, in Administration -> Admin and User Settings:

 

 

I've not tested this.......

 

we already have this set 

 

In our case it's just easier to reduce the attack footprint. we don't need it there accepting any responses.

[colly72]

2 minutes ago, Jaan said:

 

we already have this set 

 

In our case it's just easier to reduce the attack footprint. we don't need it there accepting any responses.

I totally agree, it's the best way to mitigate the risk if you don't need it.