help to unblock chia

DaddyGo

On my J1900 it is a challenge.

this "iron" is more than enough for your target... (home privacy and security)...

we have several endpoint pfSense installations (https://www.pcengines.ch/apu4d4.htm) that can handle large DNSBL lists with 4G RAM, just don't overload your "box" with unnecessary heavy apps (Squid for home, IPS for home, thousands of OpenVPN tunnels)

my answer to the question of the list, it all depends on what you want to achieve, there can be very different goals
(f.e.: I have at least 10 variations for lists, the first is always to keep the bad guys out, the second is to keep the individual goals)

for XXX, I would suggest the following, just off the top of my head, which was in my collection:
(but there are many other good lists for this purpose)

https://raw.githubusercontent.com/Clefspeare13/pornhosts/master/0.0.0.0/hosts
https://raw.githubusercontent.com/chadmayfield/my-pihole-blocklists/master/lists/pi_blocklist_porn_all.list

@gwaitsi "xhamster - brings me SSL_ERROR_INTERNAL_ERROR_ALERT"
(I see everyone is into the good stuff)

just do the right things: - Diagnostics / States / Reset States

johnpoz

Where is chia.net being filtered by 1.1.1.3??

$ dig @1.1.1.1 chia.net +short
104.22.7.173
172.67.44.5
104.22.6.173

$ dig @1.1.1.3 chia.net +short
104.22.7.173
104.22.6.173
172.67.44.5

Now other stuff is filtered..
$ dig @1.1.1.3 www.youporn.com +short
0.0.0.0

DaddyGo

@johnpoz said in help to unblock chia:

chia.net being filtered by 1.1.1.3

Yup, that's right, it wasn't checked...
(just looked it up I also, 1.1.1.2 does not filter this site
would be strange as it uses CF cert. - they don't shoot at "house rabbits"

this also shows there are other problems there

+++edit:
originally the discussion was about 1.1.1.2

@gwaitsi "My unbound is fowarding to 1.1.1.2. could it be;
1.1.1.2 blocks chia.net"

4o4rh

@johnpoz I rechecked it.
1.1.1.1 / 1.1.1.2 / 1.1.1.3 all resolve and can traceroute for chia.net
1.1.1.2 / 1.1.1.3 https doesn't work to chia.net (but does if it use firefox dns over ssl settings to 1.1.1.1)

I have a good config. I am using 1.1.1.1 and pfblocker for the lists).

Three observations;

the dnsbl lists don't load on boot. Waiting to see if they load on the next scheduled cron job. * it updates on the first cron run. wouldn't it make sense to run all cron jobs on boot?
some results e.g. xhamster get return ssl errors rather than a pfblocker banner but the net effect is the same, the site is blocked.
the results are not filtered from search (I use duckduckgo). ** this was the reason from memory I went for the 1.1.1.3 to begin with

So, looks like I have come the full circle.
If I want the results to be removed from the search, I need to use cloudflare family.

But then, I am stuck with not being able to access https://www.chia.net

** interestingly, with pfsense set top 1.1.1.1 i set firefox to dns over ssl with 1.1.1.3 and it works.
so, something on my pfsense is causing https://www.chia.net to break when I use either 1.1.1.2 / 1.1.1.3 as the dns. but doesn't seem to happen to anything else.

4o4rh

@DaddyGo this gives a better result for me, because xhamster, porn etc from any browser simply returns no results and I don't have to worry about maintenance. I wonder if there is still any point to also use dnsbl as it only uses additional resources.

johnpoz

Well for one www.chia.net and chia.net are not the same thing.

$ dig @1.1.1.3 chia.net +short
172.67.44.5
104.22.6.173
104.22.7.173

$ dig @1.1.1.3 www.chia.net +short
0.0.0.0

1.1.1.3 filters on www.chia.net but not on just chia.net

.2 is also filtering it

$ dig @1.1.1.2 www.chia.net +short
0.0.0.0

4o4rh

@johnpoz i noticed that, but am getting exactly the same as you with dig.

If you go to www.chia.net or chia.net in a browser, they both auto goto https://chia.net

with the general settings as 1.1.1.1
https://chia.net works

with the general settings as 1.1.1.2 or 1.1.1.3
https://chia.net does not work

with firefox set to dns over ssl using 1.1.1.3
https://chia.net works

i am really stuck on getting to the bottom of this

johnpoz

You sure filtering even works over dot? There was a whole thread about it..

https://community.cloudflare.com/t/1-1-1-3-does-not-filter-content-if-queries-are-made-via-dot-dns-over-tls/167730

I have not tested it because to me dot or doh is a complete abomination, and without something to encrypt the sni, be it esni or ech trying to hide your dns queries from you isp via dot or doh isn't really doing that. All you end up doing is sending your queries to the 3rd party as well as your isp knowing the fqdn your going to, with always knowing which IP your going to anyway no matter what.

Now in that above thread they said there was some mention of it being enabled - but I have not actually tested it.

Keep in mind that be it you go to chia.net or www.chia.net in your browser at some point your going to get a 301 to redirect you.

Connecting to chia.net (chia.net)|104.22.6.173|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.chia.net/ [following]

So your going to have to resolve www.chia.net - which isn't resolving 1.1.1.2 or .3

If your goal is leveraging clouldflare dns for there filtering - then do that. And take doh or dot out of the equation. Browsers don't do dot, they do doh, while pfsense does dot and can not do doh..

Also bringing up your other thread about doing specific forwarding for specific client - I know of no way to do that with unbound. So you either run bind that can do that, and for sure uses different caches even for the different views. Or you run multiple instances of unbound where 1 forwards to filtering, and other forwards to non filtering - and point the clients you want to do what to the respective instance of unbound.

4o4rh

@johnpoz I can't say I understand a word you said there m8.
Can you repeat the last part in idiot's English please.

Are you saying 1.1.1.2 doesn't work?
But why does it work if I use it in the browser as DNS over SSL?

johnpoz

@gwaitsi said in help to unblock chia:

But why does it work if I use it in the browser as DNS over SSL?

dot and doh are different - that link was saying that dot doesn't work for filtering, some people suggested it does near the end. But maybe it only works with doh and not dot. Browsers use doh..

If I find some time this morning from real work - I will try and give it a test.

4o4rh

@johnpoz would appreciate it

johnpoz

Ok suppose to be doing some real work stuff - but this was quick test.. So doing a dot test to 1.1.1.3 filters www.chia.net

user@NewUC:~/tmp$ kdig -d @1.1.1.3 +tls-ca +tls-host=family.cloudflare-dns.com www.chia.net
;; DEBUG: Querying for owner(www.chia.net.), class(1), type(1), server(1.1.1.3), port(853), protocol(TCP)
;; DEBUG: TLS, imported 129 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: od9obscoXQND56/DikypZrJkXGvbQV5Y61QGfcNitHo=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 11574
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 407 B

;; QUESTION SECTION:
;; www.chia.net.                IN      A

;; ANSWER SECTION:
www.chia.net.           60      IN      A       0.0.0.0

;; Received 468 B
;; Time 2021-06-09 08:42:07 CDT
;; From 1.1.1.3@853(TCP) in 26.3 ms
user@NewUC:~/tmp$

I will try and do a test with doh here in a bit.. got a freaking meeting have to join - arggh ;)

