Showing results for 
Search instead for 
Did you mean: 

iRule for RDS Session


I'm a newby at this so forgive me in advance if that applies. I'm running iapp rds_session_host.v10.2, I would like to use Big-IP to route RPD traffic to assigned desktops, based on user name.


Looking to keep this RDP not HTTPS, userA, userB open Remote Desktop and login, Big-IP routes userA to RD-Machine-A, routes userB to RD-Machine-B.


Is this possible?






The RDP Protocol has indeed a build-in support to pass the username (aka. the "MSTSHash Cookie") to support load balancing decissions. But this functionality is unfortunately "somewhat" problematic to use, since...


  • The username field of the MSTSHash Cookie will be truncated to the first nine characters (including DOMAIN\ notations)
  • Its somewhat unreliable, because of certain client side flaws/bugs, causing the the Microsoft RDP client to not update the cookie value on username changes or sometimes doesn't even send the username at all.
  • Its again somewhat unreliable, since not every 3rd party RDP client do support the "mstshash cookie" mechanism.

You could evaluate the "MSTSHash Cookie" functionality by using the iRule below. The iRule will [TCP::collect] the first RDP packet, extract the username from the "MSTSHash Cookie" field and then simply [log] the the value to your LTM logfile.


when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA { if { [TCP::payload] contains "Cookie" } then { log -noname local0.debug "RDP Session provides the Cookie = [findstr [TCP::payload] "Cookie: " 8 "\n"]" } else { log -noname local0.debug "RDP Session does not provide a Cookie" } TCP::release }

Note: The provided iRule could be easily extended to lookup a datagroup to select a RDP host for a given username. But again, I highly doubt that the "MSTSHash Cookie" functionality is stable enough, to meet your requirements.


Note2: Parsing the "MSTSHash Cookie" will be most likely the only possibility you have, to inspect the username and route the session to a given terminal server. If this functionality won't meet your requirements, then it MAY be possible to intercept/relay the X.224 BPDUs (its easy) of the initial RDP handshake, proxy/insepct the TLS negotiation of the RDP protocol (little more complicated) and then parse the NTLM challange/response of the RDP network level authentication (I never did that before)...


Cheers, Kai