It does work with MITM and certificates installed on the computers and mobile devices. I originally had the dns settings for safe search but i've removed them and now I'm using squidguard safe search, which is working fine. So basically no need to force safe search using the DNS method if you have SSL certificate installed on all devices you can just us the squidguard safesearch. I've just double checked with enabling and disabling safesearch and it worked the way it's suppose to.

I've now got a call that didn't work and analyzed the log entries. Here is the log: (I replaced the phone numbers and my external IP) Apr 20 14:57:28 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:57:24 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:57:20 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:57:16 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:57:12 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:57:08 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:57:06 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: LANDLINE@pro1.voipgateway.org -> MYPHONE@pro1.voipgateway.org [Req: MYPHONE@MYEXTERNALIP] [IP: 212.117.203.34:5060] Apr 20 14:57:04 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:57:00 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:56:58 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:56:57 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:56:57 siproxd 73173 plugin_logcall.c:127 INFO:Ending Call: MYPHONE@pro1.voipgateway.org -> LANDLINE@pro1.voipgateway.org [Req: *NULL*@212.117.203.40] [IP: 172.17.2.26:5060] Apr 20 14:56:16 siproxd 73173 plugin_logcall.c:127 INFO:Incoming Call: LANDLINE@pro1.voipgateway.org -> MYPHONE@pro1.voipgateway.org [Req: MYPHONE@MYEXTERNALIP] [IP: 212.117.203.34:5060] For the caller it was like the call was never accepted. (He would still hear the beeps) And on my side there was no sound at all. Any ideas what could cause such problems?

Solved! Add allowed networks in Services –> Squid Proxy Server --> ACLs --> Allowed Subnets :)

Hi again! It`s working as expected now :) Pages load no more partial loads.

That was it, thanks much!

Perhaps you could add a acl? 'Path starts with' : '/.well-known…..'

@wiz561– I've moved away from Synology due to lack of integration between applications. Nothing against them, I do really like their products out of the box. I've moved to NextCloud, Google Photos, & dedicated web servers for hosting. I still do use HAProxy as discussed in this thread. I do believe Synology has since integrated a reverse proxy server right into DSM. You might want to check it out--I have never used it, so I can't officially vouch for it. For what it is worth, my latest HAProxy config is shown here: https://forum.pfsense.org/index.php?topic=146701.msg796970#msg796970.

Ok, it seems there is different kinds of info - like - TCP_MISS/520 & TCP_MISS/200 ect Yes, there are many bits of information there including the Address you're trying to reach through the proxy. Ok. It is running transparently. Transparent mode can be tricky to get working with HTTPS sites. I don't understand what you mean by: "To that end, delete he X-Forwarded header, disable VIA headers, and suppress squid version" Go to Services - Squid Proxy Server - General tab - Headers Handling, Language and Other Customizations section.  Start reading.

Its global passtrough settings…

THX  :)

Is having a firewall rules in place enough since this is the current version of squid supported? Did you actually read the CVE?? "The Squid Software Foundation Squid HTTP Caching Proxy version 3.0 to 3.5.27, 4.0 to 4.0.22 contains a Incorrect Pointer Handling vulnerability in ESI Response Processing that can result in Denial of Service for all clients using the proxy.. This attack appear to be exploitable via Remote server delivers an HTTP response payload containing valid but unusual ESI syntax." All this means is that a funny packet can crash squid.  If you want to protect against this via firewall rules, simply block all tcp 80/443 traffic.  You won't be able to use the web at all, but you will be safe from having your squid crashed if you happen to hit the figurative lottery and somehow stumble upon this… Also, enabling the option Suppress Squid Version enough to hide the squid version? Probably.  Test it and see: http://www.lagado.com/proxy-test You should suppress squid version, turn off VIA headers, and delete the X-Forwarder header.

Sorry for the late reply I did end up making a Gmail alias with the ports that go above my other rules which seems to work.

Do you actually have a 3rd interface (after WAN and LAN) that you have labelled DMZ?  It isn't there for everyone by default.

Squid is a caching proxy.  Squidguard is an URL filter that requires squid.  Squid by itself does not block content except for in the most primitive way.

On the frontend you chose mode:'http/https(offloading)' however behind the 443 port you dont have the offloading checkbox set. Should probably check that. Then also when enabling that make sure to configure certificates to use at the bottom of the frontend.