4o4rh

@johnpoz what is the meaning in English pls?

Regarding filtering, 1.1.1.3 provides the services for normal users for sure.
If you try any of the search engines and enter variants of porn, etc. no results are returned at all.
This is the ideal behaviour I am looking for, in terms of the family.

from the desktop

kdig -d @1.1.1.3 +tls-ca +tls-host=family.cloudflare-dns.com www.chia.net
;; DEBUG: Querying for owner(www.chia.net.), class(1), type(1), server(1.1.1.3), port(853), protocol(TCP)
;; DEBUG: TLS, imported 130 system certificates
;; WARNING: connection timeout for 1.1.1.3@853(TCP)
;; ERROR: failed to query server 1.1.1.3@853(TCP)

couldn't find how to install kdig on pfsense

from desktop to pfsense

kdig -d @192.168.2.1 www.chia.net
;; DEBUG: Querying for owner(www.chia.net.), class(1), type(1), server(192.168.2.1), port(53), protocol(UDP)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 22077
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; www.chia.net.                IN      A

;; ANSWER SECTION:
www.chia.net.           60      IN      A       0.0.0.0

;; Received 46 B
;; Time 2021-06-09 16:06:39 CEST
;; From 192.168.2.1@53(UDP) in 104.2 ms

johnpoz

