Re: SSL termination/SNI routing
On Sun, Jan 20, 2013 at 7:55 AM, Willy Tarreau w...@1wt.eu wrote: Hi, On Sat, Jan 19, 2013 at 07:01:52PM +, shouldbe q931 wrote: It seems to have been overlooked but *** I need to have HTTPS from HAproxy to the Exchange servers, this requirement cannot be removed.*** The flow would be Internet 443 - NAT - HAproxy 443 - CAS 443 snipped for brevity server multi-5 10.201.253.65 weight 200 check port 443 inter 5000ms rise 3 fall 2 server multi-6 10.201.253.66 weight 1 check port 443 inter 5000ms rise 3 fall 2 server multi-3 192.168.53.63 backup weight 25 check port 443 inter 5000ms rise 3 fall 2 server multi-4 192.168.53.64 backup weight 10 check port 443 inter 5000ms rise 3 fall 2 You forgot to specify ssl on your server lines, so the connections are sent in clear. You seem to confuse two things : - either you want haproxy to *decipher* the SSL for you and then you need it to *cipher* it to join the server ; This is exactly what I'm after. :-) - or you want haproxy to just act as a simple TCP proxy which does not know anything about ssl. For the first option, your server lines need ssl and if the protocol is HTTP, then you'd even better use HTTP and stick on cookies rather than IP addresses. So the dumb question is, how is SSL specified for the server lines ? You simply add the ssl directive after the server name Which I've _now_ found here http://cbonte.github.com/haproxy-dconv/configuration-1.5.html#5-ssl. I had completely missed that previously, too much time spent looking for an example, not enough time reading the manual. I had started from the examples on the exceliance. blog, none of which have the ssl directive for servers For the second option, you can remove ssl everywhere but you'll lose client information when reaching the server. I hit a couple of things the option prefer-server-ciphers is not accepted, so I removed it from the config. It was removed from the config in recent versions and is always enabled by default. (...) Regards, Willy As I had said, I'd got something wrong, however it now works :-) As I've tried to do with the weights and the backup directive, this is a cascade of failovers (primary and backup in main DC, then primary and backup in DR DC) rather than balancing load, is there any advantage of using cookies instead of source IP ? Many Thanks!
Re: SSL termination/SNI routing
On Sun, Jan 20, 2013 at 12:19:02PM +, shouldbe q931 wrote: As I've tried to do with the weights and the backup directive, this is a cascade of failovers (primary and backup in main DC, then primary and backup in DR DC) rather than balancing load, is there any advantage of using cookies instead of source IP ? When you're using HTTP, clients can come from various IP addresses, especially when some xDSL load balancing is installed on their side, or when they're connecting from mobile devices. The big benefit of relying on a cookie then is that they'll provide the cookie regardless of their IP address and haproxy will be able to find the correct server all the time. Regards, Willy
Re: SSL termination/SNI routing
On Sun, Jan 20, 2013 at 12:34 PM, Willy Tarreau w...@1wt.eu wrote: On Sun, Jan 20, 2013 at 12:19:02PM +, shouldbe q931 wrote: As I've tried to do with the weights and the backup directive, this is a cascade of failovers (primary and backup in main DC, then primary and backup in DR DC) rather than balancing load, is there any advantage of using cookies instead of source IP ? When you're using HTTP, clients can come from various IP addresses, especially when some xDSL load balancing is installed on their side, or when they're connecting from mobile devices. The big benefit of relying on a cookie then is that they'll provide the cookie regardless of their IP address and haproxy will be able to find the correct server all the time. Regards, Willy I'm going to stick with IP for the moment, I get how they would be much better if I was balancing load across multiple servers, but with my use case of a failover cascade, I don;t see any advantage, however I will be doing more reading :-) After spending the time to mitigate the Beast attack on the CAS server some time ago, I found it much simpler on HAProxy. For the benefit of the rest of the list, I used the ciphers directive in the bind line with RC4:HIGH:!aNULL:!MD5 Thanks once again
Re: Failed to persist on SSL session ID
Hi, Emeric Thank you for your suggestion. There are some codes implemented for ssl session cache in haproxy indeed. But I cannot find the implementation of the option stick on ssl_session_id either in dev16 or dev17. And haproxy failed to start with 'stick on ssl_session_id' set in configuration file. The error information as below: [ALERT] 020/114500 (29257) : parsing [h-ssl.cfg:33] : 'stick': unknown fetch method 'ssl_session_id'. Best Regards, Godbach 2013/1/19 Emeric BRUN eb...@exceliance.fr: Hi, If you want to handle ssl offloading on haproxy and ssl session id persistance you should use: stick on ssl_session_id Payload_lv method is used when haproxy doesn't perform ssl offloading and load balance in tcp mode. Note: in addition, there is a lot of fixes between dev16 and dev17. Regards, Emeric original message- De: Godbach nylzhao...@gmail.com A: haproxy@formilux.org Date: Sat, 19 Jan 2013 01:47:02 +0800 - Hi, all I have tested persistence on SSL session ID of haproxy-1.5-dev16. The main configuration of frontend and backend as below: frontend fe bind 172.22.16.112:443 ssl crt /home/fortiadc/ca-user-key.pem ca-file /home/fortiadc/ca-root.cer #verify required crl-file /home/fortiadc/ca-root-crl.cer maxconn 1048576 use_backend be unless backend be balance roundrobin # maximum SSL session ID length is 32 bytes. stick-table type binary len 32 size 30k expire 30m acl clienthello req_ssl_hello_type 1 acl serverhello rep_ssl_hello_type 2 # use tcp content accepts to detects ssl client and server hello. tcp-request inspect-delay 5s tcp-request content accept if clienthello # no timeout on response inspect delay by default. tcp-response content accept if serverhello # SSL session ID (SSLID) may be present on a client or server hello. # Its length is coded on 1 byte at offset 43 and its value starts # at offset 44. # Match and learn on request if client hello. # should be (44, 32) if sticking to SSL session ID ? stick on payload_lv(43,1) if clienthello # Learn on response if server hello. # should be (44, 32) if storing SSL session ID ? stick store-response payload_lv(43,1) if serverhello server 1 10.128.7.1:80 cookie cookie weight 1 maxconn 0 slowstart 0s server 2 127.0.0.1:80 cookie cookie weight 1 maxconn 0 slowstart 0s Both the acl and stick configurations are copied from introduction of 'stick store-response' in manual. After testing, I found that haproxy has not stored SSL session ID becaused of the acl 'clienthello' has not matched. From the codes of SSL supporting, SSL_do_handshake() supplied by OpenSSL library was called to do whole SSL handshake. It means that haproxy doesn't have the chance to copy TCP payload during SSL handshake to session buffer. As a result, haproxy cannot check the data of handshake. Maybe we just check SSL hello type in SSL record data. In addition, I want to know that the main configuration should be like this if I want to stick on SSL session ID: stick on payload_lv(44,32) if clienthello stick store-response payload_lv(44,32) if serverhello I am also wondering that whether I used incorrect configuration to lead the failure or it is a bug indeed. Best Regards, Godbach
Re: Connection error on RabbitMQ consumer behind haproxy
On Sat, Jan 12, 2013 at 5:24 AM, Bryan Talbot btal...@aeriagames.comwrote: forwardfor is for http only of course. You have the client and server timeouts set to 60 seconds which means that if those tcp connections are idle for that time the connection will be closed. Maybe that's not what you intended? I need a persistent connection. Is it possible after any configuration tweaks ? Thanks -Bryan On Thu, Jan 10, 2013 at 8:20 PM, B MK bmkg...@gmail.com wrote: Hello, My rabbitmq connection dropped every minute behind haproxy. If i connected directly there was no issue. I already mailed this issue on rabbitmq mailing list. http://rabbitmq.1065348.n5.nabble.com/Connection-error-on-RabbitMQ-consumer-behind-haproxy-td24348.html . How to add this option forwardfor in tcp mode. Is it possible. [WARNING] 010/095024 (902) : config : 'option forwardfor' ignored for proxy 'rabbitmq_consumer_cluster' as it requires HTTP mode. See my haproxy configuration, global log 127.0.0.1local0 log 127.0.0.1local1 notice #log loghostlocal0 info maxconn 4096 #chroot /usr/share/haproxy user haproxy group haproxy daemon #debug #quiet defaults logglobal #modehttp #optionhttplog optiondontlognull retries3 option redispatch maxconn5000 contimeout1 clitimeout6 srvtimeout6 listen rabbitmq_producer_cluster 0.0.0.0:5672 mode tcp balance roundrobin server rabbit_1 rabbit1:5672 check inter 5000 rise 2 fall 3 server rabbit_2 rabbit2:5672 check inter 5000 rise 2 fall 3 #server rabbit_3 rabbit3:5672 check inter 5000 rise 2 fall 3 listen rabbitmq_consumer_cluster 0.0.0.0:5673 mode tcp balance roundrobin option tcpka server rabbit_1 rabbit1:5672 check inter 5000 rise 2 fall 3 server rabbit_2 rabbit2:5672 backup check inter 5000 rise 2 fall 3 #server rabbit_3 rabbit3:5672 check inter 5000 rise 2 fall 3 listen private_monitoring :8100 mode http option httplog stats enable stats uri /stats stats refresh 5s
Re: Failed to persist on SSL session ID
Ki, original message- De: Godbach nylzhao...@gmail.com A: Emeric BRUN eb...@exceliance.fr Copie à: haproxy@formilux.org Date: Mon, 21 Jan 2013 11:46:46 +0800 - Hi, Emeric Thank you for your suggestion. There are some codes implemented for ssl session cache in haproxy indeed. But I cannot find the implementation of the option stick on ssl_session_id either in dev16 or dev17. And haproxy failed to start with 'stick on ssl_session_id' set in configuration file. The error information as below: [ALERT] 020/114500 (29257) : parsing [h-ssl.cfg:33] : 'stick': unknown fetch method 'ssl_session_id'. Sorry, stick on ssl_fc_session_id Best Regards, Godbach 2013/1/19 Emeric BRUN eb...@exceliance.fr: Hi, If you want to handle ssl offloading on haproxy and ssl session id persistance you should use: stick on ssl_session_id Payload_lv method is used when haproxy doesn't perform ssl offloading and load balance in tcp mode. Note: in addition, there is a lot of fixes between dev16 and dev17. Regards, Emeric original message- De: Godbach nylzhao...@gmail.com A: haproxy@formilux.org Date: Sat, 19 Jan 2013 01:47:02 +0800 - Hi, all I have tested persistence on SSL session ID of haproxy-1.5-dev16. The main configuration of frontend and backend as below: frontend fe bind 172.22.16.112:443 ssl crt /home/fortiadc/ca-user-key.pem ca-file /home/fortiadc/ca-root.cer #verify required crl-file /home/fortiadc/ca-root-crl.cer maxconn 1048576 use_backend be unless backend be balance roundrobin # maximum SSL session ID length is 32 bytes. stick-table type binary len 32 size 30k expire 30m acl clienthello req_ssl_hello_type 1 acl serverhello rep_ssl_hello_type 2 # use tcp content accepts to detects ssl client and server hello. tcp-request inspect-delay 5s tcp-request content accept if clienthello # no timeout on response inspect delay by default. tcp-response content accept if serverhello # SSL session ID (SSLID) may be present on a client or server hello. # Its length is coded on 1 byte at offset 43 and its value starts # at offset 44. # Match and learn on request if client hello. # should be (44, 32) if sticking to SSL session ID ? stick on payload_lv(43,1) if clienthello # Learn on response if server hello. # should be (44, 32) if storing SSL session ID ? stick store-response payload_lv(43,1) if serverhello server 1 10.128.7.1:80 cookie cookie weight 1 maxconn 0 slowstart 0s server 2 127.0.0.1:80 cookie cookie weight 1 maxconn 0 slowstart 0s Both the acl and stick configurations are copied from introduction of 'stick store-response' in manual. After testing, I found that haproxy has not stored SSL session ID becaused of the acl 'clienthello' has not matched. From the codes of SSL supporting, SSL_do_handshake() supplied by OpenSSL library was called to do whole SSL handshake. It means that haproxy doesn't have the chance to copy TCP payload during SSL handshake to session buffer. As a result, haproxy cannot check the data of handshake. Maybe we just check SSL hello type in SSL record data. In addition, I want to know that the main configuration should be like this if I want to stick on SSL session ID: stick on payload_lv(44,32) if clienthello stick store-response payload_lv(44,32) if serverhello I am also wondering that whether I used incorrect configuration to lead the failure or it is a bug indeed. Best Regards, Godbach
Re: HAproxy
Hi Laurent, First of all, please avoid using HTML mail :) Second, you just need to add as many fronted/backend or listen section as you need. so just duplicate the configuration you have for server A, replace with information for server B in the same config file, reload haproxy and you're done. cheers On Mon, Jan 21, 2013 at 8:22 AM, Laurent Genari-Conti laurent.genari-co...@exterity.com wrote: Good morning, ** ** I would like to try and use the Haproxy for redundancy between multiple server. Here is my scenario: I have a server A and the redundant server A. I have a server B and the redundant server B. ** ** In the past I tried to use the HAproxy to have redundancy between Server A and the redundant server A. It worked perfectly. I’d like from the same HAproxy server to also manage the redundancy between my server Bs. Is it possible? Do I need to run multiple instances of the HAproxy? ** ** Thanks a lot in advance. Laurent. ** ** ** ** ** *Laurent Genari-Conti* | Support Engineer | *Exterity Ltd* tel: +971 (4) 4470602 | fax: +971 (4) 4470609 e: laurent.genari-co...@exterity.com | w: www.exterity.com http://www.exterity.com/aboutexterity/events/ise.html Follow Exterity... http://www.twitter.com/exterity http://www.facebook.com/pages/Exterity/106159572757779?ref=emailfooter http://www.linkedin.com/company/exterity Exterity design and manufacture IPTV products for the corporate, education and hospitality markets. These products can revolutionise communications within your organisation, improving staff training, creating a professional image and broadcasting live television across your computer network to anyone who needs it. For more information or a product demonstration contact Exterity on +44(0)1383 828 265 or visit www.exterity.com *Legal Notice* Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. Exterity Limited is registered in Scotland under No. 225313 with its registered office at Ridge Way, Hillend Industrial Park, Dalgety Bay, KY11 9JD. ** ** image002.gifimage003.gifimage004.gifimage001.gif
