Only 50% of users connecting with UDP - Not sure why (v18.1)

We recently upgraded to v18 (18.1.0 22733 RAS, 22712 clients). The new 'sessions' tab is great, and we see a lot more information.
Of about 100 clients, we notice only about 50% are connected via. UDP, and we're puzzled as to why.

• All Clients have the same policy (we have a single policy for all users)
• Network-Level authentication is enabled (via. policy)
• Everyone accesses Parallels from the same remote.company.com external DNS/IP), so firewall rules are all the same and as per Parallels' documentation
• Everyone is on the same version of client
• Everyone is on Windows 10 Pro, up to date.
• Internet connections are similar across the board
• No obvious commonalities or reasons why some people are TCP and others are UDP.

I can't really figure out why some people are TCP, others are UDP.
Thoughts or things I can check?

 

I would suggest checking if it's not a UI glitch first (BTW I don't believe this is the case here, but better to doublecheck).
Do you have an option to open "Sessions > Sessions Information > select a session > Show information" on a client that is using TCP according to the Console? does it really use TCP?
All RDP sessions start in TCP and then try switching to UDP if some conditions are met. Looking into the 50% you mentioned I have a question, how many gateways do you have? 2? Do you have "Unable RDP UDP tunneling enabled on all RAS Gateways?

 

I do have that option, yes. Showing information does confirm TCP is TCP, and UDP is UDP... So it's the same in the 'show information' screen as in the main sessions screen.
We have a single gateway. 'Enable RDP UDP Data Tunneling' is indeed enabled, yes.
Hence my curiosity why it's roughly 50/50. The gateway is in AWS with lots of bandwidth available (speed test shows 10g down, 5gup).

 

Very interesting...
What about hosts? is there a correlation between hosts running sessions? do you see both TCP and UDP sessions on the same host?
if yes, then please enable verbose logging on all ras components (server and client), connect from a client that doesn't get UDP connection established, wait for a minute and generate a problem report for us. (Console -> Help -> Upload system report to Parallels).
We will ask a dev to take a look into the report.

Thanks in advance!

 

No correlation with RD session hosts from what we can see - it's random across servers. A given host has some TCP, some UDP.
Our RD session hosts all come from the same golden template, so we know they're configured exactly the same.
It's affecting me personally from my own machine (I don't get UDP), so I'll upload that report shortly referencing your name and this thread.

 

Report uploaded - number 379419842. I'm happy to help diagnose or provide further info if someone wants to contact me on the email address associated with this account.

 

thank you.

 

Dear Scott, our engineers reviewed your report and findings is below:
You had 60 active RDP session at report taking time and Gateway had 58 sockets for TCP and 63 sockets for UDP.
It means almost all your connections worked via UDP.

Could you please, share the way how you figure out your 50/50 TCP/UDP ratio?

 

I got this impression from the 'Sessions' screen in the new 18.1 RAS console. One of the columns shows 'Transport Protocol'. Roughly half show TCP, and the other half show UDP.
Even right now, if I sort by active sessions only (excluding idle, disconnected), I see roughly half of the active sessions show TCP, half show UDP in the 18.1 RAS Console.

 

Hi Scott, please try recommendations mentioned in https://kb.parallels.com/en/125538

 

Hi Alexey - admittedly that won't be an option for us, because out RDSH servers are created randomly every day via. AWS autoscaling... So manually going in and changing each one's name to an IP isn't really feasible for now. We'll wait until a more permanent fix is available. Doesn't seem to be affecting our users much - just something I noticed in passing after upgrading to 18.1.

 

The client fix is required.
UPDATE: The hotfix is expected after 18.2.