On 05/07/2014 04:40 PM, Mathew Levett wrote:
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 <[email protected] <mailto:[email protected]>> wrote:
Willy Tarreau <w <at> 1wt.eu <http://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?)
Hi Mathew,
It seems to be the same problem we discussed off-list from 22 to 29
august 2013.
We solved it adding a line in config to force the gateway server to
re-attempt a clear connection.
"tcp-request content reject if { req_ssl_hello_type 1 }"
Regards,
Emeric
