Re: Binaries for HAProxy.
Hi Kuldip, I think you may need to provide a little more information, it may be that your Linux distribution may already have haproxy in their repository. However the information supplied does not really show what your running. Do you know the distribution name? If its Debian then something like 'apt-get install haproxy' may be all you need, RedHat based distros may use yum so 'yum install haproxy'. however its also not that hard to compile the latest version from source and is well documented in the download file. Usually on a list like this you need to supply as much information as possible so the people here can help. Kind Regards, Mathew On 16 July 2014 14:50, Kuldip Madnani k.madnan...@gmail.com wrote: Hi, Where can i find the compiled binaries for haproxy.My system configuration is this : $ uname -a Linux 2.6.32-279.22.1.el6.x86_64 #1 SMP Sun Jan 13 09:21:40 EST 2013 x86_64 x86_64 x86_64 GNU/Linux Thanks Regards, Kuldip
Re: Binaries for HAProxy.
Hello Kuldip, Ok in that case you can probably use the following command to install the binary. yum install haproxy however this may be an older 1.4 version, if you want to build the latest version you can use the guide here and simply skip over the Transparent/T_Proxy part. http://blog.loadbalancer.org/setting-up-haproxy-with-transparent-mode-on-centos-6-x/ On 16 July 2014 15:14, Kobus Bensch kobus.ben...@trustpayglobal.com wrote: Hi I have built my own RPM with a spec file and it works great. I can share the rpm if anybody is interested Kobus Bensch *Address:* *Phone:* *Email:*22 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD 0207 871 3890 kobus.ben...@trustpayglobal.com On 16 July 2014 15:07, Kuldip Madnani k.madnan...@gmail.com wrote: My Linux Distribution is : Red Hat Enterprise Linux Server release 6.3 (Santiago) On Wed, Jul 16, 2014 at 9:03 AM, Mathew Levett mat...@loadbalancer.org wrote: Hi Kuldip, I think you may need to provide a little more information, it may be that your Linux distribution may already have haproxy in their repository. However the information supplied does not really show what your running. Do you know the distribution name? If its Debian then something like 'apt-get install haproxy' may be all you need, RedHat based distros may use yum so 'yum install haproxy'. however its also not that hard to compile the latest version from source and is well documented in the download file. Usually on a list like this you need to supply as much information as possible so the people here can help. Kind Regards, Mathew On 16 July 2014 14:50, Kuldip Madnani k.madnan...@gmail.com wrote: Hi, Where can i find the compiled binaries for haproxy.My system configuration is this : $ uname -a Linux 2.6.32-279.22.1.el6.x86_64 #1 SMP Sun Jan 13 09:21:40 EST 2013 x86_64 x86_64 x86_64 GNU/Linux Thanks Regards, Kuldip Trustpay Global Limited is an authorised Electronic Money Institution regulated by the Financial Conduct Authority registration number 900043. Company No 07427913 Registered in England and Wales with registered address 130 Wood Street, London, EC2V 6DL, United Kingdom. For further details please visit our website at www.trustpayglobal.com. The information in this email and any attachments are confidential and remain the property of Trustpay Global Ltd unless agreed by contract. It is intended solely for the person to whom or the entity to which it is addressed. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. Trustpay Global Ltd does not accept any liability for any personal view expressed in this message. -- -- With Kind Regards. Mathew Levett Loadbalancer.org http://www.loadbalancer.org Tel (UK) - +44 (0) 3303801064 (24x7) Tel (US) - +1 888.867.9504 (Toll Free)(24x7)
Re: RDP Session Broker Redirect Token
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?)
Re: RDP Session Broker Redirect Token
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. My haproxy configuration is still the same as in the previous issue and works fine if the mstsc client connects directly. its only when it goes via the Terminal Server Gateway server it breaks. The odd thing is other Session Broker enabled loadbalancers work, its just haproxy that seams to ignore the cookie in this configuration. Kind Regards, On 14 August 2013 19:35, Willy Tarreau w...@1wt.eu wrote: Hi Mathew, On Wed, Aug 14, 2013 at 05:05:17PM +0100, Mathew Levett wrote: Hi Willy, Thanks for the patch and the clarification. That makes total sense now and seams to work perfectly.Untill you add a Remote Desktop Gateway server into the mix. when I then add that I go back to the same issue of sessions not being reconnected when going via the gateway server. however direct connections to the TS farm VIP are fine. its only when going though the Gateway server first that it breaks. Packet captures on the loadbalancer show the same traffic for working and non working and they all include the token as expected but i just can not get the sessions that come in via the gateway to reconnect to existing sessions. Anyone have any ideas or seen this before? Just to be sure to understand, a first connection goes from the client to the gateway, then a new connection goes from the client to haproxy hoping to reach the correct server and it fails, that's it ? Or does the gateway forward the connections to haproxy ? That part is not clear to me, so I'm not sure I understand what the issue can be. Regards, Willy
Re: RDP Session Broker Redirect Token
Hi Willy, Thanks for the patch and the clarification. That makes total sense now and seams to work perfectly.Untill you add a Remote Desktop Gateway server into the mix. when I then add that I go back to the same issue of sessions not being reconnected when going via the gateway server. however direct connections to the TS farm VIP are fine. its only when going though the Gateway server first that it breaks. Packet captures on the loadbalancer show the same traffic for working and non working and they all include the token as expected but i just can not get the sessions that come in via the gateway to reconnect to existing sessions. Anyone have any ideas or seen this before? Kind Regards, On 13 August 2013 16:22, Willy Tarreau w...@1wt.eu wrote: Hi Mathew, On Tue, Aug 13, 2013 at 12:40:43PM +0100, Mathew Levett wrote: Just an update on this, it looks like there may be a small bug in the way multiports work when used with RDP as if I specify the port on the real servers as below it then works correctly. listen TS-Farm bind 192.168.75.38:3389 mode tcp balance leastconn persist rdp-cookie server backup 127.0.0.1:9081 backup non-stick option tcpka tcp-request inspect-delay 5s tcp-request content accept if RDP_COOKIE timeout client 12h timeout server 12h option redispatch option abortonclose maxconn 4 log global option tcplog server TS01 192.168.75.36:3389 weight 1 check inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions server TS02 192.168.75.37:3389 weight 1 check inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions It would appear that the when Session broker is in Use Token Redirection mode you have to specify the RIP ports or you end up with duplicate sessions. Hmmm good point. The RDP protocol transmits the port number in the cookie, so it's a discriminant as well as the address. Thus, I think we should emit a warning when persist rdp-cookie is used in a farm where at least one server does not have an explicit port. Finally I've just done it with the attached patch. Kudos for catching this, I know how hard it can be sometimes to track long-session persistence issues! Best regards, Willy
Re: RDP Session Broker Redirect Token
Just an update on this, it looks like there may be a small bug in the way multiports work when used with RDP as if I specify the port on the real servers as below it then works correctly. listen TS-Farm bind 192.168.75.38:3389 mode tcp balance leastconn persist rdp-cookie server backup 127.0.0.1:9081 backup non-stick option tcpka tcp-request inspect-delay 5s tcp-request content accept if RDP_COOKIE timeout client 12h timeout server 12h option redispatch option abortonclose maxconn 4 log global option tcplog server TS01 192.168.75.36:3389 weight 1 check inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions server TS02 192.168.75.37:3389 weight 1 check inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions It would appear that the when Session broker is in Use Token Redirection mode you have to specify the RIP ports or you end up with duplicate sessions. Kind Regards, On 12 August 2013 17:17, Mathew Levett mat...@loadbalancer.org wrote: Hi all, We seam to have an issue with haproxy where if we set our TS servers to use Use Token Redirection instead of Use IP Redirection (recommended) it does not work. The configuration I am using is a follows listen TS-Farm bind 192.168.75.38:3389 mode tcp balance leastconn persist rdp-cookie server backup 127.0.0.1:9081 backup non-stick option tcpka tcp-request inspect-delay 5s tcp-request content accept if RDP_COOKIE timeout client 12h timeout server 12h option redispatch option abortonclose maxconn 4 log global option tcplog server TS01 192.168.75.36 weight 1 check port 3389 inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions server TS02 192.168.75.37 weight 1 check port 3389 inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions However what I have noticed in packet captures is there seams to be both a mstshash=USERNAME first in the stream and then a msts=Encoded IP after It seams that 70% of the time a user is reconnected to his disconnected session correctly but the other 30% of the time they end up on any one of the other servers. I am wondering if haproxy is triggering on the mstshash instead of the msts as that seams to be sent after the mstnshash. Any help would be greatly received. Kind Regards.
RDP Session Broker Redirect Token
Hi all, We seam to have an issue with haproxy where if we set our TS servers to use Use Token Redirection instead of Use IP Redirection (recommended) it does not work. The configuration I am using is a follows listen TS-Farm bind 192.168.75.38:3389 mode tcp balance leastconn persist rdp-cookie server backup 127.0.0.1:9081 backup non-stick option tcpka tcp-request inspect-delay 5s tcp-request content accept if RDP_COOKIE timeout client 12h timeout server 12h option redispatch option abortonclose maxconn 4 log global option tcplog server TS01 192.168.75.36 weight 1 check port 3389 inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions server TS02 192.168.75.37 weight 1 check port 3389 inter 2000 rise 2 fall 3 minconn 0 maxconn 0 on-marked-down shutdown-sessions However what I have noticed in packet captures is there seams to be both a mstshash=USERNAME first in the stream and then a msts=Encoded IP after It seams that 70% of the time a user is reconnected to his disconnected session correctly but the other 30% of the time they end up on any one of the other servers. I am wondering if haproxy is triggering on the mstshash instead of the msts as that seams to be sent after the mstnshash. Any help would be greatly received. Kind Regards.
