@viragomann Damn i completely forgot that i could use the current LAN CARP i have..!! Yeah that works for me !! Thank you very much !!!

@pradeep-sl Check if the backend is shown up as online on the FS stats page.

@aGeekhere said in Unofficial Squid Custom Refresh Patterns: https://github.com/mmd123/squid-cache-dynamic_refresh-list I added them thanks.

@viragomann "Host Matches" in my Case works only when also setting to "use defaults"

I was able to solve the issue by shifting the redirect rules for phpmyadmin to the frontend instead of trying to path it out on the backend. This resolved the issue for me. Front End [image: 1749176745146-e80ffba8-07fd-4520-8b54-abf5e3bdff8e-image.png] [image: 1749177376791-dd4aa560-b111-4f7a-8489-ef46975a5039-image.png] Since the pathing now happens in the front end, I was able to clean up the backend and it's just a simple passthrough in the case of phpmyadmin. Hopefully, this helps someone else out too. There's probably a more elegant way to solve this, but it did the trick for me.

@jonny190 said in ACL with multi Action: in to one rule, i can get the first line in just not the seccond So add a second one. The original config has also two rule for what you want. BTW: the original rule looks a bit different than yours. It seems, to also replace the last octet of the IP.

@anemacuore 2.8.0 is work (update)

@aniodon Apologies for the necro posting. How would you apply such a patch ? https://github.com/pfsense/FreeBSD-ports/commit/476a7d0e3dca704b236839970f1d215912184f73 I've created a system patch via pfsense GUI with the commit mentioned in this thread, however, it does not apply to my squid config, It seems that it is not recognizing the file to update (?) Here's what I'm getting in the debug log (not having changed default patch settings): /usr/bin/patch --directory='/' -t --strip '2' -i '/var/patches/682f24bdbc39f.patch' --check --forward --ignore-whitespace Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |From 476a7d0e3dca704b236839970f1d215912184f73 Mon Sep 17 00:00:00 2001 |From: Marcos Mendoza <mmendoza@netgate.com> |Date: Tue, 26 Nov 2024 18:36:53 -0600 |Subject: [PATCH] www/pfSense-pkg-squid: remove duplicate option | |--- | www/pfSense-pkg-squid/files/usr/local/pkg/squid.inc | 1 - | 1 file changed, 1 deletion(-) | |diff --git a/www/pfSense-pkg-squid/files/usr/local/pkg/squid.inc b/www/pfSense-pkg-squid/files/usr/local/pkg/squid.inc |index 719cda2fb3cf..129b8b05335c 100644 |--- a/www/pfSense-pkg-squid/files/usr/local/pkg/squid.inc |+++ b/www/pfSense-pkg-squid/files/usr/local/pkg/squid.inc -------------------------- No file to patch. Skipping... Hunk #1 ignored at 1236. 1 out of 1 hunks ignored while patching pfSense-pkg-squid/files/usr/local/pkg/squid.inc done

Got damn, there are one unused backend in HAproxy package configuration! How I miss it?… After delete AND cold pfSense-based server restart - error not appear at all.

Did'nt you forget the ACL? The action will never be triggered...?!

Bumping this as I am experiencing the exact same issue with the exact same behavior. I have even tried putting a transparent bypass for 127.0.0.1 as the source and destination, the hostname of the firewall, and the firewall's own public address as a source with no success.

@sensewolf said in Can't protect certain path only with client certificate: -- The expected outcome is that in order to access the specific path, a client certificate is required. Surprisingly, however, the path becomes publicly accessible again without the client certificate -- I don't understand why this doesn't work. The setup is basically the same as for my other accessible and protected domains with the only difference that in this case only a certain path should be protected. Did you put this rule to the top, so that it is probed and executed before the other one? For testing the ACLs just use a simple rule, which give a clear result like "http request deny". Why isn't this working? What am I missing? Maybe someone will see it if you post the whole configuration.

Hi there, Thanks for the detailed explanation—this is a good catch. Your suspicion is right: this issue isn’t caused by pfSense or HAProxy, but by the web server behind Nextcloud (likely Apache or Nginx) not serving .mjs files with the correct MIME type. HAProxy simply acts as a reverse proxy and does not handle or modify MIME types. It forwards the request to your backend server (10.0.24.10:3334 in this case), which is responsible for serving static content like .mjs files. To fix it: For Nginx, modify mime.types to include: application/javascript js mjs; For Apache, add: AddType application/javascript .mjs Once this change is in place, the viewer and other JS modules should load properly through HAProxy. As a side note, if you're ever doing advanced tasks like proxy rotation for web scraping or external API access, that’s something HAProxy can help with—but it doesn’t apply here. Let me know if you'd like help locating your web server config!

@sensewolf All of the applications I have that run websockets use the same port, so I do not create separate backends for them and it works fine. If your application does use separate ports then you will need to create a separate backend. I'm not sure how common this is, but I have I think 5 domains with websockets and none of them use a separate port.