Ooohhhhh…Well, at least it was an honest mistake.  Thanks for pointing me to the correct playing field.  Just makes me question my day 1 logic class reflexivity principle.

HAProxy != HAProxy

:o

I do believe, though, that you could still legitimately call DSR products "proxies", they're just L2 proxies.  I mistakenly assumed that checking the Transparent ClientIP box in pfSense's HAProxy implementation turned it into the L2 magician I'm looking for.

I´ve done the clear cache option but still having the same problem of cashparov i don´t know what to do now.

Hi,
I put the ldaps:// in the command below, tested and it worked, as mentioned above …

./basic_ldap_auth -v 2 -b ou=users,dc=company,dc=local -D cn=admin,dc=company,dc=local -w XXXXXXXX -f "uid=%s" -u ou=users,dc=company,dc=local -P ldaps://ldap.company.local:636

But when I make the change in squid.conf and run "squid -k reconfigure", the authentication fails.
I added the CA certificate through Cert. Manager, what could be wrong?

The fix for this was to move the HAProxied hosts to their own subnet and interface on the firewall, independent of the "LAN".  Then, hosts on the LAN can still benefit from the failover HAProxy provides.

Seems that when a FQDN is added which does not resolve, squid treats it as a '*'.

I assume it also has to do with a blocking shellcmd process, which caused my other problem.

kr

So… today it’s working. I’m still not sure that everything is done by the book but this is it:

#WAN interface
#My main interface 192.168.130.1 (router on a stick with several VLAN-s on it)
#My second interface 192.168.120.1 (router on a stick with several VLAN-s on it)

In Services – Squid Proxy Server under Proxy Interface(s) I have selected both the 130.1 and 120.1 interface and every VLAN interface.

In Firewall – NAT I have this:
130InterfaceNet    TCP/UDP    *    *    *    53 (DNS)    127.0.0.1    53 (DNS)    Redirect DNS   
120InterfaceNet    TCP/UDP    *    *    *    53 (DNS)    127.0.0.1    53 (DNS)    Redirect DNS

(in Firewall Rules I allow/block traffic between VLAN-s)

And in the WPAD file everything returns to the 192.168.130.1:3128

My two questions are:
#1 Why do I only have to make the NAT port forward for the main interface and not for the VLAN interfaces?
#2 Is it OK, since it does work, that the WPAD returns everything to that one 192.168.130.1:3128 or should the 192.168.120.0 network return to 192.168.120.1:3128?

@Tantamount:

I thought the CN was how programs determine if the certificate belongs to the host providing the certificate – I.E. verify that the FQDN matches the CN.

Actually, since RFC 2818 back in May of 2000, the use of CN for matching hostnames has been deprecated in favor of matching based only on Subject Alternative Names (SAN). Some browsers still fall back to check the CN if the SAN list is empty, but Chrome recently dropped checking CN entirely and now only looks at the SAN list.

I'm not sure how that would have made a difference with your splice all setup, since it wouldn't be doing MITM, except that maybe having that on still made it alter the certificate when it should have left it alone.

Hello again.

Finally I installed the Unofficial wpad and I configured the dns resolver, but I can not get the wpad file. Probably because of my rules. If I write the url in a client http: //wpad.mydomain.local/proxy.pac
Is not able to download it. nslookup command Works fine and i get ip address of the lan.
From a vlan these are my rules.What is wrong with them?

Anybody found a solution to this? I am trying to get SQUID to work with CP authentication but cant! Help will be appreciated

@shyaminayesh:

any updates on this ?

No because it is not a bug, it's working in the only way that it can with SSL/TLS.

wow how the time passed posting this more then a year ago :0

Well i tried the redirect URL but I just gave up and when a user cant get in a website they notify me and i fix it,