[Solved] Warnung vor Update HA Proxy 0.59_2

nonick

Seitdem heutigen Update des HA Proxy auf Version 0.59_2 geht nichts mehr. Das SNI scheint kaputt zu sein.

oder

Leider war ich diesmal zu schnell und es hat mich erwischt. Da ich nicht weiß wie schnell das gefixt wird, hat jemand eine Idee wie ich die Vorgängerversion 0.54_2 wieder herstellen kann?

LAVenetz

@nonick hallo, leider ist mir das auch passiert! Bei mir sind 6 Websites blockiert Ich habe noch einen alten pfSense mit 2.3.5-RELEASE-p2 (i386), da ist aber die Version 0.54_2 installiert (32-bit version). Ich weiss nicht, ob ich die benutzen kann.

nonick

@LAVenetz

Ich habe es geschafft die HA Proxy Version 0.54_2 zu installieren. :)
Ich habe die aktuelle Version deinstalliert und anschließend auf der Kommandozeile folgende Abhängigkeiten installiert:

pkg add http://files00.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/lua53-5.3.4_1.txz
pkg add http://files00.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/haproxy-1.7.10.txz

und anschließend dann die Version 0.54_2

pkg add http://files00.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/pfSense-pkg-haproxy-0.54_2.txz

Jetzt bin ich am testen ob alles wieder funktioniert.

LG, Micha

LAVenetz

@nonick Super, Micha, werde ich auf dem Testsystem auch probieren. Kann ich mich auf dein Resultat verlassen?

LAVenetz

@lavenetz hallo Micha, denke, dass ich den Fehler gefunden habe: Check die Box im HAProxy => Frontend => neben Port 443 => Encrypt (SSL). Ob man die Box SSL Checks auch anklicken muss, muss ichn noch ausprobieren. Auf alle Fälle gehts es bei mir wieder mit Paket haproxy 0.59_2

nonick

@lavenetz Danke!!!

Nach dem Downgrade auf Version 0.54_2 ging es bei mir immer noch nicht. Ich habe die Konfig mehrfach geprüft, aber ich habe die Einstellung immer übersehen. Es war tatsächlich so, dass der Haken bei Encrypt (SSL) im Backend durch die aktuelle Version nicht mehr gesetzt war!

Ich musste doch den Downgrade auf Version 0.54_2 belassen, da eine Webseite mit mehreren SAN im Zertifikat nicht ging. Es ist doch was mit der SNI in der neuen Version kaputt.

PiBa

@nonick
Sorry, should get fixed soon by: https://github.com/pfsense/FreeBSD-ports/pull/542 . haproxy-devel package does not seem affected though it has the same code..
Please let me know if 0.59_4 indeed is working properly again.

LAVenetz

@piba hi I've checked also newest haproxy 0.59_4 on my main pfSense (normally I don't do this), but it also did not work, same as 0.59_2. I did the same workaround like Micha (many thnks):

deinstallation of current version
pkg add http://files00.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/lua53-5.3.4_1.txz
pkg add http://files00.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/haproxy-1.7.10.txz
pkg add http://files00.netgate.com/pfSense_v2_4_2_amd64-pfSense_v2_4_2/All/pfSense-pkg-haproxy-0.54_2.txz
check box Encrypt (SSL) in HAProxy Frontend(s) and ev. reboot
check HTTPS and/or HSTS with
6 a) https://www.ssllabs.com/ssltest/analyze.html?d=www.xxx.yy (should be at least a green A+)
6 b) https://www.sslshopper.com/ssl-checker.html#hostname=www.xxx.yy (all should be green)

Regards, LAV, sorry about my English!

PiBa

@LAVenetz,
I'm not following exactly what does/doesn't work for the setup you have.
What does 0.59_4 (not) do?

Are you using https offloading? With certificates loaded on pfSense/haproxy?
Are you using multiple certificates on a (shared?)frontend?
Are you using ssl on the webserver?
Can you check the haproxy backend server ssl settings, for example dont double-encrypt, but do perform checks with ssl, if your using TCP and https on the backend..
Check that servers are 'up' in the haproxy stats page

nonick

Hello PiBa,

I am back to version 0.54_2 because the new version 0.59_4 does not work for part of my config.

Here is an excerpt from the config that no longer works with the new version 0.59_4.

frontend Nextcloud-HTTPS
	bind			92.50.99.156:28443 name 92.50.99.156:28443 
	mode			tcp
	log			global
	timeout client		30000
	tcp-request inspect-delay	5s
	acl			NextcloudSNI	req.ssl_sni -i cloud.domain.tld
	acl			OfficeSNI	req.ssl_sni -i office.domain.tld
	tcp-request content accept if { req.ssl_hello_type 1 }

	use_backend Backend-Nextcloud_https_ipvANY  if  NextcloudSNI 
	use_backend Backend-Nextcloud_https_ipvANY  if  OfficeSNI 


backend Backend-Nextcloud_https_ipvANY
	mode			tcp
	log			global
	timeout connect		30000
	timeout server		30000
	retries			3
	option			httpchk OPTIONS / HTTP/1.0\r\nHost:\ cloud.domain.tld:28443\r\nAccept:\ */*
	server			Nextcloud 192.168.200.1:28443 check-ssl check inter 1000  verify none

Webconsole Frontend

On the web server Nextcloud 192.168.200.1:28443 runs Apache with 2 virtual hosts, cloud.domain.tld and office.domain.tld.

Webconsole Backend

With the new version one can not call the website, in Firefox the message error code: ssl_error_rx_record_too_long, in Chrome ERR_SSL_PROTOCOL_ERROR.

The health check is ok.

The same applies to the current version haproxy-devel-0.59_3, version haproxy-devel-0.55_2 worked perfectly.

PiBa

Seems your screenshots are not from 0.59_2 nor 0.59_4 version.?

It should have extra checkbox options on both the acl and the server..
Using 0.59_4 with SNI acl's seems to work fine here, make sure to check the server ssl settings though.:
Frontend:
0_1532818474973_2018-07-29 00_53_04-Window.png
Backend:
1_1532818474981_2018-07-29 00_53_31-Window.png

nonick

@piba

Hello PiBa,
my screenshot are from version haproxy-devel-0.55_2.

The error was with me in the settings in the backend. Why not Encrypt (SSL) for SSL but SSL checks? The name is confusing.

Thank you for your help, think it will help others too.

PiBa

@nonick
Well the mode is ssl/https which from haproxy's perspective is 'mode tcp' with SNI acl's. So no certificates loaded for the frontend of haproxy. The webservers are using port :443 and do have the certificates configured. (well any port like your 28443 would work, but 443 is the default )

Encrypt(SSL)
A client is sending SSL enrypted traffic, haproxy does not decrypt that traffic(there are no certificates configured on the frontend), and when forwarding the already encrypted traffic to the webserver, it should not re-encrypt the request send to the webserver. (Otherwise the http request would be wrapped in 2 layers of ssl encryption.) As such this option must NOT be checked.
SSL Checks
When the healthcheck of haproxy needs to send a "GET /status HTTP/1.1" request that request has to be encrypted with SSL otherwise the webserver will not understand the plain http request. As such this option must be checked.

Does that make it more clear?

nonick

@piba
Perfect! Now I understand that.
Thank you for your explanation. A note about it in the configuration menu would be nice.