We have a ticket opened with WatchGuard because we’re having issues connecting to VPN using SSLVPN with AuthPoint. While on the phone with support he said, “Uh-oh…looks like it’s our issue. I just got an email from engineering saying they are looking into ongoing issues in the US.”
Their status page showed issues started yesterday. Anyone hear anything to help?
EDIT: As of 15 minutes ago my users can now connect.
I dealt this this throughout the day today… specifically AuthPoint pushes for SSL VPN users. Sort of erratic behavior. Seemed resolved early AM Monday, but then continued to have issues through the business day today. Had a ticket open and worked with a WG tech. Appears to be OK as of around 3PM or so; finger crossed. Not clear whether anything we did on our end had any impact.
EDIT; Be aware of a very misleading UI at the status.watchguard.com page, which shows big green checkmarks everywhere, indicating everything is 100% good. But if you click INTO the Americas region, you will see all the updates on this alert topic. Poor design. Would have saved me a lot of confusion had I seen this right away.
Word on the street is they’ve been consistently under a RADIUS DDOS attack for the last few months. And intermittently prior to that. The severity of which comes and goes. And makes it very difficult for them to allocate the proper amount of cloud side resources to combat it.
That’s likely at least part of the problem here.
That word lines up with what I saw. I left a comment on another thread that Sunday one of my small sites started seeing 100’s of K of OpenVPN/SSLVPN brute force attempts from RU/DE/CN/IN/etc ip’s. I was able to block 95% of them via geolocation policies, but every request is a forward to Authpoint Cloud, even when the username is not a valid one.
I noticed that the .4 firmware has a “Fail2Ban” feature added that helps with blocking these when the IP’s are in the same regional area or if your org is too spread across the globe for geolocation policies to help.
So here is my question. How are the attackers able to brute force these SSL VPNs unless the root CA for Watchguard has been compromised? In order to establish a connection to the VPN you must present the server with a private key. At that point you can try a username/password. In my mind this must mean WatchGuard’s Certificate Authority has been compromised. Am I wrong?
The issue is occurring before the VPN establishes. It’s the initial authentication so there’s not a certificate issue at all. BS usernames and credentials are being used. It never proceeds to the certificate checking phase or establishing the VPN. And a service degradation on the cloud side is occurring from all the BS auth attempts.