We have recently built a RDS solution and have put BIG-IP LTM infront of the web access server (which is also the gateway & connection server).
I have two iApp built HTTP virtual servers currently in use - one for internally connected devices and one for externals. The idea being we could leverage APM to put 2FA in place for the external connections. All other authentication is handled by the RDS server - not the F5.
The problem I have is that whilst the internal vs works fine the external does not. As soon as I place an access policy on the vs (even just a blank one) I can no longer get a desktop. I still get to the web access RDS logon page and desktop selection, etc but everytime I launch a desktop I get...
Your computer can't connect to the remote computer because the Remote Desktop Gateway server is temporarily unavailable. Try reconnecting later or contact your network administrator for assistance.
Did you assign the RAP policy in the VPE??
We also have that same trouble here currently, using Big-IP 13.1.0 and Remote Desktop on a set of 2019 Servers. We can easily create the Virtual Server/Pool/Node setup and then, we can successfully use the Remote Desktop Environment, either by using the HTML5 client or a RDP client.
However, when we create an Application Security Policy (Brand new simple policy, setup as transparent) and apply it the the virtual server, connection immediatly stops working. As it is non-blocking, this should in theory work perfectly fine.
There seems to be an issue with code injection in the HTTPS traffic as described in these posts:
My first guess looks like that Remote Desktop detects the changes and starts refusing the packets because they are altered. I did go around the system and deactivate all the features mentionned in those posts (Most of them where already off, there was one on but I can't remember which one) but none changed the end result.
We also found this yesterady that seems to point that if your servers are not running on Server 2012 R2 and lower, they are not supported, although it isn't clear if it is through the Application Security or through the Web Access feature in the Big-IP:
We are currently working on starting a service request with F5 to have this checked out. We'll post updates here when we have some, but in the meantime, if someone here has a solution or can confirm this will never work, it would be appreciated.