VPN Users repeatedly dropped [TZ600]
I have an issue with our TZ600 where our VPN users are being repeatedly kicked off their VPN. The only solution is to reboot the firewall whenever this starts happening (once every 24-48 hours).
I've updated the Sonicwall TZ600 to 6.5.4.14-109n but it did nothing to fix the issue. Could the Sonicwall be needing replaced?
Happens with both SSLVPN and Wireguard.
Category: SSL VPN
2
Answers
I'm having a similar issue with a tz400. SSL-VPN users will get kicked out moments after logging in. Sometimes the sonicwall reboots itself, which I'm assuming is related. I saw the 6.5.4.14-109 had a resolved issue related to ssl-vpn causing reboots so I upgraded to it yesterday, then for the rest of the day it seemed fine. But then today having the same issue along with sometimes the sonicwall will reboot itself. I'm glad to know someone else is having a similar issue with these Gen6's. Something else too that idk if its related, but we have a lot of brute force login attempts for ssl-vpn in the log.
I'm having the same issue on my TZ300. We had an older firmware, updated it yesterday to 6.5.4.14-109n, it was working fine for less than 24 hours and then the same issue of NE drops as soon as you establish an RDP session (for all users). Restarted the firewall and now it's working again. I'm submitting a case with Sonicwall support. We probably need to replace it as well.
We are facing a similar issue with our TZ600
I monitored memory leaks on the primary firewall, while the secondary has a stable 64% in standby
The memory usage reaches 99% in about 12-24 hours then it dies, then the secondary takes over and its memory usage starts to rise again, till it also dies
It seems like there is a bug which is causing a process to leak and kill the sonicwall. I dunno, if it is a part of an attack or if it is the software itself
We are running the lastest firmware and we have all recommended protection mechanism implemented
The issue is causing our whole infrastructure to go offline.
This is NOT acceptable! and it should be addressed immidiately
7.1.1-7051 is also rebooting! Try it when you have an sslvpn
configured with an LDAP server, and with some specific users. go figure
I opened a ticket with SonicWALL, it took them a week to come back to me with a hotfix.
It is for TZ570.
It is also happening on gen6 with this 6.5.4.14-109n firmware, and randomly when usrers sslvpn in..
stay on 6.5.4.13-105n for gen6.
I have over 100 of these SonicWALL out there. Was a nightmare with these new firmware for the past 2-3 weeks.
Glad to hear I'm not alone.
I've already received my non-Sonic wall replacement firewall as we cannot risk having more issues and seeing the mess of the 7.x gen 7 firmware I decided not to go with Sonicwall again.
I updated to the 6.5.4.13-109n firmware which still had the issue after 24-48 hours, but after rebooting it once more the issue has gone away. I'm keeping the replacement for it on standby.
We turned off a few site-to-site VPN tunnels and NE stopped disconnecting. We currently have one open tunnel. I'll report back in a few days.
Sonicwall Support has provided a hot fix (hoping this finally resolves this) and are aware of the issue affecting Gen6 Firewalls. It is not public so you have to reach out to Support in order to obtain the hotfix. Commonality found was NetExtender.
Steps were to upgrade the devices to the latest firmware then apply the hotfix.
We don't have any site to site tunnels, only remote users. It's been a week and the VPN has been stable. I'm going to wait for the new firmware and hopefully that will be the end of it.
What firmware number is the hotfix? Did they give an ETA on when this should be public?
Update the SonicWALL to firmware to 6.5.4.14-109n (If you get an error that it can't upload the firmware as the memory is full; reboot the SonicWall then try uploading the firmware.) | The Firmware number for hotfix is | SonicOS Enhanced 6.5.4.14-111n--HFGEN6-2333-16n. We did not get an ETA on when this will be public.
Unfortunately the maintenance/support expired last week on one of my NSA2600, so I can't raise a ticket to receive the hotfix!
I also can't renew the support (due to the 2600 being EOL) so I am having to order a new firewall.
Did the hotfix fix the issue? We're having the issue as well.
I work for an MSP and we have hundreds of Gen6 firewalls we manage. So far we have reports of about 6 or 7 customers experiencing this issue. Like others have posted, reboot or flip to HA unit stabilizes it for a little while, but then the next day it happens again. Spent about 3 hours on the phone with SW support, and got hotfix firmware for 8 different models of firewall, just in case. (They had to create a separate ticket for each one, then get approval to attach each firmware, so that's why it took so long.) Applying hotfix to a few units tonight and will see if it gets cured or not. We are also seeing tons of brute force SSLVPN attempts, but unclear if it's related. We blocked a bunch of countries in Geo-IP settings today on one unit and it seemed to help.
I was able to get the hotfix that is only available by request. I called SonicWall support yesterday 4/10 and finally after an hour of the most annoying hold music ever someone answered. Support was able to upload the hotfix onto "mysonicwall" and once it was downloaded and installed, everything was back to normal.
I would open a ticket and then call them immediately just so they have a reference and can pull up your issue easier.
GG
Glad I found this thread, same issue with Gen6 TZ500, started recently and it's not just NetExtender. Just opened ticket for this hotfix.
We logged this today and got a hotfix within an hour for our TZ-300's, I'll be applying out of hours - but the tech seemed confident it would fix the issue.
We solved our issue, after we monitored thousands of events for Logs - Settings - Users - Authentication Access - Wrong User Password
Check this value and make sure you are not having a brute force attack on your wan ports
If this is the case, then turn off virtual office and all Management and User Login access to the wan ports
Good luck!
Can someone post the version number(s) of the Gen7 Hot Fix. I was given one weeks ago but it has not worked. Support also not answering our support case requests.
We were give sw_tz_470.7.1.1-7051-R3176-HF46826.bin.sig for TZ470 last week and still reboots. Is this the current Hotfix for Gen 7's? Thanks.
Same issue. Waiting on the hot fix from support apparently.
sw_tz_470.7.1.1-7051-R3262-HF46826.bin.sig is the latest for the 470 that is supposed to fix…
We're on 6.5.4.14-109n and still having the issue.
I upgraded to the same firmware, and after a second reboot everything has been working normally for just over a week now. I'm still hoping for a public firmware update that fixes the issue completely. I have a new firewall ready to install just in case it goes down again.
Submitted a support request and they gave me firmware sw_tz-400_eng_6.5.4.14-111n--HFGEN6-2333-17n_6.5.4_release_6_5_4_1_17n_1295194
This appears to have fixed it.
Disabling Virtual Office Portal worked on my Gen6's
On our TZ 6 Gen, FW hotfix: 6.5.4.14-111n--HFGEN6-2333-16n fixed it. Interestingly build date is 16 March so it's a known issue for at least a few weeks..
Looks like there's been a global attack on VPN's.
https://arstechnica.com/security/2024/04/cisco-warns-of-large-scale-credential-compromise-attack-thats-likely-to-get-bigger/
We're also seeing this across a broad range of SonicWall devices. Older devices with lower capabilities seem to be more prone to the problem but we are seeing this on newer devices like the x70 series and NSA as well.
Does anyone have any additional info on mitigation?
No additional info but has anyone seen any updated official firmwares beyond 109n?
We have a remote user who has been having a lot of issues with his NetExtender dropping out after anywhere from a few seconds to a few minutes. I found another post somewhere suggesting to go in to his PCs Group Policy and set "Select RDP transport protocols" to "Use only TCP." Apparently there can be an issue with UDP packets on NE, since setting it to only TCP he's been solid. Worth a try!