Re: [PATCH 0/3] Add http-check agent-hdr option
Hi Simon, On Wed, Apr 17, 2013 at 02:36:36PM +0900, Simon Horman wrote: Hi Willy, On Mon, Apr 01, 2013 at 11:29:12PM +0200, Willy Tarreau wrote: Hi Simon, Sorry for the long delay and thanks for waiting. I've just reviewed your two patch series (16 total). They're pretty good in my opinion. likewise, sorry for the delay. No problem! I'm seeing a few points we'll probably have to adjust : - normally, health checks reserve file descriptors (one per checked server), here we'll have to count up to two fds when the two checks are enabled. I don't remember where this is done, maybe in haproxy.c. Sure, I will look into that and update my patches accordingly. - I think that we'll soon have to support an agent-addr parameter, which means that -addr will have to move from check_common to struct check. Sure, I will move that. I will probably also implement agent-addr as a way to test it. The reason for the last point is that I'm pretty sure that a number of uses of the agent will involve checking a component to get reliability information about the server itself. It might simply be because the server runs on multiple addresses, or in transparent mode. But it might also be because a monitoring station is checked to retrieve the server status. Also what I like with your approach with the struct check is that it could make it easier to combine tests later. Many people ask how it is possible to check two ports at a time and AND them. Till now it was not possible but now it starts to be possible. Thanks. I think there are a few assumptions lingering in my implementation, but it should not be difficult to weed them out and use the code in a more generic manner. We already have a massive number of patches pending for dev18, so I think I'll issue dev18 now then open post-dev18 with your patches. Thanks. Should I re-post my series or make the changes you suggest above as incremental patches on top of my existing patches? As you like. If you make fixes to existing patches, I prefer that you merge them so that we reduce the number of incomplete patches. But if you improve things, I'm perfectly fine with additional patches. Do as you see fit ! Best regards, Willy
Re: [PATCH 0/3] Add http-check agent-hdr option
On Wed, Apr 17, 2013 at 08:03:11AM +0200, Willy Tarreau wrote: Hi Simon, On Wed, Apr 17, 2013 at 02:36:36PM +0900, Simon Horman wrote: Hi Willy, On Mon, Apr 01, 2013 at 11:29:12PM +0200, Willy Tarreau wrote: Hi Simon, Sorry for the long delay and thanks for waiting. I've just reviewed your two patch series (16 total). They're pretty good in my opinion. likewise, sorry for the delay. No problem! I'm seeing a few points we'll probably have to adjust : - normally, health checks reserve file descriptors (one per checked server), here we'll have to count up to two fds when the two checks are enabled. I don't remember where this is done, maybe in haproxy.c. Sure, I will look into that and update my patches accordingly. - I think that we'll soon have to support an agent-addr parameter, which means that -addr will have to move from check_common to struct check. Sure, I will move that. I will probably also implement agent-addr as a way to test it. The reason for the last point is that I'm pretty sure that a number of uses of the agent will involve checking a component to get reliability information about the server itself. It might simply be because the server runs on multiple addresses, or in transparent mode. But it might also be because a monitoring station is checked to retrieve the server status. Also what I like with your approach with the struct check is that it could make it easier to combine tests later. Many people ask how it is possible to check two ports at a time and AND them. Till now it was not possible but now it starts to be possible. Thanks. I think there are a few assumptions lingering in my implementation, but it should not be difficult to weed them out and use the code in a more generic manner. We already have a massive number of patches pending for dev18, so I think I'll issue dev18 now then open post-dev18 with your patches. Thanks. Should I re-post my series or make the changes you suggest above as incremental patches on top of my existing patches? As you like. If you make fixes to existing patches, I prefer that you merge them so that we reduce the number of incomplete patches. But if you improve things, I'm perfectly fine with additional patches. Do as you see fit ! Thanks, got it.
Re: proxy name filtering introduced in haproxy 1.5
❦ 17 avril 2013 01:00 CEST, Willy Tarreau w...@1wt.eu : I've just recompiled haproxy 1.5 with the latest commits. The patch containing a box to filter proxies is useful but I think we should remove the autofocus keyword from the generated html. Currently, it prevents using the keyboard to scroll the page without having to leave the box. Also, in case someone uses stats refresh, it can become quickly painful : each refresh, the browser will scroll up to the box, which is annoying when you want to follow some values in the middle of the statistics page ;-) Are you OK for this modification ? I'm perfectly OK, I didn't think about this and indeed that can quickly become painful, especially for people who like to type a few chars to search contents. I think users of this box will have no problem clicking into it when they need it. You can add a tabindex=1 to the field so that it gets focused on first Tab. -- Say what you mean, simply and directly. - The Elements of Programming Style (Kernighan Plauger)
Re: HA Proxy FTP Load Balancing Timeout
Alok, On Tue, Apr 16, 2013 at 8:26 PM, Alok Kumar a_sa...@yahoo.com wrote: I have a HA Proxy server(1.4), thzt is load balacing FTP traffic to Six FTP servers. I noticed that Load Balancer is dropping traffic after 50 sec, where as there was a valid ftp control port and Large file transfer was in progress over data port. I have the same behavior on my cluster (by design) by setting timeout client (or old clitimeout) setting in haproxy. For me it is desirable, as most (all?) FTP clients will re-open the command channel if needed. The command channel is not needed for ongoing transfers. http://code.google.com/p/haproxy-docs/wiki/timeout_client You might also look for timeout server in your configuration. It may be that this is unintentionally enabled in your configuration. I tried using tcpka in defaults section, but it didn't make any difference. In my particular case, using tcpka option on the backend side could have solved the issue of control channel timing out dut to inactivity. Am I missing something like setting tcp keeyalive time, interval and probe frequency setup on Ha Proxy Linux server. If the answer is not so simple, I suggest you provide your configuration to the list (obscure anything sensitive) to receive more in-depth help.
how to limit access to only 50 users and redirect the others
Hello, We are going to launch a web app for a critical subscription step in our school. A high load the day we open the server, and would therefore like to protect it from that and setup a waitqueue with ha proxy. But we wonder how to setup ha proxy for that. Our idea is that : * we have 3 servers : ha proxy, the web app's server and a third delivering a static html page * if there are too many candidates (let's say over 50), only some of them will get access to the web app. The other will be redirected to the static html page. * if a candidate starts the web process, he must be able to continue until the end of the procedure (idea : use a cookie to have persistence) We have read a bit about maxconn, cookie persistence and maxqueue but we're not sure if our idea can be built with them. Any opinion about that ? Best regards, -- Mikael Kermorgant
Re: how to limit access to only 50 users and redirect the others
Hi Mikael, The question is: When do you consider your server overloaded? Is that when it is running more than 50 requests at a time? Or is that when it manages 50 sessions from an application point of view? In the first case, maxconn on the server line statement may help. In the second case, it may be a bit more complicated to do. You can find an example of how you can do this using stick tables here: http://blog.exceliance.fr/2012/09/19/application-delivery-controller-and-ecommerce-websites/ This is the overusage protection section. Baptiste On Wed, Apr 17, 2013 at 2:09 PM, Mikael Kermorgant mikael.kermorg...@gmail.com wrote: Hello, We are going to launch a web app for a critical subscription step in our school. A high load the day we open the server, and would therefore like to protect it from that and setup a waitqueue with ha proxy. But we wonder how to setup ha proxy for that. Our idea is that : * we have 3 servers : ha proxy, the web app's server and a third delivering a static html page * if there are too many candidates (let's say over 50), only some of them will get access to the web app. The other will be redirected to the static html page. * if a candidate starts the web process, he must be able to continue until the end of the procedure (idea : use a cookie to have persistence) We have read a bit about maxconn, cookie persistence and maxqueue but we're not sure if our idea can be built with them. Any opinion about that ? Best regards, -- Mikael Kermorgant
HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hello HAProxy developers/users, I would like to be able to run HAProxy transparently on FreeBSD 8.3. This would be both for my own usage and also to make it available to a larger public by including it in a 'haproxy-devel' package for pfSense. However when trying to use it i get the error: /[ALERT] 104/235847 (72477) : parsing [/var/etc/haproxy.cfg:34] : 'usesrc' not allowed here because support for TPROXY was not compiled in./ From what i read it seams it should be possible. For example the Makefile contains the following: /ifeq ($(TARGET),freebsd)// USE_TPROXY = implicit/ Which seams like it is supposed to be 'supported'. Ive also tried the USE_LINUX_TPROXY=yes compile flag, but this returns 2 undeclared variables *SOL_IP* and *SOL_IPV6*. Ive tried declaring them with substitute values like 'IP_BINDANY', or the value 6 which could stand for the TCP protocol type, or 0. , but though the source did then compile the end result still was that either an error was returned to the browser that no backend was available, together with the following debug error: *[ALERT] 104/235129 (17380) : Cannot bind to tproxy source address before connect() for backend pb3TEST_http. Aborting.** *Or i dont get a response at all and HAproxy seems to be waiting for 'something' to happen.. Could it be that something is not fully supported in HAProxy toghether with FreeBSD to allow transparent proxying? Or am i looking at the wrong side of the problem and would i need to compile the FreeBSD kernel with tproxy support.? Which I believe would be natively supported in version 8, but i might be wrong on that.. I i add after /*setsockopt(fd, SOL_IP, IP_TRANSPARENT, one, sizeof(one)*/ this line: */setsockopt(fd, SOL_IP, IP_FREEBIND, one, sizeof(one));/* It removes the error about 'Cannot bind to tproxy source address...' and packets do seam to be send to the proper destination. Except the connection never establishes.. The browser running on 192.168.1.50 contacts haproxy on its IP:port http://192.168.1.22:81/ Haproxy then forwards the traffic to the server 192.168.0.40.81 which is according to status page L7OK/200 in 0ms. Also the reply packets gets routed back to the original client pc (wireshark confirmed that..), and seam not to get intercepted by HAproxy which i think is supposed to happen.?.. when passing through the 'FreeBSD router'. But when performing a tcpdump on the interface in the 192.168.0.117 network only SYN and SYN-ack packets seem to be 'exchanged'.. Bet never any actual 'data' 21:02:04.915310 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1556876 ecr 0], length 0 21:02:04.915464 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,nop,wscale 8,sackOK,TS val 1281557 ecr 1556876], length 0 21:02:04.915546 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1556876 ecr 0], length 0 21:02:07.910690 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,nop,wscale 8,sackOK,TS val 1281857 ecr 1556876], length 0 21:02:07.911073 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557176 ecr 0], length 0 21:02:07.911079 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557176 ecr 0], length 0 21:02:11.110673 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557496 ecr 0], length 0 21:02:11.110685 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557496 ecr 0], length 0 21:02:13.913959 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,sackOK,TS val 1282457 ecr 1556876], length 0 While when the pc contacts the webserver directly it works 'normally'.. 20:45:12.746359 IP 192.168.1.50.3588 192.168.0.40.81: Flags [S], seq 24635592, win 64240, options [mss 1460,nop,nop,sackOK], length 0 20:45:12.746473 IP 192.168.0.40.81 192.168.1.50.3588: Flags [S.], seq 3353931105, ack 24635593, win 8192, options [mss 1260,nop,nop,sackOK], length 0 20:45:12.746937 IP 192.168.1.50.3588 192.168.0.40.81: Flags [.], ack 1, win 64260, length 0 20:45:12.747071 IP 192.168.1.50.3588 192.168.0.40.81: Flags [P.], ack 1, win 64260, length 282 20:45:12.750878 IP 192.168.0.40.81 192.168.1.50.3588: Flags [.], ack 283, win 65520, length 1260 20:45:12.751005 IP 192.168.0.40.81 192.168.1.50.3588: Flags [P.], ack 283, win 65520, length 1142 20:45:12.751463 IP 192.168.1.50.3588 192.168.0.40.81: Flags [.], ack 2403, win 64260, length 0 20:45:12.800179 IP 192.168.1.50.3588
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
I forgot to mention im using HAproxy 1.5dev18. Hello HAProxy developers/users, I would like to be able to run HAProxy transparently on FreeBSD 8.3. This would be both for my own usage and also to make it available to a larger public by including it in a 'haproxy-devel' package for pfSense. However when trying to use it i get the error: /[ALERT] 104/235847 (72477) : parsing [/var/etc/haproxy.cfg:34] : 'usesrc' not allowed here because support for TPROXY was not compiled in./ From what i read it seams it should be possible. For example the Makefile contains the following: /ifeq ($(TARGET),freebsd)// USE_TPROXY = implicit/ Which seams like it is supposed to be 'supported'. Ive also tried the USE_LINUX_TPROXY=yes compile flag, but this returns 2 undeclared variables *SOL_IP* and *SOL_IPV6*. Ive tried declaring them with substitute values like 'IP_BINDANY', or the value 6 which could stand for the TCP protocol type, or 0. , but though the source did then compile the end result still was that either an error was returned to the browser that no backend was available, together with the following debug error: *[ALERT] 104/235129 (17380) : Cannot bind to tproxy source address before connect() for backend pb3TEST_http. Aborting.** *Or i dont get a response at all and HAproxy seems to be waiting for 'something' to happen.. Could it be that something is not fully supported in HAProxy toghether with FreeBSD to allow transparent proxying? Or am i looking at the wrong side of the problem and would i need to compile the FreeBSD kernel with tproxy support.? Which I believe would be natively supported in version 8, but i might be wrong on that.. I i add after /*setsockopt(fd, SOL_IP, IP_TRANSPARENT, one, sizeof(one)*/ this line: */setsockopt(fd, SOL_IP, IP_FREEBIND, one, sizeof(one));/* It removes the error about 'Cannot bind to tproxy source address...' and packets do seam to be send to the proper destination. Except the connection never establishes.. The browser running on 192.168.1.50 contacts haproxy on its IP:port http://192.168.1.22:81/ Haproxy then forwards the traffic to the server 192.168.0.40.81 which is according to status page L7OK/200 in 0ms. Also the reply packets gets routed back to the original client pc (wireshark confirmed that..), and seam not to get intercepted by HAproxy which i think is supposed to happen.?.. when passing through the 'FreeBSD router'. But when performing a tcpdump on the interface in the 192.168.0.117 network only SYN and SYN-ack packets seem to be 'exchanged'.. Bet never any actual 'data' 21:02:04.915310 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1556876 ecr 0], length 0 21:02:04.915464 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,nop,wscale 8,sackOK,TS val 1281557 ecr 1556876], length 0 21:02:04.915546 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1556876 ecr 0], length 0 21:02:07.910690 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,nop,wscale 8,sackOK,TS val 1281857 ecr 1556876], length 0 21:02:07.911073 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557176 ecr 0], length 0 21:02:07.911079 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557176 ecr 0], length 0 21:02:11.110673 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557496 ecr 0], length 0 21:02:11.110685 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557496 ecr 0], length 0 21:02:13.913959 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,sackOK,TS val 1282457 ecr 1556876], length 0 While when the pc contacts the webserver directly it works 'normally'.. 20:45:12.746359 IP 192.168.1.50.3588 192.168.0.40.81: Flags [S], seq 24635592, win 64240, options [mss 1460,nop,nop,sackOK], length 0 20:45:12.746473 IP 192.168.0.40.81 192.168.1.50.3588: Flags [S.], seq 3353931105, ack 24635593, win 8192, options [mss 1260,nop,nop,sackOK], length 0 20:45:12.746937 IP 192.168.1.50.3588 192.168.0.40.81: Flags [.], ack 1, win 64260, length 0 20:45:12.747071 IP 192.168.1.50.3588 192.168.0.40.81: Flags [P.], ack 1, win 64260, length 282 20:45:12.750878 IP 192.168.0.40.81 192.168.1.50.3588: Flags [.], ack 283, win 65520, length 1260 20:45:12.751005 IP 192.168.0.40.81 192.168.1.50.3588: Flags [P.], ack 283, win 65520, length 1142 20:45:12.751463 IP 192.168.1.50.3588 192.168.0.40.81: Flags [.], ack 2403, win 64260, length 0
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi, In order to work in transparent proxy mode, the server's default gateway must be the HAproxy server. Or at least, the traffic from the server must pass through the haproxy box before reaching the client. Even if HAProxy spoof the client IP, it's HAProxy which initializes the TCP connection, so if the server try to reach the client directly, this one would refuse the connection. Baptiste On Wed, Apr 17, 2013 at 8:01 PM, PiBa-NL piba.nl@gmail.com wrote: I forgot to mention im using HAproxy 1.5dev18. Hello HAProxy developers/users, I would like to be able to run HAProxy transparently on FreeBSD 8.3. This would be both for my own usage and also to make it available to a larger public by including it in a 'haproxy-devel' package for pfSense. However when trying to use it i get the error: [ALERT] 104/235847 (72477) : parsing [/var/etc/haproxy.cfg:34] : 'usesrc' not allowed here because support for TPROXY was not compiled in. From what i read it seams it should be possible. For example the Makefile contains the following: ifeq ($(TARGET),freebsd) USE_TPROXY = implicit Which seams like it is supposed to be 'supported'. Ive also tried the USE_LINUX_TPROXY=yes compile flag, but this returns 2 undeclared variables SOL_IP and SOL_IPV6. Ive tried declaring them with substitute values like 'IP_BINDANY', or the value 6 which could stand for the TCP protocol type, or 0. , but though the source did then compile the end result still was that either an error was returned to the browser that no backend was available, together with the following debug error: [ALERT] 104/235129 (17380) : Cannot bind to tproxy source address before connect() for backend pb3TEST_http. Aborting. Or i dont get a response at all and HAproxy seems to be waiting for 'something' to happen.. Could it be that something is not fully supported in HAProxy toghether with FreeBSD to allow transparent proxying? Or am i looking at the wrong side of the problem and would i need to compile the FreeBSD kernel with tproxy support.? Which I believe would be natively supported in version 8, but i might be wrong on that.. I i add after setsockopt(fd, SOL_IP, IP_TRANSPARENT, one, sizeof(one) this line: setsockopt(fd, SOL_IP, IP_FREEBIND, one, sizeof(one)); It removes the error about 'Cannot bind to tproxy source address...' and packets do seam to be send to the proper destination. Except the connection never establishes.. The browser running on 192.168.1.50 contacts haproxy on its IP:port http://192.168.1.22:81/ Haproxy then forwards the traffic to the server 192.168.0.40.81 which is according to status page L7OK/200 in 0ms. Also the reply packets gets routed back to the original client pc (wireshark confirmed that..), and seam not to get intercepted by HAproxy which i think is supposed to happen.?.. when passing through the 'FreeBSD router'. But when performing a tcpdump on the interface in the 192.168.0.117 network only SYN and SYN-ack packets seem to be 'exchanged'.. Bet never any actual 'data' 21:02:04.915310 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1556876 ecr 0], length 0 21:02:04.915464 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,nop,wscale 8,sackOK,TS val 1281557 ecr 1556876], length 0 21:02:04.915546 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1556876 ecr 0], length 0 21:02:07.910690 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,nop,wscale 8,sackOK,TS val 1281857 ecr 1556876], length 0 21:02:07.911073 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557176 ecr 0], length 0 21:02:07.911079 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557176 ecr 0], length 0 21:02:11.110673 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557496 ecr 0], length 0 21:02:11.110685 IP 192.168.1.50.51194 192.168.0.40.81: Flags [S], seq 352103919, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1557496 ecr 0], length 0 21:02:13.913959 IP 192.168.0.40.81 192.168.1.50.51194: Flags [S.], seq 4102632929, ack 352103920, win 8192, options [mss 1260,sackOK,TS val 1282457 ecr 1556876], length 0 While when the pc contacts the webserver directly it works 'normally'.. 20:45:12.746359 IP 192.168.1.50.3588 192.168.0.40.81: Flags [S], seq 24635592, win 64240, options [mss 1460,nop,nop,sackOK], length 0 20:45:12.746473 IP 192.168.0.40.81 192.168.1.50.3588: Flags [S.], seq 3353931105, ack 24635593, win 8192, options [mss 1260,nop,nop,sackOK], length 0 20:45:12.746937 IP
Re: HAProxy on FreeBSD 8.3 with transparent proxying (TProxy?)
Hi Baptiste, Thanks for your reply, i understand that the traffic must pass through the router/HAProxy box, and for that part i can confirm that the routing of packets is 'working' like it should. To explain my setup a little more: *Webserver* (Win7) 192.168.0.40/24 on a OPT1/DMZ using gateway :192.168.0.117 *HAProxy* on FreeBSD 8.3(pfSense2.1) which performs routing between the 2 networks has 2 interfaces(that matter): DMZ interface has 192.168.0.117/24 LAN interface has 192.168.1.1/24 *ClientPC* (WinXP) 192.168.1.50/24 on the LAN gateway :192.168.1.1 (p.s. to make the picture complete and a little more complicated the FreeBSD and ClientPC are running within 'VMware Workstation' which runs on the Win7 machine., But im positive the networks are correctly separated (using a 'LAN-segment' between FreeBSD and the ClientPC) and traffic does flow through the FreeBSD machine.) All traffic moving between clientPC and the Webserver 'must' go through the FreeBSD machine which routes the traffic, i have confirmed that traffic moves correctly through the FreeBSD machine by using wireshark and tcpdump on all machines. So i have traced the packets of the connection to go like this: 1-ClientPC browser 'connects' to HAProxy and waits for the webpage (ok) 2-HAProxy sends SYN packet to Webserver with a spoofed source IP (ok) 3-Webserver sends response SYN-ack back to the spoofed source IP to its gateway 192.168.0.117 (and the MAC address using that IP) (expected) 4-FreeBSD passes the SYN-ack on to the ClientPC.(this is what should not happen.) ## HAproxy waits and retries for a few timeouts to occur.. and then eventually after about 2 minutes the browser is served the 503 page No server is available to handle this request. ## So to me it seams HAproxy should in step 4 somehow get the SYN-ack packet, im not sure if it should listen/bind on all local IP's or if the traffic should get passed back to a HAProxy port by using for example a NAT rule.?. PiBa-NL Op 17-4-2013 21:21, Baptiste schreef: Hi, In order to work in transparent proxy mode, the server's default gateway must be the HAproxy server. Or at least, the traffic from the server must pass through the haproxy box before reaching the client. Even if HAProxy spoof the client IP, it's HAProxy which initializes the TCP connection, so if the server try to reach the client directly, this one would refuse the connection. Baptiste On Wed, Apr 17, 2013 at 8:01 PM, PiBa-NL piba.nl@gmail.com wrote: I forgot to mention im using HAproxy 1.5dev18. Hello HAProxy developers/users, I would like to be able to run HAProxy transparently on FreeBSD 8.3. This would be both for my own usage and also to make it available to a larger public by including it in a 'haproxy-devel' package for pfSense. However when trying to use it i get the error: [ALERT] 104/235847 (72477) : parsing [/var/etc/haproxy.cfg:34] : 'usesrc' not allowed here because support for TPROXY was not compiled in. From what i read it seams it should be possible. For example the Makefile contains the following: ifeq ($(TARGET),freebsd) USE_TPROXY = implicit Which seams like it is supposed to be 'supported'. Ive also tried the USE_LINUX_TPROXY=yes compile flag, but this returns 2 undeclared variables SOL_IP and SOL_IPV6. Ive tried declaring them with substitute values like 'IP_BINDANY', or the value 6 which could stand for the TCP protocol type, or 0. , but though the source did then compile the end result still was that either an error was returned to the browser that no backend was available, together with the following debug error: [ALERT] 104/235129 (17380) : Cannot bind to tproxy source address before connect() for backend pb3TEST_http. Aborting. Or i dont get a response at all and HAproxy seems to be waiting for 'something' to happen.. Could it be that something is not fully supported in HAProxy toghether with FreeBSD to allow transparent proxying? Or am i looking at the wrong side of the problem and would i need to compile the FreeBSD kernel with tproxy support.? Which I believe would be natively supported in version 8, but i might be wrong on that.. I i add after setsockopt(fd, SOL_IP, IP_TRANSPARENT, one, sizeof(one) this line: setsockopt(fd, SOL_IP, IP_FREEBIND, one, sizeof(one)); It removes the error about 'Cannot bind to tproxy source address...' and packets do seam to be send to the proper destination. Except the connection never establishes.. The browser running on 192.168.1.50 contacts haproxy on its IP:port http://192.168.1.22:81/ Haproxy then forwards the traffic to the server 192.168.0.40.81 which is according to status page L7OK/200 in 0ms. Also the reply packets gets routed back to the original client pc (wireshark confirmed that..), and seam not to get intercepted by HAproxy which i think is supposed to happen.?.. when passing through the 'FreeBSD router'. But when performing a tcpdump on the interface in the 192.168.0.117 network only
stick on src same source ip send request to different server port
I'm wondering when setting up haproxy with stick on src, if the same client send 2 requests to different ports on server. i.e. 443 and 8443. Are these 2 requests going to hit same server always? Thanks, William
Re: stick on src same source ip send request to different server port
Yes, as long as you use them in the same backend or you point one backend to the other one. An example for a persistence for both IMAP and SMTP: http://blog.exceliance.fr/2011/07/14/send-users-to-the-same-server-for-imap-and-smtp/ Baptiste On Thu, Apr 18, 2013 at 2:58 AM, William Wu william...@citrix.com wrote: I’m wondering when setting up haproxy with “stick on src”, if the same client send 2 requests to different ports on server. i.e. 443 and 8443. Are these 2 requests going to hit same server always? Thanks, William
