Poor RDP performance with NetExtender SSL/VPN starting with firmware 7.0.1 5080
Hi,
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,
Thomas
Answers
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.
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.
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.
--Michael@BWC
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
I can. This is 'agile' development.
But to label it as a resolved issue, that's 'boundless'!
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".