Sorry i read my reply again, and of-course the proposed change should have read "http-check expect status 403" so it sees that code as valid..
Anyhow if your willing to dig further into the problem, lemme know, ill try and help.

Unrestrict users bypass authentication, squid has integration with captive portal. So, it's possible.

take a look on resulting config and create your own acls to complete your configuration.

So it is not possible for the captive portal and squid in non-transparent mode to work together?

Having it like:
messages.mydomain.com to point to 192.168.1.1
clients.mydomain.com to point to 192.168.1.152
Should probably work nicely..

As for the frontends make sure to make them 'shared' as the webgui calls it. Or use just use one frontend it the gui, and use the acl+action to select the second backend for the second domain.

I find it useful, I get blocks every so often especially from the game sites my son browses to. It may not be the BEST a/v solution, but it is useful…

I am not using SSL intercepting / filtering at this time.  I wanted to get a better sense of the software before diving into that.

in case anyone else has trouble there is two ways to do this.  the first is from the front end the alternative is globally. 
1.  front end - edit - advanced settings - advanced pass thru
2.  settings - Global Advanced pass through - custom options

I also have a rule in my global advanced pass through settings to explicitly deny SSL 3.0 and TLS1.0.

ssl-default-bind-options no-sslv3 no-tlsv10

even with that I was not getting good results when I would scan my subdomains using https://www.ssllabs.com/ssltest.  it noted many deprecated ciphers were in use.  I found some posts by others who were doing something close to what i wanted to do.
Ex: http://wolfspyre.com/?p=207

This was close but I still found that I was having trouble with the 3DES cipher on TLS 1.1 and 1.2.

https://www.ssllabs.com/ssltest, directed me to use the cipher list that mozilla outlined (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations).  Because all of my remote devices are newer i opted to use the Modern cipher assortment.  I added a lin underneath my default bind options eliminating support for SSL 3.0 and TLS1.0.  it is the following:

ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

Currently, these ciphers seem to rule out TLS 1.0 and force TLS1.2 only.  This could be a problem for older browsers and smart devices.  SSLLabs' ssltest does a pretty good job of enumerating which systems are likely to have trouble.  I have confirmed that all my devices work without issue given my configuration.

@vielfede:

@Pontiac_CZ:

vielfede: I have read that thread but I am still sorf of confused. What was the key setting for getting the squid to work in transparent mode?

Sorry, my mistake! I missed to clear proxy settings in client pc, hence I was suposed to use transparent mode. Indeed it does not!
Or better:

splice all + transparent mode: http works, https sometimes works and sometimes it does not, no idea about the causes

splice all + NON transparent mode works (flawlessly) http+https (you have to set proxy client settings)

Vielfede,
What about the "block page" while using HTTPS/Non-Transparent mode? Is it showing your "block page" normally? do you have your pfsense web-console using Https as well?
Thanks!
fabricio.

It seems the old known problem ( http://https* ) is still present on version 2.3.4
Also, for some reason, when using HTTPS for pfsense console, Squidguard is not redirecting the error page for Https, but http.
Still investigatin it here…

@techbee:

What I understood was, if I choose splice all, I dont need to install the CA cert to clients, am I right?

Yes, that's it.

@techbee:

On the other hand, I dont know how to push dns suffix using dhcp or maybe I get it the wrong way.

take a look or search for dns dhcp options. BTW, if you're going to configure squid splice all, it can be in transparent mode. this way, you do not need a wpad file. Mobile devices ignores wpad configuration too.

I had the same problem, this fixed it.

Thank you very much for sharing.

Steve

i'm encountering the same issue as well, IPsec requests are going towards WAN gateway instead

I got it working now. I had to use the unofficial WPAD package marcelloc created using nginx and it actually started working as it should. Thanks fellows!

If transparent proxy doesn't work well for you (I've personally found it buggy and decided against it); I've found success in setting up Group Policy to force the WPAD file on users. Defining the AutoConfigURL registry value works well. But if you're totally blocking 80 and 443 all together, I believe you can just set the ProxyServer registry value and not even need the WPAD file. (that is, depending on your environment. I'm assuming an all Windows Active Directory setup.)

https://blogs.msdn.microsoft.com/askie/2015/07/17/how-can-i-configure-proxy-autoconfigurl-setting-using-group-policy-preference-gpp/

https://support.microsoft.com/en-us/help/819961/how-to-configure-client-proxy-server-settings-by-using-a-registry-file

This is just what I have so far. I'm willing to do a more detailed write-up after I've had a chance to explore.

Essentially just follow the Windows config portion of the guide for creating the DNS entry, user and keytab file. The username can be anything. It doesn't have to be named squid. The guide shows RC4-HMAC-NT being used, but both pfSense and Server 2008 support AES256-SHA1, so this should be possible to adjust.

Put both the krb5.keytab and krb5.conf files in /etc. (It seems like it'd be a good idea to change the group owner of the keytab file to squid and then lock it down with 640 permissions, but the Squid helpers crash when doing this. I'm not sure why. The helpers run as the squid user. Maybe somebody else can chime in?)

My kbr5.conf currently looks like this ("yourdc" is your domain controller, and "yourdomain" is your FQDN. This is caps sensitive);

[libdefaults]
    default_realm = YOURDOMAIN.COM
    default_tkt_enctypes = rc4-hmac des3-hmac-sha1
    default_tgs_enctypes = rc4-hmac des3-hmac-sha1
    default_keytab_name = /etc/krb5.keytab

[domain_realm]
    .yourdomain.com = YOURDOMAIN.COM
    yourdomain.com = YOURDOMAIN.COM

[realms]
    YOURDOMAIN.COM = {
        default_domain = yourdomain.com
        kdc = yourdc.yourdomain.com:88
        admin_server = yourdc.yourdomain.com
    }

Then just put the following under the "Custom Options (Before Auth)" section in the Advanced part of the Squid config page (yourhostname is the name you defined in DNS and also when making the keytab file on the DC);

auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -i -d -s HTTP/yourhostname.yourdomain.com@YOURDOMAIN.COM -k /etc/krb5.keytab
auth_param negotiate children 10 startup=5 idle=5
auth_param negotiate keep_alive on

acl auth proxy_auth REQUIRED

http_access deny !auth
http_access allow auth
http_access deny all

The -i and -d flags are for debugging. They're probably worth taking out when no longer needed as they are extremely noisy.

For anyone planning to use this, keep in mind that this isn't going to work with Transparent Proxy enabled because this relies on the client being sent a HTTP 407 auth response.

One problem I'm working on is when something doesn't work correctly (either kerberos fails or the client doesn't support it), it will prompt the user for credentials. This credentials window is completely useless. Regardless of what is typed in, it will still fail (and possibly transmit credentials in clear text). This happens on Chrome, IE and Edge. I'm currently reading through the Squid docs for a graceful way to handle this.

*** Also, for any devs reading this - this seems like something that would be fairly painless to implement into the web UI. I can't be the only person that would benefit from this ***