SonicOS 7.1.1-7051, SSL-VPN users taking up multiple licenses on signin

VPN
1

I have a TZ670 on the latest firmware (Which seems to have solved the CPU issue of the earlier 7.1.1 release), but something still isn’t right.

We have a total of 35 licenses for SSLVPN, but folks are reporting they they are getting error messaging trying to connect due to maximum license count being reached. When I look at the list of logged in SSLVPN users, I see 15 users logged in successfully, but then 10 listings for the same remote IP with the status “login pending”, and a further 12 listings for a different remote IP with that same status. So for some reason, users are taking up multiple licenses getting stuck somehow trying to connect. When you add that all up, 15+10+12 = 37, which is over 35, so the next person trying to log in gets the “maximum licenses reached” rejection.

Once you let some time pass, those “login pending” folks actually complete the login and the multiple “pending” listings go away, but in the interim, I’m getting continual reports of login failures.

What’s going on here, and how do I even troubleshoot this? Is there some setting somewhere to restrict the number of licenses that can be taken by a single remote IP? We shouldn’t have to buy 50 licenses to guarantee 25 people can login.

​

Update - Hotfix supplied by support appears to have NOT solved this issue.

Hotfix Filename is: sw_tz_670.7.1.1.7051-R3176-HF46826.bin.sig dated 3/23/24.

Note this is different than the latest maintenance release shown in MySonicwall, which is:

sw_tz_670_eng.7.1.1.7051-R5653.bin.sig which is dated 3/12/24.

I’m still seeing occasional multiple licenses taken by bad actors, and when I input those IPs into the Diagnostics page of the GEO-IP filter, it shows they are all in the US, so I’m adding them to the blocked list, but this is not a scalable solution.

I have gotten back to Sonicwall with these results, but not heard back yet regarding next steps.

​

​

2

I know this isn’t the correct answer but maybe helpful as a workaround until it gets corrected. https://www.sonicwall.com/support/knowledge-base/how-to-control-multiple-logins-from-same-user-on-sonicwall/220727072820143/

3

We were hit with this today also. Started blocking IPs and quickly realized that wasn’t going to help… turned on login uniqueness, turned off Virtual Office and enabled Geo-ip filter blocking countries/continents.

Thus far no more connections.

4

Sounds like a SW bug where they don’t release a license properly. Can you try with GVPN client as I’d bet even money that the GVPN does not double or triple count like that. SW did some changes the SSL engine (patching of CVE) and likely created another problem.

5

Update: Yes, it is a known bug, originally reported a few days ago - hotfix currently in development. Support recommended a few changes to minimize impact until the hotfix is available:

  • Disable Virtual Office on WAN interface (no problem, didn’t use it anyway)
  • Change port and domain name for SSL connections - This isn’t really an option for me since we have a lot of installations of NetExtender out there that were done with the MSI version, and restricted to a single server/domain. If I change the port/Domain, those users will have to completely uninstall NetExtender and then reinstall the EXE version. I’m not ready to do that yet, so I’ll wait for the hotfix since it seemed it was going to be imminent.
6

I’m seeing this as well, but it was users that don’t exist in our system. I’ve had to block a couple of IPs so I’m wondering if this is a new attack attempt. It was consuming the licenses until they timed out (well now blocked). Reference on how to block SSLVPN connections for certain IPs:

https://www.sonicwall.com/support/knowledge-base/how-to-block-certain-public-ip-addresses-from-accessing-ssl-vpn/230712073537070/

7

2024-04-05

Similar bug exists in SonicOS 6.5.x.

I have a 4600 I am replacing in use. I had this bug on a fully patched 4700 with 7.1.1. The 4600 just got brute forced. It didn’t cause license or IP tie ups like the 4700 does, but the brute force was enough to overload the 4600 and crash something and reboot.
Changing the SSLVPN port helped for now on that.

8

I am honestly done with SonicWALL. This week with the sslvpn brute force attacks that cause the device to lock up, to (the terrible offshore) tech support bricking one of our TZ370s requiring my technician to drive 2 hours to the site to reset it and import the config backup. Oh and not to mention the firmware upgrades that seem to cause more issues than they fix. Even our own office TZ400 would not boot properly after swapping out a UPS. I think we’ll hit up Fortinet again.

9

I had this issue last week and thought someone was trying to brute force and connect. ended up changing my SSL port as a temp fix.

10

Update: SW Support sent me the hotfix today - I haven’t loaded it yet, but will do so this evening. I haven’t seen any additional pending logins, but a search of the logs for the last 24 hours for event 32, showed 2 hundred attempts early this morning from a single IP (US located: 162.210.103.224), so I just added that to the WAN->WAN block rule I created earlier. The domain at that IP is altar56.supremepanel56.com, so clearly not a local user.

11

I too and having this problem running 7.1.1.7051 on a NSA 4700.

I have SSL-VPN on Port 443.

