It doesn’t happen very often, but occasionally one of my clients gets a flurry of AD account lockouts when some idiot tries to brute force their way in via the SSL VPN portal. MFA is enabled on the SSL VPN, but that obviously doesn’t stop the incorrect login attempts from locking their accounts (users are authenticated against AD via LDAPS and the AD has lockout policies). It’s a minor irritation as it doesn’t happen very often, but just wondering if anyone had experience similar problems and found a work around that wasn’t costly (they are small local charity).
The new firmware will let you hide the Web portal for the SSLVPN. Virtual office also exposes your domain name. I used to see attempts but hardly any after hiding it.
If you have a valid subscription make sure you enable the Geo IP filter and add the countries to the deny side. You can also do this rule specific to SSLVPN Connections
Lock down SSL VPN to only trusted hosts.
How do you do that for anyone not on a static IP?
Dynamic DNS clients. Allow those through with address objects. Everything else is denied.
STFU, get off my firewall.
We just started having this issue today. Did you fine any good way to negate this?
Can you elaborate more on this? Is it whitelisting only specific IPs?
I’m not a sysadmin
Thanks. That’s very helpful!
How do I do this rule specific to the SSLVPN?
that’s not feasible for mobile clients
This is the only useful way as far as I can tell…most domain registrars that handle DNS (GoDdaddy as an example) will provide you with api key access so you can run a simple PowerShell script on the clients to identify their current public IP, update their dynamic address and launch your SSL VPN client (necli.exe?). You can update the script to pull the api key from say Azure key vault after authenticating to keep the api key out of the script. Not sure if you can get the NetExtender cli to run a log off script to remove the dyn dns entry on exit though. Does anyone know?
In the end, we upgraded to the latest firmware release and disabled the virtual portal on the WAN interface as posted here - https://www.sonicwall.com/support/knowledge-base/how-to-disable-virtual-office-portal-access/210715065231700/. Too early to celebrate, but we’ve seen a dramatic decrease of active connections to port 443 from source IP addressed that are clearly servers hosted in cloud (rather than client endpoints). Time will tell. For us it wasn’t just account lockouts. It was flooding VPN services for legitimate users causing them to drop off. I have seen wider reports of Sonicwall clients suddenly seeing these issues, so perhaps a wider campaign? All rather irritating, but here’s hoping and good luck!
In settings under the SSL VPN, virtual office section. Disable the virtual office on WAN ports. You need to have a recent firmware version to do this.
In the firewall policy under the rules, find the rule for sslvpn traffic to the wan. There is a security tab for the rule settings, you can set the GEO ip options to use global or change it to be just rule specific. Make sure you toggle it on.
I’m doing this from memory so I may be a bit off on the process.
Where did OP specify mobile clients?
Did you need to reboot any of your hardware for this change to take effect? We upgraded the firmware, disabled the WAN Virtual Office, but we’re still able to access the Virtual Office externally. We are trying to avoid rebooting at this stage because we just had to do it to update the firmware.
How do you handle MFA registration after disabling the web portal?
Nope. We did not. The firewalls rebooted as part of the firmware update process. But after that initial reboot, it was a case of switching on the option to disable Virtual Office on the WAN interface and saving that change. After that, any attempt to access the portal from the WAN zone via a browser on SSL port 443, was blocked. I should add our virtual office was always accessible on port 443. We never change the service to a different port as I know some admins do when they config their units, so not sure if changing that would have any bearing on the effectiveness of the setting. I’m guessing not.
You can enable the portal on the LAN interface, set it all up from there. When you access with the Netextender client, log in with the user you setup and the password.
That makes sense. Thank you