Modifying rdp-cookie OR persistent stick-tables?

Help!
1

Hi,

I’m currently playing around with rdp-cookie load-balancing, and as far as I can tell, there are 2 ways to do it:

  1. balance rdp-cookie

This works great - except the problem is that different clients format the cookie in different ways - it’d be nice to have a way to (almost always) extract the username from the rest of the data. IS there a way to modify the cookie before it’s used in balancing?

  1. stick on rdp_cookie(mstshash),regsub(.*\\\,,g),regsub(@.*,,g) (with balance leastconn)

So the above lets me modify the cookie and remove windows domains from in front and behind the username - which is great! However tables aren’t persistent between unexpected outages/reboots ( and while I’m aware of peering, that doesn’t help for a single proxy server setup or whole-pool outage), so if someone has an rdp session open on a backend node, and I have to restart the proxy service, balance leastconn won’t send them back to their established session.

I’ve discovered I can read and set the table as follows:
echo "show table rdp" |socat stdio /var/run/haproxy.stat >/etc/haproxy/stick-table
Then use the key and server_id on restore to re-establish the table:
echo "set table rdp key bob data.server_id 1" | socat stdio /var/run/haproxy.stat

However doing this manually is a bit racey, and requires a regular backup and restore mechanism along-side haproxy.

any ideas on how to solve the problem of always wanting to balance on rdp-cookie, but also wanting a way to modify the cookie?

2

Hi,

Your assumption about peers is wrong: it can be used to share data between
processes.
This includes the reloading phase when a new process replaces an old one.

Baptiste

3

I know it can share tables with the ‘new’ process on reload/restart, or with other nodes in a pool - but I didn’t think you could completely stop the/all nodes (e.g a reboot) and have the tables persist on restart (i.e have them written to disk)?

4

Sorry I know it doesn’t answer the question at hand but is there any reason you can’t use MS connection broker persistence?

When available this method works better than RDP cookies for several reasons:

  1. No issues with the length of cookies and style of username/domain name entered.
  2. It will entirely honor any disconnected sessions left by users on the hosts.
  3. Doesn’t rely on stick tables.
    …

Anyway, fully understand this is probably not an option or you might have tried it already so I’m just throwing it out there.

5

Hi - yeah this isn’t an option for us - we’re not running any windows servers in this config - only haproxy (as the gateway) and xrdp backends for linux xorg sessions. Of course there might be a connection broker server available for linux, but I’ve not found one so far…

6

Hi, did you find a solution for persisting stick-tables across reboots?

7

Our solution in the end was to set up our pool such that every node is
both an haproxy node and an rdp server, with a single dns A name
pointing to a single ip address.

In normal operation, connections are load balanced and the stick table
synced between nodes.

If all the nodes are down, then there are no rdp sessions active, so the
loss of the stick tables doesn’t matter.

This is obviously a relatively specific solution, but hopefully it’s of
help to you. If not, then the suggested socat example would probably be
the best option.