@ben-ihelputech Many thanks, that was quite helpful.

@jonathanlee Thanks a lot

@dobby_ Thanks a lot, I am going to try.

@michele-trotta Hi everyone , sorry for the delay, but the problem has been solved. When the citrix workspace web app is launched it is asked to open a new page with microsodt EDGE. When "Open APP" is confirmed, a file with the ICA extension is downloaded. In this file there is a parameter that identifies an internal proxy that citrix will use. Now once this value has been discovered, it must be included in our Squid and the game is done!!!! Good job everyone Michele

@viragomann I have one interface for LAN, other for VLANs.

@swemattias said in HAProxy Nextcloud WebDAV URL Discovery: the second part is not able to be saved due to that I have a http redirect already http to https. Possibly you did that wrong? Did you limit the respective ACL to non-HTTPS Traffic?

@gerdesj said in HAProxy use_backend multiple ACLs: S Haha. That did it. So essentially you don't need any ACLs to help with websockets when using HAProxy. Fantastic. Thanks for the help.

@jonathanlee SquidGuard "General settings TAB" For automatic loading this option here must be activated as if I was not getting it wrong. [image: 1682052827901-squidguard.jpg] SquidGuard "Blacklist TAB" And this should be for manual loading that lists but multiple of them (one after one). Links keep stored for the next "run". [image: 1682053079533-squidguard-2.jpg]

@soheil-amiri by increasing retry option on my client application, problem solved.

@jsiegfried I don’t see any notification from HA Proxy about that CVE. They haven’t addressed it or spoken about it at least on their blog. The CVE score is pretty low compared to the other one tho. https://www.cvedetails.com/cve/CVE-2023-0056/

@karimhaydar31 said in connection is not private when using Chrome: X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN The certificate is valid, but not co-signed by one of the major players, like Verisign etc. see here for a list. The thing is, your browser only accepts (and stays silent) certificates if they were co or toot signed by one of the authorities that are on 'the list' (in your device). You could actually empty this list, and your browser would not even trust https://www.micirostf.com any more. So, the easiest thing to do, is : export the certificate that is being used by the Webconfigurator, and import it into you browser / OS. Now, your browser / OS it trust it, and no more errors. That's all it takes ! You could also get your hands on a certificate that is trusted out of the box. A trusted certificate is free. Example : if these are your general settings : [image: 1681197872695-5f251b0a-5c89-4ab6-aec6-556829c21c72-image.png] and you actually own, or rent the some-domain.tld domain name, you could obtain certificate for *.some-domain.tld for free. The pfSense package "acme" is all about that functionality. Again : the certificate will be free, the domain name will cost some money.

@michmoor I think clam AV has it as a false positive.

@michmoor This was solved on my end. Was an issue with the backend server domain-name vs. hostname configured.

@jonathan-young you need a redirection rule - http-request redirect along with a conditional i think would help. http-request redirect location def-test.example.com code 302 if { hdr(host) -i abc-test.example.com

Try setting a file extension in the field there even if you're not using that.