Join the Conversation

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


Poor RDP performance with NetExtender SSL/VPN starting with firmware 7.0.1 5080


we recently upgraded an NSA 2650 to an NSA 2700 running on 7.0.1 5080

First day in production users (connecting with NetExtender over SSL VPN) complained about reduced performance of the RDP connection, comparing to the NSA 2650.

The RDP connection is no more using UDP. Packet capture shows that the rdp client tries an UDP connection, and these packets are dropped. "DROPPED, Drop Code 726(Packet dropped - Enied by SSLVPN per user control policy) Module Id 27(policy)

There is no firewall rule in place, vpn access is allowed for the destination ip (we and support also tried with whole subnet).

We were able to reproduce the problem with an TZ 670. It was on 7.0.1 5065, rdp worked fine with udp. We did an upgrade to 7.0.1 5080 and now udp stopped working, same drop code.

Sonicwall told us they were able to reproduce this in the lab, ant they gave it to the Engineering team.

Today I received the answer from Engineering "RDP using UDP is not supported on SSLVPN and this is by design. We have an enhancement request (RFE 4675) raised with engineering to include the support for "RDP over UDP" on SSLVPN sessions.  as a workaround, you need to force RDP over TCP" 

No explanation, why this was working with the NSA 2650 or the TZ 670 with 7.0.1 5065 just "is not supported"... I can't believe that.

If there is anybody out there, who also uses Netextender SSL VPN and rdp sessions. Please check UDP (click on the connection state/quality button in the rdp client in fullscreenmode). For optimal performance it should look like this:

As stated above, after the upgrade to 7.0.1 5080 and in the other case after importing the configuration in the NSA 2700 with 7.0.1 5080 it looks like this

Best Regards,


Category: Entry Level Firewalls


  • Options
    tgbtgb Newbie ✭

    Found this in release notes for the 7.0.1 5080 firmware:

    GEN7-31660 An UDP session was being enabled for RDP sessions connected through

    NetExtender, causing severe packets loss and, eventually, disconnection.

    This sounds like someone encountered connection problems with RDP connections over UDP. So maybe they really decided starting with firmware 5080 to drop rdp connections via udp "by design".

    Our customers had no problems with these type of connections. I think the firewall should not drop packets, without letting the user decide whether allow this type of data or not.

  • Options
    TKWITSTKWITS Community Legend ✭✭✭✭✭

    I have customers use RDP over SSLVPN in a Gen7 7.0.1.-5080 setup, BUT I always set the RDP connection 'Experience' parameters. I NEVER let it 'autodetect connection quality'. I only enable 'Visual Styles' and 'Font Smoothing'.

    I'm not saying that will change for your instance, but I haven't received any complaints.

    But yes, this was changed by design. Release notes are your friend.

  • Options
    BWCBWC Cybersecurity Overlord ✭✭✭

    Hi guys,

    I'am confused, -5080 Release Notes listed this as Resolved Issue

    GEN7-31660 An UDP session was being enabled for RDP sessions connected through NetExtender, causing severe packets loss and, eventually, disconnection.

    For what reason should it be disabled in NetExtender, it's a Tunnel after all. I would understand if it's disabled in a Bookmark, but in NetExtender? That's just weird.


  • Options
    tgbtgb Newbie ✭

    Starting with 5080 it drops these types of packets. I'm not sure whether it is really related to this resolved issue. But the resolved issue reads very much like the issue we see - no more rdp udp packets go through the tunnel. Because other udp packets (tested with netcat) still go through, they must have somehow harcoded this rule.

    Ok, writing this - I tested what about connections to non standard rdp port?

    Changed rdp port from 3389 to 3390 on one test workstation. Established connection - voila RDP works over UDP

    They really have hardcoded dropping UDP Packets to port 3389 over SSL VPN

    I can't believe it

  • Options
    TKWITSTKWITS Community Legend ✭✭✭✭✭

    I can. This is 'agile' development.

    But to label it as a resolved issue, that's 'boundless'!

  • Options
    ArkwrightArkwright All-Knowing Sage ✭✭✭✭

    Interesting using of the words "design" and "friend" there tkwits :D

    This is a complete and utter hack. What other kinds of UDP traffic are going to be targetted next? Softphones, perhaps? "RTP blocked by design, just forward calls to your mobile instead".

Sign In or Register to comment.