No UDP support on KEMP for Load Balancing Remote Desktop Gateway

In Windows 2012 (and higher) UDP support for Remote Desktop Gateway (RDGW) was introduced, if you missed that you can read more here.

For a big RD deployment (6000 users) we tested this setup (intensively), but found out this currently does not properly work. After logging a support issue, Kemp said to us;

It seems like we are genuinely supporting RDP connections for TCP, while UDP connections are being ignored for port following. I will tender this for a feature request.

I will post some details on our current setup, as in our tests at first glance it seemed to work, but after digging in deeper the results weren’t constant. This was quite hard to troubleshoot as most traffic was encrypted. MS has some guidelines to decrypt this traffic, but that’s food for another blogpost. We have tested on one Hyper-v 2012R2 machine (Dell R730), all our servers are (patched) 2012R2 VMs which live on this host.
– Two RDGW servers with the config in 2.2.3 of the Kemp deployment guide.
– The RDWA are on different servers.
– Two RDCB in HA setup, currently bypassing the Kemp because of troubleshooting UDP.
– Multiple RDSH hosts (currently 3), no applications installed.
– KEMP VLM200 hosted on a different Hyper-V host, initially 7.1-30-75.20150929-0318, but upgraded to 7.1-32a-88.20160114-2207. This Kemp is used for testing and our office servers, so it has 4 nics and multiple networks. In all the VIPs the default gateway is set accordingly. The persistence is set to 2 minutes for less wait time with testing with new connections. Later Kemp support told me the caching can be flushed by deactivation/activation of the VIP, so i will be doing that from now on.
– Sophos UTM, version 9.351-3 used for NAT rules of RDGW on ports 3389/3391.
– SSL bridging is configured on the RDGW servers with HTTPS-HTTPS (this is not mentioned in the guide).
– The used certificate on all systems is from Thawte and is a wildcard SHA2 certificate valid till 2018.
– We initially tested this on 2 external clients (Win12R2 hosts) from another datacenter, to exclude any interruptions in the internet connection. Mstsc client version 6.3.9600. We started the mstsc client with the settings;
server: sc01.sometestdomain.com
rdgw: sometestdomain.com
The servername is the session collection DNS name and belongs to the Kemp VIP for the RDSH hosts, equivalent with the rsdhfarm.rdpdoc.net name From the Kemp guide.
The RDGW address is the external available url on which the VIP of the RDGW servers is available.
– In a later stadium we tested by downloading the .rdp file from RDWA, but found out we need to set the “full address property” to get the same results as mentioned in 2.2.5.3.1 of the guide. We ran the PS line;
set-RDSessionCollectionConfiguration -Collectionname T-Desktop -ConnectionBroker CONNECTIONBROKER.domain.loc -CustomRdpProperty “full address:S:sc01.sometestdomain.nl”
– There are 2 GPO settings active on the RDSH hosts;
Use IP Address Redirection Disabled
Use RD Connection Broker load balancing Disabled
– Another difference with the Kemp guide is that we have an .loc TLD while the Kemp guide uses a public TLD. We solved this by configuring the certificate on the RDP protocol
– We configured a RDGW Farm in the Gateway Manager on both RDGW servers. This is not mentioned in the Guide. Kemp support confirmed this not to be necessary, but said it couldn’t hurt so we left this in place.
– We triple checked the guide, the (minor) differences from the guide are mentioned above.
– We tested with Direct Server Return (as mentioned in the guide) and without (in a 2 armed config)

Here are some results we got;
– from the same client in another datacenter;
user58 gets an udp
user59 gets an udp
user60 gets an udp
user61 gets an udp
user62 gets an udp
user63 gets an udp
user64 gets an udp
user65 gets an udp
all concurrent sessions (so i start user58, keep that alive and start user59)
Starting these sessions (essentially reconnect) from another client in the same datacenter they all get an udp connection except user65.
– tested with logging into RDWA, starting the connection from there.
user58 gets an udp
user59 gets an udp
user60 gets an udp
user61 gets an udp
user62 gets an udp, after closing the connection and starting the connection, the mstsc would hang on: “configuring remote session..”. After cancelling and restarting, the connection did successfully finish.
user1563 gets an udp, gets “configuring remote session..” hang on first connection. after cancel it would connect.
user1564 gets an udp
user1565 gets an udp
As RDWA keeps reconnecting to the same user, these were not concurrent sessions (so i start rdp with user58, check udp. logoff and start user59).
Starting these sessions (essentially reconnect) from another client user58, user59, user60 would not get udp.

Following the RDS deployment guide we found we have some difficulty with the setup, especially;
– The udp connection won’t start at all if we use the default configuration.
– If we change the ServiceType of the SessionCollection VIP (called rdshfarm.rdpdoc.net in the guide to Generic and add a VIP with udp port following, we do get udp connections.
– There is no load balancing, all the sessions are redirected to the same RDSH server while there are 3 servers in the VIP.
– Kemp told me that the service type Remote Terminal does not do UDP connections, as we found out in our first deployment.
– Transferring bigger files (+10mb) in the RDP connection over UDP will sometimes fail, even with just one available real server. After turning off the UDP this issue was resolved.

So if you use Kemp’s  in your RD deployment, and want to use UDP, please sent them a request. You can mention support case #30785 and #29605 and point to this blog. I will use my contacts to get this feature bumped up on the priority list.