RE: HAProxy and site failover

[Lukas Tribus]

 i am wondering if the ability exists in HAProxy to reply to a HTTP proxy
 request with a reset (RST) if no backend server is available.

 the scenario goes as such:
 i have a proxy pac file that assigns multiple proxies to all clients,
 and through the logic tree in the pac file, the proxies are assigned in
 a specific order. i have multiple sites with load balanced proxies, and
 the intention is to provide site failover, should a larger event occur
 like ISP issues that breaks internet access. with the pac file
 assigning all proxy VIPs to the client, should the default VIP not have
 an available backend server to fulfill the request, i would want to
 configure HAProxy to send a reset to the client, indicating that the
 next assigned proxy should be used.

HAProxy is not a forward proxy to begin with. As to your question,
no, I don't see how this would be possible without an external
helper (checking backend statuses and installing specific iptables
rules).


Lukas

  

RE: sticky sessions with tcp mode

[Lukas Tribus]

 I am having some issues with sticky sessions. The sessions are not sticking. 
  
 I am using tcp mode with ssl. I have implemented the example out of the  
 manual. 
 The user is getting bounced back and forth between the two servers,  
 which is causing issues in the application. 
 Am I missing something?

Probably because TLS tickets are used instead of the SSL session ID. Either
disable TLS tickets on your backend or use some other stickiness methods,
like source ip stickiness.


Lukas

  

RE: HAProxy and site failover

[Lukas Tribus]

 haproxy is a tcp (layer 3/4) proxy, that can perform application (layer
 7) functions. i am already doing service checks against my proxies to
 validate their availability. when no pool member is available, haproxy
 knows it. there are no external helpers needed to make this
 determination. the layer 7 capabilities make this possible.

 the injection of a RST is part-and-parcel to the tcp proxy
 functionality. i can understand if the functionality in not in haproxy,
 but it is not outside the realm of capability for a t.

The 3 way TCP handshake happens before the application (haproxy) is even
aware of the session, therefor this is only possible if the kernel handles
it (iptables), which is why I said its only possible with external helpers.

Or is what you are requesting to send a RST in the middle of an already
established TCP session?


Please CC the mailing list.


Lukas

  

Re: HAProxy and site failover

[Brendan Kearney]

On Sat, 2015-03-21 at 14:03 +0100, Lukas Tribus wrote:
  haproxy is a tcp (layer 3/4) proxy, that can perform application (layer
  7) functions. i am already doing service checks against my proxies to
  validate their availability. when no pool member is available, haproxy
  knows it. there are no external helpers needed to make this
  determination. the layer 7 capabilities make this possible.
 
  the injection of a RST is part-and-parcel to the tcp proxy
  functionality. i can understand if the functionality in not in haproxy,
  but it is not outside the realm of capability for a t.
 
 The 3 way TCP handshake happens before the application (haproxy) is even
 aware of the session, therefor this is only possible if the kernel handles
 it (iptables), which is why I said its only possible with external helpers.
 
 Or is what you are requesting to send a RST in the middle of an already
 established TCP session?
 
 
 Please CC the mailing list.
 
 
 Lukas
 
 

sorry, thought i did cc the list.

i will have to test out the behavior, as this is an implemented solution
where i work, using other products.  i can test a couple of different
scenarios that come to mind.

1, new browser session comes in to the load balancer, and no backend
servers are available.  where / when is the RST sent?

2, a session to the load balanced exists, and the backend servers become
unavailable.  where / when is the RST sent?

i'll run these scenarios and let you know what i find in a packet
capture.

Re: HAProxy with multiple certificates, one of which being wild card, and the other being sub of that wildcard

[Peter BUtler]

forgot to CC the mailing list.


