load balance MSRDP traffic

Hi Phillip,

 

 

I don't think that will work, as the TCP won't contain the hostname. To test this, try capturing a tcpdump on your client using Wireshark while you connect using RDP to a remote host. You can try testing by IP address, hostname or using a fake hostname set in your hosts file for the remote host. I don't think you'll see the hostname or the hosts file entry in the TCP packets your client sends to the remote host. This is because RDP doesn't have a concept of host header like HTTP does. The client just resolves the hostname to an IP address and then attempts to establish the RDP connection with that IP address.

 

 

This means you'll need to have separate IP:port combinations for each RDP pool. If you don't want to require clients to specify the port when using mstsc, you'll need to have separate VIPs each defined on port 3389 for each pool.

 

 

Aaron

Hmm, ok. What then, is the proper way to balance RDP traffic in the F5 where I *don't* know an IP range the client is coming from and RDP does not give me header info to query against to route traffic?

 

 

Phillip

Do each of the hostnames (new.vip.com, old.vip.com and reallyold.vip.com) resolve to separate IP addresses? Or can you change DNS so they do? You could then configure three separate VIPs pointing to which ever pool you want used for each hostname.

 

 

Aaron

The 3 vip's externally resolve to the same IP, internally they resolve to 3 diff. IP's. Yes, I can configure the vips on the F5 to statically point to the appropriate pool, but that seems like such a lame way to use the F5.

That may be, but in this case it is a protocol limitation, not a limitation on the BIG-IP. If you control the clients, you could always force the initial username request to pass your unique vipID and distribute traffic that way. User will punch in correct credentials once the login shows up.

I guess I'm also still wondering in what scenario this iRule would work?, what all is in the TCP payload that could be inspected?

 

 

when CLIENT_ACCEPTED {

 

TCP::collect 25

 

}

 

when CLIENT_DATA {

 

if { [TCP::payload 25] contains "legacy" } {

 

pool Pool_Review

 

} else {

 

pool TS_2008_Test_Pool

 

}

 

TCP::release

 

}

@citizen_elah, could you explain "force the initial username request to pass your unique vipID" please.

sure. One of the few things available in the clear is the username or routing token for session mapping. If session directory is enabled, this presents as msts=.... where the value can be extracted into an IP:port. Without session directory, the user credentials are available as mstshash=...... If the clients are on controlled builds, you can force them (or request them) to use old, reallyold, or new as the username so you can balance accordingly. Here's an old thread that approaches this from the persistence angle, but could be modified to switch pools as necessary:

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=25271 Click here

 

 

I am so lost now..., what and where is "session directory"?, what does "username" have to do with any of this?

The RDP Client username field could be used as a workaround to your problem. If you can't guarantee client compliance however, it's probably best not to rely on this. Session directory is a Windows Terminal Services feature that assists in getting wayward rdp sessions back to the original server so a user doesn't orphan multiple sessions in a ts farm due to faulty persistence schemes.