DNS Block and Redirect for IPv6

aGeekhere

Blocking External Client DNS Queries
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html

Redirecting Client DNS Requests
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

Any info on how to also do this for IPv6 ?

Gertjan

@aGeekhere said in DNS Block and Redirect for IPv6:

also do this for IPv6 ?

Copy the block rule, and change :

= IPv4 for IPv6.

The "Redirecting Client DNS Requests" IPv6 counterpart : change localhost "127.0.0.1" for it's IPv6 version "::1".

aGeekhere

@Gertjan That is what i thought however

However i get hits from the reject rule in the logs
LAN [2403:5801:13b9::220]:55984 [::1]:53 UDP

Gertjan

@aGeekhere

The first image : I would (tm) re order the rules.
First : the pass rule for "ok" traffic : DNS requests from a LAN IPv6 device to the pfSense LAN IPv6.
So : place your second rule at the top.
Next : If the traffic didn't match the first, the NAT rule will all TCP/UDP IPv6 destination port 53 to internal pfSense "::1:53"

NAT rules :

Btw : take note : I DNS redirect DNS on my captive portal, and a pfSense captive portal is 'IPv4' only, so my IPv6 DNS redirect rules is a demo here, as I can't really test it.
Also, be ware of the "!" : DNS traffic that is send to the correct pfSense interface is not NATted as there is no need. This means obnly traffic from a device on your network LAN which sends DNS requests to a device not being member of the LAN interface, will get NATted.

This probably explains why this first = IPv6 - LAN firewall rule :

which is the firewall rule attached to the NAT rule, doesn't trigger/match any traffic.
All my devices that use IPv6 are behaving correctly, and ask "pfSense" for their DNS needs.
( I guess ) so the NAT rule doesn't get matched = not get used.

@aGeekhere said in DNS Block and Redirect for IPv6:

LAN [2403:5801:13b9::220]:55984 [::1]:53 UDP

What rule was hit ?
Not this one :

as the counters are '0'.

aGeekhere

@Gertjan

Made the change

This is what is getting hit

and in the logs are lots of
IP6 DNS Reject (1752636706) [2403:5801:13b9::220]:55984 [::1]:53 UDP

Gertjan

@aGeekhere

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