After reading related articles and trying to uninstall..reinstall the package. There was still no joy in getting the package to run. The problems started on 06/01/18 after an update. I tried to delete the /usr/local/etc/squid dir and that didn't work either. What did work, was to recover the system to a date before the update. The packages were reloaded and ta-da the squid cache came back to life. Should of tried the easy button first. Looking back on what I read, there was mention of the CA certificate having a problem and needed to be rebuilt. According to my effective dates it was good for several more years. So, I have no clue as to what went south. Really gives reason to backup often and certainly before any upgrade.

You will not get anything to work properly when running a version that outdated. Remove all packages. Backup config.xml. Reinstall with 2.4.3. Restore configuration. Reinstall packages. If your hardware is i386 and won't take 2.4.3, at least install 2.3.5.

Yes @jimp, we're using HAProxy to run websites and offloading SSLs over there. We use "redirect scheme https code 301 if !{ ssl_fc }" code in Advanced pass thru option in frontend to redirect the requests from port 80 to port 443. The site was running in Windows Server 2012 R2 IIS before, so recently we migrated those sites to pfsense for advanced security. And after that all sites went down and found this issue in logs. Our SSLs are bought from COMODO. Please tell me if you want more information regarding this.

Thanks for your response PiBa. I've made some good progress on this and think I have a working solution. I've found a working ACL combination: [image: 1528222391202-workingacls-resized.jpg] That is, when all backends are down, I get a match on the kdemo_dead ACL that says "!minCountUsableServers ge 1" and haproxy uses the tpc-request connection reject as desired. Interestingly, at first when I initially had SSL offload enabled for the frontend, I had a lot of errors when the package attempted to create the haproxy.cfg, and when I finally got past that I no longer got the desired behavior: despite the ACLs, haproxy still initiated a TCP connection and returned a 503. I really don't know what's changed,: perhaps it was because I had some of the boxes checked that created additional ACLs? It seems the haproxy package is dynamically generating a haproxy.cfg when I apply UI changes and sometimes the content and sequence of entries causes unintended consequences. At any rate, seems to be working now, so I'm happy:)

I think the NONE_ABORTED is because it can't retrieve the images from the cache. Can you set the hard disk cache size back to what it was previously?

Thank you, i will try doing it

Hello, I have selected OPT1 in Services - Squid Proxy Server - General - Squid General Settings - Proxy Interface(s) i don't understand where is the problem . what could I forget please ? Thank you

Ah now i can generate this : Squid Object Cache: Version 3.5.27 Build Info: Service Name: squid Start Time:    Mon, 21 May 2018 11:18:58 GMT Current Time:  Tue, 22 May 2018 10:58:14 GMT Connection information for squid:         Number of clients accessing cache:      208         Number of HTTP requests received:      463691         Number of ICP messages received:        0         Number of ICP messages sent:    0         Number of queued ICP replies:  0         Number of HTCP messages received:      0         Number of HTCP messages sent:  0         Request failure ratio:  0.00         Average HTTP requests per minute since start:  326.7         Average ICP messages per minute since start:    0.0         Select loop called: 27805416 times, 3.063 ms avg Cache information for squid:         Hits as % of all requests:      5min: 0.0%, 60min: 0.0%         Hits as % of bytes sent:        5min: 0.5%, 60min: 1.2%         Memory hits as % of hit requests:      5min: 0.0%, 60min: 100.0%         Disk hits as % of hit requests: 5min: 0.0%, 60min: 0.0%         Storage Swap size:      0 KB         Storage Swap capacity:  0.0% used,  0.0% free         Storage Mem size:      360 KB         Storage Mem capacity:    0.0% used, 100.0% free         Mean Object Size:      0.00 KB         Requests given to unlinkd:      0 Median Service Times (seconds)  5 min    60 min:         HTTP Requests (All):  0.18699  3.11263         Cache Misses:          0.46965  0.27332         Cache Hits:            0.00000  0.00000         Near Hits:            0.00000  0.00000         Not-Modified Replies:  0.00000  0.00000         DNS Lookups:          0.00278  0.01269         ICP Queries:          0.00000  0.00000 Resource usage for squid:         UP Time:        85155.572 seconds         CPU Time:      691.461 seconds         CPU Usage:      0.81%         CPU Usage, 5 minute avg:        0.50%         CPU Usage, 60 minute avg:      0.43%         Maximum Resident Size: 1444736 KB         Page faults with physical i/o: 0 Memory accounted for:         Total accounted:        7096 KB         memPoolAlloc calls: 132887173         memPoolFree calls:  135763872 File descriptor usage for squid:         Maximum number of file descriptors:  293616         Largest file desc currently in use:  1426         Number of file desc currently in use:  239         Files queued for open:                  0         Available number of file descriptors: 293377         Reserved number of file descriptors:  100         Store Disk files open:                  0 Internal Data Structures:             54 StoreEntries             54 StoreEntries with MemObjects             51 Hot Object Cache Items             0 on-disk objects Looks nothing wrong, or am i missing something maybe?

I do not understand, you put how much value in the field ssl children? Because I have the same problem too.

You could add acl's that check for the proper domainname and reject requests otherwise. Or add strict-sni to the ssl options so that the requested domain must match your certificate.

Normal LAN firewall rules are ignored for traffic that is passed to the proxy and for good reason.Tthe NAT redirect that is in place for the transparent proxy forces the traffic to the proxy by rewriting the destination address:port pair in the packets to 127.0.0.1:3128 (the usual set up) before they hit the LAN filter rules. This is why the modified traffic won't match your LAN filter rules. Make sure you're not proxying too much with a too "wide" NAT rule, NAT only the traffic you want to be controlled by the proxy.