DNS Block and Redirect for IPv6

Gertjan

The first rule gets used : this is the IPv6 DNS traffic send to pfSense, that's ok - no need to NAT this traffic.
The second rule : the actual NAT rule, never gets used - the counters stay zero - ... that's puzzling. Can you show this NAT rule ?
and because traffic isn't NATted, the third rule is reached, and starts rejecting.

Btw : none of your IPv6 devices seem to use destination port '853'. That's ok, and normal.
Some IPv4 capable devices do use DNS to port '853' (pfSense) .

aGeekhere

@Gertjan Been following the Doc, here are the NAT rules

I wonder why the ipv6 rule has this issue but not the ipv4 rules, did i make an error or is it a bug?

johnpoz

@aGeekhere said in DNS Block and Redirect for IPv6:

IP6 DNS Reject (1752636706) [2403:5801:13b9::220]:55984 [::1]:53 UDP

Do you have an ACL for this IPv6 source address?

And a redirect for 853 isn't going to work because - not with any sane client, because it would validate the cert you provide - which isn't going to be valid for where they wanted to go.

aGeekhere

@johnpoz I have DHCPv6 Static Mappings

johnpoz

@aGeekhere not talking about the IP - I am talking about unbound ACL list. Do you have it set for auto, or did you turn that off and manually set it. If you query pfsense IPv6 normally do you get answers?

Lets see a nslookup to pfsense IPv6 address - and then to something else. Your saying it works to pfsense IPv6 address but then you get a reject to something else that is redirected to loopback?

aGeekhere

@johnpoz I do no have any Access Lists and in the doc https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

Clients using DNS over TLS or DNS over HTTPS could circumvent this protection. Redirecting or blocking port 853 may help with DNS over TLS, depending on the clients.

See Blocking External Client DNS Queries for additional advice.

So far ipv4 as per the doc works, ipv6 seems to not work

johnpoz

@aGeekhere - my point is that statement about the depending on the client - a sane client will validate the cert given back. If its not valid it won't work. One of the major points of both doh and dot is validation that your talking to who you think you are talking to - a dot client that doesn't validate the cert is utter shit.. what would use a shit client that doesn't validate the cert?

If you are getting a reject - points to unbound ACL not allowing the query.

Forget the dot redirect for a moment - and do a simple dig or nslookup query to pfsense IPv6, and then to some other IPv6 - do you get an answer when direct to ipv6 IP of pfsense, and then a reject on the redirect?

Gertjan

@aGeekhere said in DNS Block and Redirect for IPv6:

did i make an error or is it a bug?

I've tried to do the same thing as you : NAT IPv6 DNS traffic to "::1".
Guess what : for the usual reasons I could't make it work neither.
Reading this wasn't motivating :

Anyway.

On my LAN, I added a IPv6 DNS NAT, NOT using "::1" , but the pfSense LAN IPv6.

which produced this LAN firewall rule :

Take note of the second rule that blocks all DNS IPv6 traffic.

Test on the console/ssh :

[25.07-RC][root@pfSense.brit-hotel-fumel.net]/root: dig @2001:4860:4860::8888 test-domaine.fr AAAA +short
2001:41d0:2:927b::15

( means : I ask Google's IPv6 DNS, 2001:4860:4860::8888 to resolve test-domaine.fr for AAAA )
That worked out.

Now, from my PC :

C:\Users\Gauche>nslookup
Serveur par defaut :   pfSense.bhf.tld
Address:  2a01:cb19:abcd:a6e2:92ec:77ff:fe29:392c
> server 2001:4860:4860::8888
Serveur par defaut :   dns.google
Address:  2001:4860:4860::8888

> test-domaine.fr
Serveur :   dns.google
Address:  2001:4860:4860::8888

Réponse ne faisant pas autorité :
Nom :    test-domaine.fr
Addresses:  2001:41d0:2:927b::15
          5.196.43.182

I asked nslookup to use "2001:4860:4860::8888" as the DNS server which is Google IPv6 DNS (the modern 8.8.8.8).

So .. I'm not sure. Redirecting to ::1 didn't worked.
When I redirect to the pfSense IPv6 LAN IP ( 2a01:cb19:abcd:a6e2:92ec:77ff:fe29:392c ), it worked.
So, we can't redirect to ::1 ?
Ok, so be it.

aGeekhere

@johnpoz Here is some output

Both block 1 and 2 which is ipv4 seems to be working correctly as per the doc

Block 3 and 4 which is ipv6 does not look correct

Unless i have not understood the doc or missed something.

Update:
@Gertjan Ah so you were able to recreate the issue, could this be a bug?

Gertjan

@aGeekhere said in DNS Block and Redirect for IPv6:

Ah so you were able to recreate the issue, could this be a bug?

Maybe, maybe not .. not sure. read above, as I got it working by not using ::1.

@johnpoz I wasn't even trying to use 853 is DNS over TLS, as I can't map out that rabbit hole right now ......
Just good old plain port 53 DNS UDP and TCP.

aGeekhere

@Gertjan Because if you read here https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

It uses 127.0.0.1 as the ipv4 loopback address so i would have though that for ipv6 you would use ::1 as the loop back address. If ::1 does not work what can be used for a loop back address for ipv6?

Gertjan

@aGeekhere said in DNS Block and Redirect for IPv6:

what can be used

See above :

@Gertjan said in DNS Block and Redirect for IPv6:

When I redirect to the pfSense IPv6 LAN IP ( 2a01:cb19:abcd:a6e2:92ec:77ff:fe29:392c ), it worked.

aGeekhere

@Gertjan Ok going to try switching it from ::1 to pfsense LAN ipv6 address. Will report back with results.

Update: More testing is needed but i think that worked.

johnpoz

@aGeekhere might be related to having to be the same scope

Gertjan

@johnpoz

That's the same image / conclusion I posted above ^^

But I'm not using link-local "fe80" stuff.
I can see the IPv6 DNS port 53 traffic using packet capturing.
It's the IPv6 GUA = the ddevice's LAN IPv6 being used.

Anyway, redirecting to ::1 is not what worked before like using 127.0.0.1. ...

Maybe I'll use AI for this one

johnpoz

@Gertjan oh I missed that - my bad.