SSLVPN random drops and connections slow to timeout and disconnect
Hello All,
I have a site running an NSa3700 HA Pair. Last week I upgraded from SonicOS 7.0.1-5119-R4713 to 7.1.1-7040-R5387. Ever since the firmware upgrade my users have not stopped dropping off SSLVPN connections. All users have different usage patterns but the most common would probably be RDP sessions, File Share via SMB and HTTPS/HTTP traffic to servers located at the datacenter.
I currently have a case open with SonicWall regarding this issue but we're not getting anywhere fast. Has anyone upgraded to 7.1.1 and run into the same issue?
Does anyone have any ideas?
I also contemplated a rollback but they said I'd have to do a factory boot to 7.0.1 and import a backup taken from 7.0.1. Has anyone done a rollback in the past, how did you proceed and what was your experience?
Thank you all for taking the time to address this post.
Comments
Before upgrading, always take an on-box backup [and export a backup]. That way you can roll back to a previous version much more easily.
Not trying 7.1 until everyone else has had a few months to find all the bugs first :D
@Natco_WG
Enduring the same issue as you (RDP Drops thru NetExtender) and have an open ticket for approx 3 weeks now. SW Techs have been very supportive but nothing definitive yet. From from the many conversations I've had with tech (Devinder in my case) seems to be UDP issue. My guy Devinder said something about better to use TCP than UDP in the RDP protocol. Based on this my own research on this theme found a workaround that seems to be working. Long story short, Part 1) on your RDP host machine in local group policy (gpedit.msc) change force the RDP connection to make TCP only connections. Then Part 2) on your (Windows) client machine instead of using NetExtender use the Sonicwall Mobile Connect App. ( available from the Windows Store) Between these two steps I went from dropping connections after mere minutes to connecting 8 hours at a stretch.
What you want to is Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment. Enable Remote Desktop Protocol 8.0 set to Enabled.Then Remote Desktop Session Host > Connections. Select RDP Transport Protocols set to Use Only TCP
Good Luck
Oh the irony....UDP improves performance of RDP sessions. If the only reason for turning it off is Netextender, then it would make more sense to block 3389/UDP from SSLVPN -> LAN so that only Netextender users are affected by this!
Unfortunately that was my complete downfall here 😅... I also took to posting this on the SonicWall subreddit and another person commented similarly. According to him, if I had taken the back up locally I would have been able to roll it back easily, instead I have cloud back ups and SonicWall's suggestion was to rollback the firmware factory default and reimport the prior configuration at the respective firmware level.
Yep, that's how it's done. If you attempt to do it the wrong way, it will leave a marker in the configuration and Sonicwall support will use this as the reason for any future issue you may have.
Thanks for your detailed input Moaner. I'm curious did forcing your RDP connections over TCP noticeably change the performance of your connection to the terminals in comparison to RDP via UDP?
As mentioned initially, our issue involves that and more so I'm a little apprehensive in forcing TCP connections since I see the problem there less, but I'm definitely interested in trying the SonicWall Mobile Client.
I will try the SWMC and report my findings and if I see the RDP issue continue to be a nuisance I'll consider forcing the TCP RDP connection.
I ran into the same issue with IPSec VPN. The 'keep' alive' fails to keep the link up between TZ470s so if there is no traffic the link will drop. Currently using continuous pings to keep the link up until support can resolve this. Different VPNs between the 470s and 570 are OK.
Have you tried IKEv2? IME, it "tries harder" to keep a VPN alive.
FYI support had a hotfix for this and stated it is included in the 7.1 firmware released today. I can confirm the hotfix has worked well for us so far (been a few days since implementation).
Thanks keeping this alive. Now that bring this to attention I'll go ahead and review the release notes, but even then I think I may hold off a few more weeks. If you happen to remember this post a few weeks down the line I'd love to hear your feedback about how it's continued to work for you.