@comet424 I forgot to mention that the best source for information on pfSense is in the book written by the experts. Recently it has been made free to the public. Even when it was not free, it was worth every penny. https://www.netgate.com/docs/pfsense/book/ Good luck Raffi

If the proxy is in a DMZ separate from the clients then it's easy to do with NAT. port forward in on LAN for a destination of any, port 80, sent to a target of the proxy on the proxy port Repeat for 443 if you're doing SSL Maybe exclude the firewall from that, and local things, but that's the general gist. That's all the squid package does internally, just forwards to 127.0.0.1 instead of another box. If the proxy is in the same subnet as the clients then it's trickier since you'd have to exclude the proxy box as a source in that rule, and work around other issues to mask the source, so don't do that.

@piba haha, i think i have to learn more about acls before asking questions ^^ Thank for your help

I found a solution, but I want to share it for people with the same problem. I could reproduce it by doing the update on the other machine and saving the logfile. The following happens: >>> Upgrading pfSense-pkg-haproxy... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: haproxy17: 1.7.11_1 [pfSense] Installed packages to be UPGRADED: pfSense-pkg-haproxy: 0.59_11 -> 0.59_14 [pfSense] Number of packages to be installed: 1 Number of packages to be upgraded: 1 The process will require 2 MiB more space. 650 KiB to be downloaded. [1/2] Fetching pfSense-pkg-haproxy-0.59_14.txz: .......... done [2/2] Fetching haproxy17-1.7.11_1.txz: .......... done Checking integrity... done (1 conflicting) - haproxy17-1.7.11_1 [pfSense] conflicts with haproxy-1.7.11 [installed] on /usr/local/man/man1/haproxy.1.gz Checking integrity... done (0 conflicting) Conflicts with the existing packages have been found. One more solver iteration is needed to resolve them. The following 4 package(s) will be affected (of 0 checked): New packages to be INSTALLED: haproxy17: 1.7.11_1 [pfSense] Installed packages to be UPGRADED: pfSense-pkg-haproxy: 0.59_11 -> 0.59_14 [pfSense] Number of packages to be installed: 1 Number of packages to be upgraded: 1 The process will require 2 MiB more space. Fetching haproxy-1.8.14.txz: .......... done [1/4] Deinstalling haproxy-1.7.11... [1/4] Deleting files for haproxy-1.7.11: ........ done [2/4] Installing haproxy17-1.7.11_1... [2/4] Extracting haproxy17-1.7.11_1: ........ done [2/4] Installing haproxy-1.8.14... pkg-static: haproxy-1.8.14 conflicts with haproxy17-1.7.11_1 (installs files into the same place). Problematic file: /usr/local/man/man1/haproxy.1.gz ignored by forced mode pkg-static: haproxy-1.8.14 conflicts with haproxy17-1.7.11_1 (installs files into the same place). Problematic file: /usr/local/sbin/halog ignored by forced mode pkg-static: haproxy-1.8.14 conflicts with haproxy17-1.7.11_1 (installs files into the same place). Problematic file: /usr/local/sbin/haproxy ignored by forced mode pkg-static: haproxy-1.8.14 conflicts with haproxy17-1.7.11_1 (installs files into the same place). Problematic file: /usr/local/etc/rc.d/haproxy ignored by forced mode [2/4] Extracting haproxy-1.8.14: ........ done [3/4] Upgrading pfSense-pkg-haproxy from 0.59_11 to 0.59_14... [3/4] Extracting pfSense-pkg-haproxy-0.59_14: .......... done Removing haproxy components... Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Syslog entries... done. Saving updated package information... overwrite! Loading package configuration... done. Configuring package components... Loading package instructions... Custom commands... Executing custom_php_install_command()...done. Menu items... done. Services... done. Writing configuration... done. >>> Cleaning up cache... done. Success For any reason haproxy-1.8.14 is installed over the haproxy-1.7.11_1 including the binary. Solution: Per console I did: pkg remove haproxy-1.8.14 pkg remove haproxy17-1.7.11_1 pkg install pfSense-pkg-haproxy-0.59_14 So only 1.7.11_1 was installed, the complete configuration remained untouched (although I took a backup before). Regards, Daniel

@ismael-segovia Looks like smth similar to - https://forum.netgate.com/topic/113490/squid-and-squidguard-are-not-starting/12

@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.