Lacking any sensible clue I ended up iterating through all options.

Forcing resolution of IPv4 DNS lookup first seems to have solved the issue (option "Resolve DNS IPv4 First").

However I do not understand why and what was actually changed since August (2.4 RC version from mid August). I did not have this setting enabled before …

Any insight regarding this?

thank you doktornotor.  :)

Create 2 firewall rule to block trafic on interface LAN for IPv4 TCP destination: Firewall itself destination port 1: HTTP and duplicate it to second rule and change to destination port 1: HTTPS. This is easy like a charm

Why not use one SQUID on localhost, and nat to that that interfaces you want? And properly configure it

Thank you very much! It would be great if you could initiate steps towards including the required capabilities in the package or if you could recommend where/whom else I should ask.  Michael

I've figured out the problem. It's two parted.

1. The regex library used in this case does not seem to support negative lookaheads like "(?!word)" for some reason. Not sure what library is used, if it's bundled with squid or if a local regex library is used. Maybe something can be done here?

2. It's indeed a allow/deny config. I think the only way to achieve what we're trying to do if problem 1 cannot be solved is to add some functionality to the reverse proxy GUI.

acl rvm_server1 url_regex -i ^https?://(www.)?domain.com.$
acl rvm_server2 url_regex -i ^https?://(www.)?domain.com/cloud($|/).$
cache_peer_access rvp_server1 allow rvm_server1
cache_peer_access rvp_server2 allow rvm_server2
cache_peer_access rvp_server1 deny allsrc
cache_peer_access rvp_server2 deny allsrc
never_direct allow rvm_server1
never_direct allow rvm_server2
http_access allow rvm_server1
http_access allow rvm_server2

Above is an excerpt from my squid.conf as generated by pfsense. Adding a single line at the correct position solves the problem.

cache_peer_access rvp_server1 deny rvm_server2

Adding the line above before the allow line of rvp_server1 and presto. Doing this from the GUI is probably easier to do by adding another url_regex on the same mapping page and denying that instead of cross referencing and I'm doing above.

Does anyone acquainted with the pfsense squid package have any input on this? Maybe the thread should be moved to packages too.

No, it will NOT work without a PROPER certificate, as already noted.

@oki:

in your current haproxy setup (initial post), you do ssl offloading and do ssl encryption again on your backend.

1. is your backend webserver listening on port https://10.10.10.52:443 and can you access the webserver using https?)
2. when reencryption is not needed in your LAN, switch "SSL off" for your backend. and change the HAProxy Backend to your http listening port. (maybe http://10.10.10.52:80 ?)
3. Verify, that the status for your backend is Up in haproxy.
4. if 1 to 3 is successful done, verify that you are using the correct Certificate for your Frontend. (DO NOT USE the pfsense WebUI Certificate, neither a (root) CA certificate). It's needed to use a SSL-Webserver certificate, as issued from Let's encrypt.

It work like a charm when I switch SSL off on my backend and change my http listening to 80 !
I also put the verification method back on HTTP.
I'm doing more extensive functional tests tonight and I'm making a return to you and DRago_Angel!

I thought you were asking about the numbers, not the URLs  ;D

Those look like weird-ass ASCII-encoded addresses like spammers use to obfuscate themselves.  Have your phone person do their thing and watch squid's realtime view to see what's going on.

I don't know PFBlocker so I can't provide any advice here.

You could install just (only) the SquidGuard package again and recheck your ftp access. If it works, the fine. If not proceed as laid out in my previous post (check for alerts in Squidguard, then disable corresponding rules).

-flo-

ok it seems to work
I had to reboot pfsense

0.4.42 no longer allows users to select unusable certs/CAs.

Fixed in 0.4.4x