@gwaitsi said in help to unblock chia:

ERROR: failed to query server 1.1.1.3@853(TCP)

That means you could not talk to 1.1.1.3 on 853.. Your blocking it most likely.

couldn't find how to install kdig on pfsense

I wouldn't suggest that even if there was a package available somewhere for freebsd.. Unless pfsense/netgate adds that as option.. Installing unsupported 3rd party packages not good idea normally.

4o4rh

@johnpoz said in help to unblock chia:

@gwaitsi said in help to unblock chia:

ERROR: failed to query server 1.1.1.3@853(TCP)

That means you could not talk to 1.1.1.3 on 853.. Your blocking it most likely.

correct. because pfsense is the dns server the clients connect to and 53/853 and nat'd to pfsense
unbound is in forwarding with dns over ssl to 1.1.1.3 (1.1.1.1 works)

johnpoz

What your clients are set to do and what a directed query is doing are different. If your only allowing clients to talk to pfsense that is fine for dns.

My point was it works via talking dot to 1.1.1.3.. So it should be filtered in pfsense... Use the pfsense dns look gui.. What do you get?

And again!! www.chia.net is blocked.. If your using 1.1.1.3 NO your not going to get to www.chia.net - which chia.net is redirect too.. So you have to be able to resolve www.chia.net

Just tested with doh.. And www.chia.net is blocked with 1.1.1.3 as well

user@NewUC:~$ q A www.chia.net @https://family.cloudflare-dns.com/dns-query
www.chia.net. 1m0s A 0.0.0.0

If you say it works - then your not using 1.1.1.3 or .2 since both of those block www.chia.net

4o4rh

@johnpoz so I can confirm from the pfsense dns lookup;

I get A records for www.chia.net with 1.1.1.1 is used
I get no A records for www.chia.net with 1.1.1.2 is used

so, in summary;

that means cloudflare is filtering right?
but my NAT forwarding of 53 / 853 is not working (because i can bypass with dns over ssl).
i have in the NAT rules

Interface: LAN
Protocol: TCP/UDP
Source Addr: *
Source Port: *
Dest addr: !LAN Address
Dest Ports: alias = 53 853 67:68 37 123 5351:5357
NAT IP: LAN Address
NAT Ports: alias = 53 853 67:68 37 123 5351:5357

so what is my solution?
i want the benefit of family which makes sure the kids can't google stuff,
but i will also need some exception. but it is strange i never had a problem till this one site

johnpoz

Not sure where you got the idea that you could redirect 853 queries?

Simple solution to allow for www.chia.net when your unbound is filtering it, is just create a domain override pointing to 1.1.1.1 for the chia.net.. Now anyone can look that up.. Because unbound will ask 1.1.1.1 for that

Now back to a shane configure of my network blocking all and any doh or dot from anything.. ;)

4o4rh

@johnpoz
yes, I see that fixed it. thank you ;-)

why am i mistaken in thinking i could trap 853 requests?
p.s. i am no idea of what a dot or doh is. sounds like taking the p.ss ;-)
i will have to do some duckduck'ing

johnpoz

@gwaitsi said in help to unblock chia:

why am i mistaken in thinking i could trap 853 requests?

You can redirect them sure.. But where you going to redirect them too? And the fqdn and certs are not going to match..

If client is wanting to talk to www.dotdns.tld, and you redirect it to say unbound listening on 853 using what for the cert.. Sure not going to be www.dotdns.tld ;)

So your client if sane should say F that -- someone is mitm my query..

See above where I did the dot query, and certs are involved.

;; DEBUG: TLS, imported 129 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: od9obscoXQND56/DikypZrJkXGvbQV5Y61QGfcNitHo=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.

You can block it sure.. But redirecting them when the client should and would validate talking to the correct server is not really possible.

While sure you could mitm yourself for a specific dot server.. And the client could be setup to trust the cert your using and think its actually www.dotdns.tld - but what if they try other.dnsdot.tld, etc. etc..