@piba It seems related to certificates, but, the whole system is acting weird, again related to certificates. I checked if they're OK and they are. I reinstalled the CAs and, issued new certificates and it still wouldn't work.

Apart from that, system 2.4.4 starts to slow down and starts losing packets, I see tons of red and black from retransmissions in captures. I don't know how to make sense of packet captures myself, but, I know that's not supposed to happen on a working network. What I do to correct is not reinstall the system, but not using the console but actually deleting the disk and reinstalling from scratch. Restoring to factory won't fix issues; I found some commands, though, that apparently are just for that but they aren't for system 2.4.4. Modifying them a little go them working and the system seemed alright again, after restoring a backup back from September I just needed to delete an VPN interface before testing again HAProxy, and when I did the system hung again. So, after all this, it seems very likely HAProxy isn't the culprit but until I get a working stable system and back the hell out of it, I can't test again. :/

Before 2.4.4 I could change and change and change stuff and it would route on for months, no biggie, but now it appears that changes affect something, maybe a database or something. "Storage!" I thought, maybe some disk-access/speed or file system issue, but the disk is local, flash-based, the system has plenty memory and I've gone back and forth between the ultra-resilient ZFS and U..HF..--something, the old one, and it doesn't seem to make a difference.

Sorry for the missing details, though. I'll keep testing.

I have known where is my problem
the Squid package is broken
after uninstall and reinstall the package
the cache started to work

Thanks for the response. I've been messing around with it a bit more this-morning and think I figured it out. I set everything up a year or so ago and forgot a lot of how I did it. I have haproxy listening to 443 then taking some SNI's and sending them to the auth sub-proxy area and others getting sent to the regular ssl (unauth) sub-proxy frontend place. In the sub-proxy front-ends, I have one listening to say :2044 and had shared frontends clicked. In that subsection, I had the redirection to the backend.

I resolved it by getting rid of the :2044 shared frontend and using a custom acl backend set to "ssl_fc_sni_reg myth.<name>".

I think my problem was I had a shared frontend setup, for whatever reason, and now it's working fine. I'm no haproxy expert; just a beginner, but I hope this may shed some light into somebody else's problem.

Thanks for the response! So is there any way to do URL filtering in pfSense and then NAT traffic to multiple public IP addresses?

@piba said in Proxy HA slow redirect https to http - [ miragration vm with different subnet ]:

haproxy upgrade from 1.8.13 to 1.8.14.

@PiBa

According to Pieter response, the case was resolved after the haproxy upgrade from 1.8.13 to 1.8.14.

@thanhlangso
may i ask what was the solution because i need something similar to whats app

Hi PiBa, and thanks for the response. Would you believe, I have just managed to get it going. Interesting one, IIS site was missing a binding for that particular host header. Strange that it didn't work considering that it's the only site on that server and it was listening on the right port, etc, but it has made the difference to it! Lesson learned!

thanks a lot. Will go through that documentation and try it out.

@jimp said in Lightsquid not removed properly, I think....:

Install lightsquid again and then uninstall it, which should remove its service tags

Thank you! That worked.....

Captive Portal authentication has been migrated to the user manager in 2.4.4. That option probably no longer makes sense.

@hexine
The issue is likely caused by a somewhat messed up configuration somewhere. Do you have a configuration backup from before the upgrade when haproxy was still working? I wonder what the <haproxy> part of that configuration looks like..
As currently it looks like the frontend with name A and description A and without address is kinda 'broken', you could perhaps delete it and configured it fresh.?

p.s. i can make the PHP 'not' throw an error on it with a few minor changes, but still it wouldn't 'properly' work..

diff --git a/net/pfSense-pkg-haproxy-devel/files/usr/local/www/haproxy/haproxy_listeners.php b/net/pfSense-pkg-haproxy-devel/files/usr/local/www/haproxy/haproxy_listeners.php index 859ba65697cb..275b318ce75d 100644 --- a/net/pfSense-pkg-haproxy-devel/files/usr/local/www/haproxy/haproxy_listeners.php +++ b/net/pfSense-pkg-haproxy-devel/files/usr/local/www/haproxy/haproxy_listeners.php @@ -256,6 +256,7 @@ function js_callback(req) { $a_frontend_grouped = array(); foreach($a_frontend as &$frontend2) { + getarraybyref($frontend2); $mainfrontend = get_primaryfrontend($frontend2); $mainname = $mainfrontend['name']; $ipport = get_frontend_ipport($frontend2, true);

Hum, you're on to something here! The gitlab server does not use SSL in the background, so I shouldn't have it there but I disabled SSL encryption and enabled SSL checks on the WAN_HTTPS backend and that seems to have done the trick!

Sweet bananas, huge thanks!