Thank you, you are correct the error was this incorrect entry and it was causing all the other issues. Fixed it and everything is now working as it should Thank you for your time and patience cjb

@oguruma Disabling transparent-client-ip on haproxy would probably make it work.?. Or make haproxy use a different port on the webserver for handling its requests. (Configure the webserver to listen on 2 ports, one for direct requests :443, the other for example :1443 for haproxy's transparent requests.)

DNS is back up and download using domain name is working again. The provider let me know that had a major system upgrade yesterday.

@oguruma Besides defining ACL's have you used those acls behind use-backend 'actions'.?

@johnpoz thank you, I am a derp, but you helped me figure out what I was doing wrong.

@piba Just network error with not much to go on... but I think I got it to work :) Several small things needed to be changed. I have an external spamfilter I forgot to take into considerations so I needed a firewall rule that I disabled when testing this. After enabling that rule I get a bit further. Then I saw somewhere else where they have been struggling that the 2 settings under Certficate: Add ACL for certificate... was something to play around with and after disabling those I got further.. then I realised that my backend might be missing the SSL setting .. that fixed the last things. so right now it seems to be working. I need to do more tests but at least I can now get data through.

@planetinse Don't ask, read.. If the certificate is valid for the root domain, then its probably due to the acl's that get added, either check both boxes for checking subject/san, or uncheck them that should allow traffic to pass to the (default) backend. That is assuming you have indeed the same issue, if not, start a different topic please.

@jjanis1 said in Package update for ver. 2.4.5-Release-p1: ....ying to update my packages since I am using a VMware workstation but when I click on the system-package manager- Available Packages I get a message that states Unable to retrieve package information. This means that pfSense itself can't use the WAN (or WANs) to go outside, connect to the pfSense Package server and down the the list with available packages. I've only one advice (based on the info you've given) : go back to default settings and you'll be fine. @jjanis1 said in Package update for ver. 2.4.5-Release-p1: It also show me that there are no packages currently installed. Did you install packages before ? If yes : so it did work before ? if yes : undo what you did (recently) and thinks go back to normal. Btw VMware workstation the fact that you use a b c d e .... as a device or a VM device doesn't matter. Ones set up the "virtual hardware" it keeping on running well. Usual tests have to be executed like : cables/witches/upstream router ok etc.

@palomero as I can see from your squid.conf this is not pfSense please check the squid/distr documentation

@thewismit It might be haproxy, dns by itself shouldn't cause this error.. Unless if its pointing to a wrong/different server/(caching)proxy.. If DNS is pointing to the cloudflare 'proxy', then you need to make sure that they have the proper certificate and encryption cipher options to accept the connection from the browser.. If DNS is pointing directly to the WAN ip, then it has to be haproxy that is sending the wrong allowable ciphers. Perhaps you could try with SSLlabs to see if/what ciphers are currently shown when visiting your wanip and/or domainname.? Can you share the haproxy.cfg file perhaps? (with obfuscated ip/domain names) Can you maybe share the domainname and your public ip? Or send me a PM, maybe i can see something hinky.?.