Worked like a charm! Thanks anything else you noticed in my haconfig that should be changed?

Thanks for the reply.  Will move over there, thanks.

In case of 'shared frontends' only 1 frontend is written to the config, and the configuration settings are 'combined' so that might be ok.

The webserver server line does also count bytes in/out ?

What if you run a 'curl http://webserver.example.net/' request to the haproxy frontend.? Does that timeout as well? Or does it perhaps redirect to a https://wanip:443/ while haproxy is listening on :80 or perhaps a redirect to https://url:9001 ? In which case the timeout would make sense as those ports are likely not open..

What do haproxy logs tell for the request? Either send them to a syslog server elsewhere on the network, or to the local log socket so it will show in status\packagelogs.

@KOM:

Isn't Diladele some paid application??  You don't need them to do URL filtering.

Thanks for pointing that out. I'm at work and gave the guide he posted a quick look, and the first page had what appeared to be clear instructions. I didn't realize he was promoting a company… Was definitely misled.

-RYknow

Haproxy just makes a plain tcp connection to port 25 and sends a few commands.. to push out a receiver subject and body.. the mailserver must be configured to not require authentication from haproxy's ip for this to work.

No authentication setting is available:
http://cbonte.github.io/haproxy-dconv/1.8/snapshot/configuration.html#3.6

An update…

I connected a laptop to the WAN side segment and I was able to connect to the proxy. So seems the problem is the router port forward... it is like it needs another port besides 3128 to connect.

Leo Manes

For anyone that bumped into this issue, the following thread solved the issue https://forum.pfsense.org/index.php?topic=141555.msg772504#msg772504

Thanks again PiBa,

I must be blind. Did not see the down arrow to add a lua script. Worked like a charm.

Regards,

Thanks for the links,

A single certificate can be valid for multiple domains, so you can make 1 certificate thats valid for both www.domain.com and domain.com as a 'Subject Alternative Name'. And yes to be able to send a redirect you still need a valid cert..

Having IIS bound to * should also work imho.. as long as it accepts haproxy's connection the request should be handled the same..

As for internally it should just work the same as externally.. Unless you visit it by a different hostname and have iis check for that also?

Will look further into it.

@DDDSSS:

and hopefully whatever's causing the HTTPS filtering to work inconsistently with PFsense gets sorted out

Not gonna happen. Since it seems that nobody in pfSense cares about Squid HTTPS filtering in transparent mode with Splice-All setting.
I read a lot of topics here. And the most common answer - Do not use HTTPS filtering in transparent mode. It's not designed for that, blah-blah-blah.
Despite it working flawlessly on other distros.

Ok, so I think I'm finally understanding where I was messing up in my squid RP logic. I was under the impression that each web server would be encapsulating their traffic into their own Let's Encrypt certificates, then forwarding that traffic to the RP server, which would then encapsulate it with its own certificate.

So… with that said, I now have another issue, which is that at least a couple of my services (OpenCloud being the main one) have https, server checks inbedded in the system, and will throw errors if not encrypted properly. Is there any way to set an end-to-end encryption path for apps like this, and really for any other http service I may have running? (I don't really like the idea of my passwords floating around on my lan between servers that much). Is there a setting in Squid Reverse Proxy for an upstream, either self-generated or squid generated certificate?

You need to use self generated Root CA to decrypt HTTPS.

It is luckily not possible to use lets encrypt. Imagine for a second it was possible - would you connect to all that WiFi spots in the modern world? Everyone would be able to decrypt your HTTPS without you even knowing.

The acl should probably check for the hostname.

After having issues with autodiscover it appears that setting Compatibility mode to intermediate fixed it. Is there any better way to fix this?

https://doc.pfsense.org/index.php/WPAD_Autoconfigure_for_Squid

Thanks. Today the issue returned and being suspicious I check on another computer bypassing my whole pfSense setup (directly on corporate LAN) and the same issue exists. I'm confident it is an issue with the upstream proxy.

I'm going to mark this thread as solved, but I'm sure I'll be back in a day or 2 with a new issue as I try and bring this thing up. Thanks for the help, seems like a strong community.  :)