We were getting brute forced with dozens of “office” users with login sessions under SSL-VPN stuck in initiating phase and some other random usernames as well. We have Multifactor SSO (In line RADIUS) so all attempts failed. It caused our IP Pool for SSL-VPN to get exhausted, and all 55 licenses to be in use as well. (Normally we have a under 20 or so). I noticed we were getting logins to the tune for 30 or so a second at times. I am VERY surprised the NSA does not rate limit bad logins by IP as in our case they were from single IP sources, with the IP changing every few hours.

This was causing our NSA to hard lock up and reboot as these attacks happened 3-4 times over the course of an hour or two before relenting.

Per recomendations here we disabled Virtual Office on Non-LAN interfaces. This cut down on “office” users attempting to connect. I still had a few rogue random user accounts trying to connect. I create a WAN-WAN for WAN Interfaces to block a Address Group of IP’s I created. Likewise on the default WAN-WAN rule for WAN interfaces for SSLVPN, I modified Geo-IP rules to only United States for now. Helps a little but some bad IPs are from within the US.

This seems to have mitigated it mostly for now, however waiting on a firmware upgrade from SonicWall to hopefully fix this. If it continues to reboot our system, I may either change the SSLVPN port or disable it on the interface they are attacking and route users to our backup connection WAN.

12

One more update - I got back with support yesterday and we reloaded the Hotfix (7051-R3176). That seems to have stopped the attempted logins taking more than one license.

Now that I am paying pretty close attention to the logs, though, I note that we are getting hammered with attempted logins. These are all US-based IPs (so not stoppable by the GEO-IP filter), and it is usually just a couple of IPs trying for a pretty short period. For example, this morning at 11:33, a single IP tried 4,063 times to log in until 11:43. Then at 11:46, a different IP tried 1,332 times to log in until 11:52. No more today, but there will be more tomorrow, I expect.

This might be normal behavior as I haven’t studied the logs before so closely. None of these attempted logins were successful, so I suppose we’ll just have to accept this as normal.

BTW, the 670 comes with 32GB of “storage memory” that is unused by default, but you can set the logs to be stored there, which will give you a whole lot more history to look at than if you leave them set at default. I don’t think any of the smaller models have this option. Device–>Settings–>Storage–>Files–>Settings. Flip the toggle to “Enable logging to storage”

I also noted that once you change the storage location, you can no longer sort by any of the columns on the Monitor–>System Logs screen. So in my case, for example, I had to just search for the phrase “login denied” and “login allowed” to see just those entries and determine if any bad guys were successful (they weren’t).

13

We also have this problem, as a work around I have downloaded the no-IP DUC tool and installed it on all PC’s that connect to us via the SSL.

I then have added the FQDN that the DUC tool repots back to as as address object in the firewall and created a group with all of these FQDN’s in, so the firewall now knows the IP address of the SSLVPN user before they even connect via the SSL.

In the firewall Access Rules I have edited the WAN>WAN rule for SSLVPN to include the new group of FQDN’s so now it checks the IP address of the user before it connects to the SSL meaning if it don’t see the IP, it will not connect

Also waiting on a patch

14

Same issue here; tech support gave me the hotfix R3213-HF46826 (not R3176) and I will test it today.

I am also getting hammered by brute forces! I managed to get it under control by enabling “Admin/user lockout” at Device->Administration->Login/Multiple Administrators

15

We have this issue and now that we applied their hot fix our firewall is randomly rebooting.
The fix didn’t mitigate the attacks. Setting accounts to lock from the firewall did. Unfortunately, the firewall rebooting is a much worse issue…

16

Can people post up the ip’s they are getting hit by? here are the ones in the last hour or two from me:

89.147.254.3

41.77.112.210

67.227.153.13

203.209.197.134

216.194.172.181

104.36.56.82

191.252.104.213

17

I found this Sonicwall article that has some recommendations for this issue: https://www.sonicwall.com/support/knowledge-base/sslvpn-license-exhaustion-on-gen7-firewalls/240325115738957/

18

This is absolutely freakin ridiculous. Why can’t Sonicwall implement a fix to only allow vpn login attempts from known users in a group?

I’m done with Sonicwalls.

Anyone got some updates?

19

Hey all, you can open a support case and they will give you a link to the hotfix release which is supposed to solve the issue. I haven’t read the release notes yet, but I did get the file. It was mentioned in this KB article near the top. https://www.sonicwall.com/support/knowledge-base/sslvpn-license-exhaustion-on-gen7-firewalls/240325115738957/ filename is, sw_tz_370.7.1.1-7051-R3262-HF46826.bin.sig

I will report back if it made any difference. For now, we’ve been locking down the SSL VPN firewall rule to US only and then adding any US based bad actor IPs to a firewall block policy. This is all stupid and messy for sure

20

The hotfix R3262-HF46826, finally, seems to work!