Your connection is not private

Gertjan

You use pfBlockerng with a DNSBL that lists "googleadservices.com" in one of its feeds, your Chrome browser use the DNS that your device got when obtaining a DHCP lease, and this lease says "the DNS is pfSense". Thus pfblockerng 'sees' this DNS request, finds it in the list, and sends "10.0.0.1" back. This 10.0.0.1 points to the pfBlockerng local web server that wants to you that the DNS request was blocked.
But Chrome was waiting for a web site that says, with its certificate, that is is "googleadservices.com". That was not the case : pfBlockerng 's web server was answering, you get a warning.
pfBlockerng can not make, create, and send a certificate that says 'I am googleadservices.com'. That's what "https" (TLS) is all about.
The Brave browser opens a encrypted (TLS, like https) channel through pfSense to a DNS server. Not pfSense, but somewhere on the Internet : cloudflare. pfSense can not 'see' thus intercept this data stream, which hides a DNS request.
This is what TLS is all about.
It boils down to to : cloudflare is (uses) a resolver. pfSense has a resolver also. They both do the same thing. Who do you trust ? What do you want ?
Open for debate, but Google can be considered as a good search engine. Web site owners and Google itself uses "googleadservices.com" for the simple reason they want to harvest serach requests, so they can "help you better", and also collect stats, with the final end goal : to monetize your requests. As Google has also bills to pay.

How do people use pfBlockerNG with chrome without getting "Your connection is blocked" message - is there a way to get best of both worlds?

No real solution. It's a questions of choices and tradeoffs. Even if you would find the best solution, you've got thousands of Google's engineers making your live 'harder'. They want you to see these "adds", they want to know how you use their search engine.
If there was a perfect solution : No more income for Google. That means no more Google shortly after that.

netboy

@Gertjan Thanks for the detailed explanation.

"If I use brave I do not need pfBlockNG because brave stops advertisements + blocks googlservices to collect info - The benefit as I see it is that brave uses google search engine without affecting privacy"

I really do not need pfBlockNG if I use brave - Is my understanding correct? or I am missing something?

Gertjan

@netboy

I'm not a Brave user, can't tell.
What is 'better' depends on your usage.

Bob.Dig

@netboy said in Your connection is not private:

I really do not need pfBlockNG if I use brave - Is my understanding correct? or I am missing something?

I would use both anyway because the DNS sink-holing can do more for you than you might think. For me it is blocking stuff outside of my browser like other software or stuff on my phone phoning home etc.

netboy

@Bob-Dig said in Your connection is not private:

I would use both anyway because the DNS sink-holing can do more for you than you might think. For me it is blocking stuff outside of my browser like other software or stuff on my phone phoning home etc.

Thanks - this makes sense.

I wiould welcome others how they leverage google search and use various browsers. Basically I am looking for "best practise" how to leverage both google search (without privacy concerns) + pfBlockNG

totowentsouth

@netboy My best practices:

qwant.com for search
Firefox with uBlock origin and most of the default recommended lists
Chromium (with uBlock origin) when necessary as some websites are allergic to Firefox
Unbound (DNS Resolver) on pfSense in full recursive mode
pfBlockerNG with regularly maintained comprehensive ad, phishing and malware block lists such as oisd.nl and hagezi
pfSense + pfBlockerNG to block known DoH servers by domain and IP address with the understanding that 100% blocking of DoH via domain and IP is futile.
Configure Unbound to respond with NXDOMAIN for a small popular set of DoH domains. Some devices are grumpy when the DNS response for a DoH domain is 0.0.0.0 or 10.0.0.1.
NAT redirection in pfSense firewall rules to redirect all DNS queries over port 53 back to the pfSense box. Some devices will report "no internet connectivity" when denied DNS queries over port 53 and a hard coded IP.

netboy

@totowentsouth Wow!! Thanks

@totowentsouth said in Your connection is not private:

Unbound (DNS Resolver) on pfSense in full recursive mode

Can you please explain to a non-network person in "english" what does this do?

uBlock origin
I installed this in Chrome and voila the googleservices vanishes....Now I can use google chrome without the annoyance. since this solves the googleservices what is the use case to use qwant.com for searches?

johnpoz

@netboy said in Your connection is not private:

in "english" what does this do?

It resolves vs forwarding.

You want to look up www.domain.tld it asks the roots hey who is the name servers for .tld

Roots answer with NS for .tld

It then asks the NS for .tld hey what is the NS for domain.tld

They answer.

It go asks NS for domain.tld hey what is the A record for www.domain.tld

you get the IP address of www.domain.tld

This is how dns works..

here is a full example.. I cut down any dnssec info to keep it cleaner looking.

$ dig forum.netgate.com +trace +nodnssec

; <<>> DiG 9.16.44 <<>> forum.netgate.com +trace +nodnssec
;; global options: +cmd
.                       16609   IN      NS      h.root-servers.net.
.                       16609   IN      NS      g.root-servers.net.
.                       16609   IN      NS      f.root-servers.net.
.                       16609   IN      NS      l.root-servers.net.
.                       16609   IN      NS      b.root-servers.net.
.                       16609   IN      NS      a.root-servers.net.
.                       16609   IN      NS      d.root-servers.net.
.                       16609   IN      NS      i.root-servers.net.
.                       16609   IN      NS      e.root-servers.net.
.                       16609   IN      NS      c.root-servers.net.
.                       16609   IN      NS      m.root-servers.net.
.                       16609   IN      NS      j.root-servers.net.
.                       16609   IN      NS      k.root-servers.net.
;; Received 239 bytes from 192.168.3.10#53(192.168.3.10) in 7 ms

com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 873 bytes from 192.5.5.241#53(f.root-servers.net) in 12 ms

netgate.com.            172800  IN      NS      ns1.netgate.com.
netgate.com.            172800  IN      NS      ns2.netgate.com.
netgate.com.            172800  IN      NS      ns3.netgate.com.
;; Received 232 bytes from 192.33.14.30#53(b.gtld-servers.net) in 27 ms

forum.netgate.com.      300     IN      A       208.123.73.83
netgate.com.            3600    IN      NS      ns3.netgate.com.
netgate.com.            3600    IN      NS      ns2.netgate.com.
netgate.com.            3600    IN      NS      ns1.netgate.com.
;; Received 276 bytes from 208.123.73.80#53(ns1.netgate.com) in 33 ms

Even when you forward to say quad9 or googledns or 1.1.1.1, there is a resolver upstream of them that they ask.. The only way to learn the IP address of some fully qualified domain name (fqdn) is to resolve..

Once a fqdn has been resolved.. Your dns server you asked will cache it for a length of time.. See the numbers there 172800, and the 3600 those are seconds.. Once something has been looked up, that is how long that lookup can be cached.

So in the above example forum.netgate.com can be cached for 300 seconds. after that have to look it up again, but since already know the ns for netgate.com and can cache them for 3600, can just go ask them directly - do not need to ask roots or gtld servers.. etc..