Disabling VPN portal breaks SSLVPN connections

Hi Stuart James ,

Please follow the recommended best practices 

Create ACL to Block IP/Country in Device Access by Creating ACL based on country

Enable Sign-in security settings

We are getting DDOS-like authentication-requests through the VPN portal.

Since some firewalls reported repeatedly failed authentications from an IP in St. Petersburg yesterday we disabled the VPN portal global for WAN, giving it local access with an ACL exception from country "Germany".

Today I wasn't even able to login to the firewall via VPN. Authentication log is completely flooded with failed authentications. After several tries I could login to WebAdmin from internal via Citrix Netscaler an restart the authentication service on the firewall. Then I was able to login via VPN (PRO file) again.

Source IP for the failed authentications is 127.0.0.1. I will go and disable the vpn portals completely now... fortunately our customers use OVPN only.

Do you use x-Ops / ATP and block traffic? 
Do you already use a blackhole NAT Rule for this? 

Because right now: DNAT / Firewall rule will deny those traffic regardless of the destination port / setup. 

No, these customers do not use MDR.

Creating a blackhole NAT rule for every single IP attempting to hack the firewall is not feasible.

I am explicitly ask for ATP / xOps, not MDR. 

Right now, the attempts above seems to only apply to two IPs. 

Yep, XOps on and set to drop

We have checked, one firewall with active ATP and MDR there are no events in ATP log and we see auth. failure entrys matching that issue. We are currently creating ACL rules via Sophos Central Partner rule over all customers.

Essentially, this situation going forward will be addressed by V21.0, you can use third party feeds to add more information to your firewall. 
This topic is not something new: Bot networks attempts such campaigns all the time. 

In this concret example, you can manually blackhole this traffic to another host. You can use Device Access Rules to block regions. 

And in the future, with SFOSv21.0 you can import external feeds as well. 

The best fix would be to allow us to close the VPN Portal full stop. Shouldn't need it open for any reason.

For PRO policy checkin use another port, or use the SSLVPN connect itself.

You can close the VPN Portal. You can still download the Policy by downloading it via VPN Portal (internally) and publish it to the Client.

Provisioning over the VPN Portal is given over the port, you want. Can be shared with the SSLVPN Portal or not. 

As stated above, you can still close the VPN Portal after publishing the pro file by using the specific flag. 

Your statement is more about the Sophos Connect component and not the Firewall, as the firewall cannot control this. 

That means contacting more than 2000 end users and redeploying the VPN profile with the specific flag. Sure, it can be done, but that is a gigantic task that will take months.

Yep, it's probably a change that needs to be made to Sophos Connect rather than the firewall, but Sophos is Sophos.

I am still try to think about a way to approach this. 

As stated above: SFOSv21.0 will include more telemetry from other sources, which can help to prevent this in the future.

This is not a new discussion, instead its there for years. 

The VPN Portal is adapted by many customers like the user portal was and this kind of campaign targeting portals like the VPN Portal are not new. 

The portals are build to be robust. 

I am still try to think about a way to approach this. 

As stated above: SFOSv21.0 will include more telemetry from other sources, which can help to prevent this in the future.

This is not a new discussion, instead its there for years. 

The VPN Portal is adapted by many customers like the user portal was and this kind of campaign targeting portals like the VPN Portal are not new. 

The portals are build to be robust.