thanks Cryil.
 

 Date: Fri, 20 Mar 2015 00:47:53 +0100
 From: cyril.bo...@free.fr
 To: peter_butler1...@outlook.com; haproxy@formilux.org
 Subject: Re: HAProxy with multiple certificates, one of which being wild 
 card, and the other being sub of that wildcard
 
 Hi Peter,
 
 Le 20/03/2015 00:32, Peter Butler a écrit :
  I logged this on stackoverflow
  (http://stackoverflow.com/questions/29133477/haproxy-with-multiple-certificates-one-of-which-being-wild-card-and-the-other),
  but HAProxy usage there is pretty low.
 
  THis is my first mailing list email in years, please let me know if I
  have broken any rules.
 
 
  I have HAProxy working pretty well, I have port 80 and 443 open, TCP
  over 443 over a internal proxy. HTTPS end to end. I am serving
  certificates: *.mycompany.com.au www.secure.mycompany.com.au
  SNI does not seem to be working, as when I go to
  secure.mycompany.com.au, I keep getting the www.secure.mycompany.com.au
  certificate (and weirdly *most* browsers do not throw a error). But when
  I go to mail.mycompany.com.au I get the *.mycompany.com.au certificate
  correctly.
 
 Indeed, keep in mind that a wildcard certificate works only for 
 subdomains, not sub-subdomains.

this is fine, and as mentioned its working great for my other wild card certs, 
but the difference is they do not have a 
specific.sub-which-is-the-same-as-a-wildcard.mycompany.com.au 

(am I believe the blod part is my issue here.


 
 So www.secure.mycompany.com.au won't match the *.mycompany.com.au 
 wildcard certificate. As no certificate matches the hostname, the first 
 one loaded is applied. I guess that in your SSL directory, the 
 certificate file for secure.mycompany.com.au is listed first.


I have tried this change already, by renaming them alphabetically.  Didn't make 
any difference.


 
 You can read the RFC 2818, chapter 3.1. Server Identity for more details :
 http://tools.ietf.org/html/rfc2818#section-3.1
 

I think my issue is here, from your link:
E.g., *.a.com matches foo.a.com but not bar.foo.a.com

In my case I have a cert for both:
*.a.com.au
and
bar.foo.a.com.au




 
  If I remove the www.secure.mycompany.com.au cert from the SSL directory,
  and I browse to secure.mycompany.com.au I get the correct certificate,
  but of course when I go to www.secure.mycompany.com.au, I get a error on
  the browser, as it tries to give me *.mycompany.com.au certificate.
 
 It tends to confirm this : the wildcard still doesn't match, and the 
 first certificate is applied (which in this case is by chance the 
 wildcard). I you insert a fake certificate before the wildcard, I'm sure 
 it will be this one that will match.
 
  Can anyone see what I am doing wrong please.
 
  |By the way, I also have a *.abc.def.mycompany.com.au and 
  *.def.mycompany.com.au in this same config (removed from below, but in same 
  syntax). and they are working perfect.|
 
  ||
 
  |haproxy -version
  HA-Proxy version 1.5.8 2014/10/31
  Copyright 2000-2014 Willy Tarreau w...@1wt.eu
 
 
 
 
  ##|
 
  |##|
 
  |##
  global
  daemon
  user haproxy
  group haproxy
  log /dev/log local0 info
  log /dev/log local0 notice
  ulimit-n 2
  pidfile /var/run/haproxy.pid
  tune.ssl.default-dh-param 2048
 
  ##
 
  ## Port80 is open only to forward all requests to port 443.
  frontend unsecure 123.123.123.155:80 #Prod
  bind 192.168.14.155:80 #Prod
  mode http
  redirect scheme https code 301 if !{ ssl_fc }
 
  ##
 
  ##Listen on 443, and forward to internal proxy on 88. Needed for SSL end to 
  end.
  listen ssl-proxy
  ##Only accept mycompany host headers
  http-request deny if !{ hdr_end(Host) -i mycompany.com.au } !{ 
  hdr_end(Host) -i www.secure.mycompany.com.au }
 
  # Get Certificates from SSL directory.
  bind 123.123.123.155:443 ssl crt /etc/haproxy/ssl npn http/1.1 ciphers 
  ECDHE-RSA-AES256-SHA:RC4-SHA:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM no-sslv3
  bind 192.168.14.155:443 ssl crt /etc/haproxy/ssl npn http/1.1 ciphers 
  ECDHE-RSA-AES256-SHA:RC4-SHA:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM no-sslv3
 
  mode tcp
  server http 127.0.0.1:88 send-proxy
 
  ##
 
  frontend internal_proxy
  mode http
  bind 127.0.0.1:88 accept-proxy name accept-sslproxy
  bind-process 1
 
  acl is_secure_mycompany_com_au hdr_end(host) -i www.secure.mycompany.com.au
  acl is_secure_mycompany_com_au hdr_end(host) -i secure.mycompany.com.au
  use_backend https_secure_mycompany_com_au if is_secure_mycompany_com_au
 
  acl is_mail_mycompany_com_au