help to unblock chia

johnpoz

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..

4o4rh

@johnpoz point was to trap requests to outside DNS. e.g. android clients, etc.
So i think it is ok, it is breaks no?

johnpoz

Yeah blocking it is fine.. I do it for both doh and dot.. Dot is easy just block port 853.. But doh can be problematic to block since its just standard 443.

But tricking a client into thinking its talking abc, while its really talking to xyz is way more tricky. Unlike with normal dns over tcp/udp 53.

alicaparker

This post is deleted!