Re: tcp options
On Mon, Aug 03, 2015 at 08:16:48AM +, zaafar.ta...@gmail.com wrote: Dear Willy, Thank you for the quick response. I wasn???t interested in some specific TCP option. I was interested in differentiation of HAProxy heartbeat handshakes from client request tcp handshakes while connecting to the backend server. So, allowing any option to be forwarded to backend server would do the trick. Normally you want them to be the same otherwise you can end up with a check that works and prod traffic that doesn't work. Up till now I have thought about using (A) transparent proxy mode, (B) separate IP for heartbeat and separate IP for client request or (C) separate port for heartbeat and separate list of ports for client reuqest. However, in option (A) it isn???t possible to load balance traffic from the same subnet, option (B) is the best option I have so far but it requires an additional IP to be allocated to HAProxy and option (C) would limit the number of concurrent connections per backend server. You can also use the addr parameter to force to send health checks to a different IP address. That may fit your needs. Other people simply use a different method in the health check that is not logged. That's why the default method is OPTIONS. Regards, Willy
Re: tcp options
Dear Willy, Thank you for the quick response. I wasn’t interested in some specific TCP option. I was interested in differentiation of HAProxy heartbeat handshakes from client request tcp handshakes while connecting to the backend server. So, allowing any option to be forwarded to backend server would do the trick. Up till now I have thought about using (A) transparent proxy mode, (B) separate IP for heartbeat and separate IP for client request or (C) separate port for heartbeat and separate list of ports for client reuqest. However, in option (A) it isn’t possible to load balance traffic from the same subnet, option (B) is the best option I have so far but it requires an additional IP to be allocated to HAProxy and option (C) would limit the number of concurrent connections per backend server. Regards, zaafar From: Willy Tarreau Sent: Sunday, August 02, 2015 4:14 PM To: zaafar.ta...@gmail.com Cc: haproxy@formilux.org Hello, On Sat, Aug 01, 2015 at 09:23:27AM +, zaafar.ta...@gmail.com wrote: Hello, If client send few additional TCP options (during TCP handshake) to haproxy would HAPROXY respect those options and forward them to the backend server? Is it possible to enable this feature from the configuration file? No it is not possible. HAProxy is a TCP proxy meaning that it uses two separate and independant TCP connections. The options you have on one side may not even be relevant to the other side (eg: MSS values, etc). What do you have in mind, is there a specific option you're interested in ? Regards, Willy
Re: tcp options
Hello, On Sat, Aug 01, 2015 at 09:23:27AM +, zaafar.ta...@gmail.com wrote: Hello, If client send few additional TCP options (during TCP handshake) to haproxy would HAPROXY respect those options and forward them to the backend server? Is it possible to enable this feature from the configuration file? No it is not possible. HAProxy is a TCP proxy meaning that it uses two separate and independant TCP connections. The options you have on one side may not even be relevant to the other side (eg: MSS values, etc). What do you have in mind, is there a specific option you're interested in ? Regards, Willy
tcp options
Hello, If client send few additional TCP options (during TCP handshake) to haproxy would HAPROXY respect those options and forward them to the backend server? Is it possible to enable this feature from the configuration file? Regards, Zaafar Ahmed
Re: Feature Request: Extract IP from TCP Options Header
Hi Willy, On 2014-05-07 10:54, Willy Tarreau wrote: Hi Jim, On Fri, May 02, 2014 at 04:13:40PM +0100, Jim Rippon wrote: Hi all, As mentioned on the IRC channel today, I have a requirement to extract an end users IP address from the TCP Options Header (in my case with key 34 or 0x22, but there are other similar implementations using 28 or 0x1C). This header is being added by some Application Delivery Optimisation solutions by providers such as Akamai (with their IPA product line) and CDNetworks (with their DNA product) though there are likely others out there hijacking the TCP headers this way. Cool, I'm happy that some people start to use TCP options for this, it could drive forward improved APIs in various operating systems to help retrieve these options. We designed the PROXY protocol precisely as an alternative for the lack of ability to access these. Because the options headers won't be forwarded by haproxy to the back-end servers, the most useful way to deal with this for our http services would be to extract the IP address encoded and place it into either the X-Forwarded-For or X-Real-IP headers, so that it can be understood and handled by the upstream servers. Sample implementations can be found in documentation from F5 [1] and Citrix [2] below. In the TCP SYN packet (and some later packets, but always in the initial SYN) we see the option at the end of the options header field like so in our packet capture: 22 06 ac 10 05 0a Broken down, we have: 22 = TCP Options Header key (34 in this case with CDNetworks) 06 = Field size - this appears to include the key, this size field and the option value ac 10 05 0a = the IP address of the end-user - faked in this example to private address 172.16.5.10 This would be hugely useful functionality - it would allow us to avoid the expense of high-end load balancer devices and licenses to support testing of our CDN implementations before going into production. Sure it would be great, and even better if we could set them. The only problem is that there is no way to retrieve these information from userland. The option is present in the incoming SYN packet, is not recognized by the kernel which skips it, and as soon as the system responds with the SYN/ACK, the information is lost. Are you aware of kernel patches to retrieve these options ? If at least one of them is widely deployed, we could consider implementing support for it, just like we did in the past with the cttproxy or tcpsplicing patches. Best regards, Willy The closest I have come so far is to have an NFQUEUE hook in iptables on my Linux servers which can extract the details from the raw packets. I don't see a way I could use this on its own, however, to mangle the packets and insert an http header as changing the size of the payload will lead to the TCP sequence numbers becoming incorrect when the server replies. My simple cli script using Python and SCAPY can be found here: http://bit.ly/1kSeZV7 My NFQUEUE proof-of-concept script can be found here, though this has the known flaw that it breaks tcp sequencing: http://bit.ly/1kSeGtu Don't know if that would help anyone - I don't really know where to go next with this, presumably a KV store for source ip/port vs ip from header populated by the nfqueue handler, that can be referred to when populating the XFF field? Jim
Re: Feature Request: Extract IP from TCP Options Header
Hi Jim, On Fri, May 02, 2014 at 04:13:40PM +0100, Jim Rippon wrote: Hi all, As mentioned on the IRC channel today, I have a requirement to extract an end users IP address from the TCP Options Header (in my case with key 34 or 0x22, but there are other similar implementations using 28 or 0x1C). This header is being added by some Application Delivery Optimisation solutions by providers such as Akamai (with their IPA product line) and CDNetworks (with their DNA product) though there are likely others out there hijacking the TCP headers this way. Cool, I'm happy that some people start to use TCP options for this, it could drive forward improved APIs in various operating systems to help retrieve these options. We designed the PROXY protocol precisely as an alternative for the lack of ability to access these. Because the options headers won't be forwarded by haproxy to the back-end servers, the most useful way to deal with this for our http services would be to extract the IP address encoded and place it into either the X-Forwarded-For or X-Real-IP headers, so that it can be understood and handled by the upstream servers. Sample implementations can be found in documentation from F5 [1] and Citrix [2] below. In the TCP SYN packet (and some later packets, but always in the initial SYN) we see the option at the end of the options header field like so in our packet capture: 22 06 ac 10 05 0a Broken down, we have: 22 = TCP Options Header key (34 in this case with CDNetworks) 06 = Field size - this appears to include the key, this size field and the option value ac 10 05 0a = the IP address of the end-user - faked in this example to private address 172.16.5.10 This would be hugely useful functionality - it would allow us to avoid the expense of high-end load balancer devices and licenses to support testing of our CDN implementations before going into production. Sure it would be great, and even better if we could set them. The only problem is that there is no way to retrieve these information from userland. The option is present in the incoming SYN packet, is not recognized by the kernel which skips it, and as soon as the system responds with the SYN/ACK, the information is lost. Are you aware of kernel patches to retrieve these options ? If at least one of them is widely deployed, we could consider implementing support for it, just like we did in the past with the cttproxy or tcpsplicing patches. Best regards, Willy
Feature Request: Extract IP from TCP Options Header
Hi all, As mentioned on the IRC channel today, I have a requirement to extract an end users IP address from the TCP Options Header (in my case with key 34 or 0x22, but there are other similar implementations using 28 or 0x1C). This header is being added by some Application Delivery Optimisation solutions by providers such as Akamai (with their IPA product line) and CDNetworks (with their DNA product) though there are likely others out there hijacking the TCP headers this way. Because the options headers won't be forwarded by haproxy to the back-end servers, the most useful way to deal with this for our http services would be to extract the IP address encoded and place it into either the X-Forwarded-For or X-Real-IP headers, so that it can be understood and handled by the upstream servers. Sample implementations can be found in documentation from F5 [1] and Citrix [2] below. In the TCP SYN packet (and some later packets, but always in the initial SYN) we see the option at the end of the options header field like so in our packet capture: 22 06 ac 10 05 0a Broken down, we have: 22 = TCP Options Header key (34 in this case with CDNetworks) 06 = Field size - this appears to include the key, this size field and the option value ac 10 05 0a = the IP address of the end-user - faked in this example to private address 172.16.5.10 This would be hugely useful functionality - it would allow us to avoid the expense of high-end load balancer devices and licenses to support testing of our CDN implementations before going into production. Regards, Jim Rippon 1: https://devcentral.f5.com/articles/accessing-tcp-options-from-irules 2: http://blogs.citrix.com/2012/08/31/using-tcp-options-for-client-ip-insertion/
