Hi Willem, That sounds very similar to the issue I was experiencing however our set-up was a little different.
1. HA Proxy VIP 1 2. Gateway Servers (two of) 3. HA Proxy Vip 2 4. RDP Servers We also had session broker mode enabled as well. This worked fine for any local connections but if you went though the gateway server you lost persistence, it seems that the gateway server when converting the RDP over SSL to pure RDP did not send the correct token so adding a couple of lines to haproxy resolved this. What your experiencing sounds like the RDP cookie issue we have seen in the past and we have blogged about http://blog.loadbalancer.org/microsoft-drops-support-for-mstshash-cookies/ In this case Micro$oft answer was to simply use session broker. What we were seeing is that not every packet sent by the RDP client would contain the mstshash cookie despite what the technet articles said. Hope that helps. On 6 May 2014 19:58, Willem <wil...@wwgr.nl> wrote: > Willy Tarreau <w <at> 1wt.eu> writes: > > > > > Hi Mathew, > > > > On Thu, Aug 15, 2013 at 10:21:51AM +0100, Mathew Levett wrote: > > > Hello Willy, > > > > > > I believe the client (mstsc.exe) connects to the Gateway server via RPC > > > over HTTPS (443), the gateway then terminates this, and makes a new > normal > > > RDP connection to haproxy, and then onwards to the Real servers, so in > this > > > case the Gateway is the client to haproxy. > > > > > > However what seams to be happening is that the loadbalancer then > balances > > > the connections as normal but does not seam to honor the MSTS cookie at > > > all. its there in the packet capture and its encoded IP match the > correct > > > server but it seams haproxy ignores it. > > > > I suspect there is a very minor difference in the packets that make > haproxy > > not recognize it as the one supposed to contain the MSTS cookie. It could > be > > both a horrible or a subtle bug. Could you please send me privately a > copy > > of the packet capture for the faulty connection ? I'd like to run the > protocol > > parser by hand on it to understand what's wrong there. > > > > Thanks! > > Willy > > > > > > > Hi, > I just stumpled upon this post while googling. We had exactly the same > issue a couple of months a go in a very familiar setting. From Wan to LAn , > if the customer hires multiple terminalservers, the usersessions pass these > components: > > 0: Hardware firewall > 1: Keepalived/LVS Loadbalancer (Layer 4, In Direct Return modus running on > CentOS 6.5) > 2: RemoteDesktop Gateway, redundant on 2x Windows 2012 (Not R2) virtual > machines > 3: HaProxy version 1.5-dev19, single instance running on CentOS 6.5 > 4: 1 out of 3 terminal servers, running Windows 2012 (Not R2) > > Just like Mathew stated; Persistance works great when connecting to the VIP > op HaProxy, but fails when taking the remotedesktopgateway into the mix. > HaProxy just wont reconnect users to their existing session. The Keepalived > loadbalancer mentioned in bullet 1 does not seem to contribute to the > problem. > > To work around this issue, we decided to work around the lack of > persistance by installing the RemoteDesktop ConnectionBroker-role onto the > RD Gateway servers. This works great, but it kind of defeats the use of > HaProxy. It also adds to the complexity of the build solution, because we > now need SQL to enable high-availability on the Connectionbroker-role. > In turn SQL also would have to be build redundant. > > I guess the question of the day would be: Where you guess able to figure > out why userpersitance didn't work for mathew? Is there any way i can > contribute to a solution? (By providing certain logging, doing TCP dumps, > or anything else?) > > > > > > >
