Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

SSLVPN random drops and connections slow to timeout and disconnect

Natco_WGNatco_WG Newbie ✭

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.

Category: SSL VPN


  • ArkwrightArkwright All-Knowing Sage ✭✭✭✭

    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

  • MoanerMoaner Newbie ✭


    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

  • ArkwrightArkwright All-Knowing Sage ✭✭✭✭

    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!

  • Natco_WGNatco_WG Newbie ✭

    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.

  • ArkwrightArkwright All-Knowing Sage ✭✭✭✭

    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.

  • Natco_WGNatco_WG Newbie ✭

    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.

Sign In or Register to comment.