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

Did you manage to get it working as I am doing the same thing but have noticed Cloudflare Proxied traffic seems to really be slow......not sure if there is something in Cloudflare that needs tweaking but it is pretty much unusable

@viragomann said in Nextcloud und SSL über pfSense Configurieren: https://<WAN IP> Sooo Fehler gefunden, es waren die IPv6 Einträge, gelöscht und es funktioniert! Über DSL von Zuhause konnten alle anfragen Aufgelöst werden, über bein Test gerät welches über Mobiele Daten ging nicht... da dieses vermutlich IPv6 genutzt hatte. Besten Danke für die unterstützung

@ngr2001 I don’t know try the directive to see it if works, I do not have that crypto chip

@tiago-duarte squid + pfSense plus

Wow, I am some glad I finally found this. I've been racking my brain on it since December, and holding off upgrading 2 production instances of pfSense to 24.11 as I thought the problem was related to 24.11, and not MIM. I'll now be able to do the upgrades on those 4 other units(2x HA pairs in remote datacenter sites).

CPU and memory all good. This is a brand new install. Why would I need to rebuild the cache?

@JonathanLee Hi, running Pfsense CE 2.7.2 Squid 6.3. Make sense what you mention, will be cool to have this feature available. Thanks @JonathanLee

The options are still valid; they just can't have spaces between them otherwise it tries to interpret them is new switches.

As far as I can tell the pfSense HAProxy SSL backend checks do not work and are bugged, at least for backend devices that have a self signed cert. I've tried everything and always resort back to doing basic checks.

@mr-elamin2 said in WordPress behind HAProxy: $_SERVER['HTTPS']='on'; define('WP_HOME','http://mysite.com'); define('WP_SITEURL','http://mysite.com'); Failed for me, but for WP 6.7.2, I added this to the top of the wp-config.php to make it work: define('FORCE_SSL_ADMIN', false); if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) $_SERVER['HTTPS']='on'; define('WP_HOME','http://sitename.com'); define('WP_SITEURL','http://sitename.com');

@melnyk sprunki 2 It's great to hear that a simple reboot resolved your issue! If you encounter similar problems in the future, these steps may help you troubleshoot effectively.

@peterweissdk said in Parsing host header through HAProxy to backend: drift hunters I'm running a k8s cluster with traefik v3 installed to loadballance my services. I'm using traefik's ingressroute to route e.g. http request to my services, using the hostname as a match for the service. When i use local dns (inside my lan) to resolve the hostname, i can reach the service in the cluster, so traefik and the service is working just fine. For the record I'm query http (80) inside my lan, and ssl off-loading everything in HAProxy running as a package in pfsense. When makin a query from outside the lan, i use cloudflare as DNS-provider, and ACME in pfsense to handle my certificates. When i query the DNS from outside my lan using https, and the query resolves to my router running pfsense, the query hangs, and I can't reach my sevice at the k8s cluster. If i have a service with a internal ip-address, everything works fine. I can resolve the DNS name, the HAProxy frontend ssl-offloads and filter the domaine names using ACL, and sending the trafic to the corresponding backends, and i have a secure connection from my browser with a valid let's encrypt certificate. So my theory is, that the domaine name (host header) is not sent through to the backend service, and thats why the Traefik proxy in the k8s cluster, can not match the domaine name. I have tried to set in: HAProxy - frontend - actions: http-request header set Conditon acl names: <backend_service> name: Host fmt: <the_domaine_name> But that did not work.... Any suggestions ? Make sure that the HAProxy configuration correctly forwards the Host header to your backend. You mentioned trying to set the Host header using an action, but it's crucial that this configuration is correctly applie.