I dont see the "http-request auth" in there?

I use squid and it works fine for me.  Maybe you have a config issue with transparent mode and certificates, peek & splice settings etc.

Android doesn't support WPAD, IIRC.

Some rewrite rules can be made in the gui with 'actions' but they are a bit limited and well manually writing them might actually be easier.. Also there is a option to use custom actions and advanced backend pass thru options to write parts of the config 'manually'..

There is not really a way to manually manage the complete config. Also because of adding certificates and using the 'test' and 'actual' config folders would be troublesome when manually trying to create/manage the config files, what paths would one use to include lists with subnets/IPs or certificates..

Unless of-course if you want to go 100% off the gui managed functionality completely manage haproxy outside the gui with custom scripts and config files.. That probably has some downsides to though..

ClamAV or any other AV running on a system like pfSense will not be able to perform virus inspection on an https site. I'm sure you know https is encrypted traffic. Therefore, the AV can't do any kind of packet level inspection since the data between the web site to your client PC is encrypted. If you have squid setup to do HTTPS/SSL Interception (Man in the middle), then it should be able to perform a virus scan of that encrypted data. However, this is a bad idea. I'm no expert on this, but there have been many posts on these forums (as well as other forums I'm sure) as to why it's not a great idea to "breach" that encrypted data for any purpose. It could break https traffic in some cases. I think newer SSL/TLS standards may not like the data being altered for any reason. Also, it may pose a legal issue since https encryption is supposed to offer privacy and security. If the data is broken down along its route for virus inspection or any other purpose, then privacy is technically no longer intact. Security wise, performing AV inspection is a good thing, but if that AV system is compromised, you are then potentially allowing someone to access encrypted data which would otherwise be inaccessible, by design.

Yes, DNS lookups are faster in your second config.

You are 100% right…except your aren't.

We have a secured internal network, what I am proposing is taking a spare public IP on my backup internet connection, and having it only accept packets going to that port, and forwarded to the internal LAN to forward it to the IP in the cloud.

The system is in the cloud, however they won't open external ports on their firewall, which is annoying. We generally like the idea of using the VPN to keep things secure, but our employees are....dumb, and instead of hitting the giant button that says "reconnect" if it loses cell reception, they just complain it doesnt work, and then we end up losing the ability to track our fleet.

Sorry for the confusion, you are generally right, however we are taking every precaution to secure the situation

If it doesn't start after hitting save and then apply, check the logs for errors.

Steve

Thanks ;)
That did the trick.
Now i have to import the certificate to androids.

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…