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?)
