I know 
My question was on the "sed" string: I don't think it works as intended.
The sed string works as intended, to create the custom chains in the ip6tables from iptables.
Then it is up to you to add the redirect in the proper chain in ip6tables.
Does that cover you?
Have you tried it? Not just looked at it, like I also did at first
I have copypasted the whole thing and it doesn't change anything, because on the current 19.07.2 this
uci -q delete firewall.dns_int
uci set firewall.dns_int="redirect"
uci set firewall.dns_int.name="Intercept-DNS"
uci set firewall.dns_int.src="lan"
uci set firewall.dns_int.src_dport="53"
uci set firewall.dns_int.family="ipv4"
uci set firewall.dns_int.proto="tcp udp"
uci set firewall.dns_int.target="DNAT"
becomes:
-A zone_lan_prerouting -p tcp -m tcp --dport 53 -m comment --comment "!fw3: Intercept-DNS" -j REDIRECT --to-ports 53
-A zone_lan_prerouting -p udp -m udp --dport 53 -m comment --comment "!fw3: Intercept-DNS" -j REDIRECT --to-ports 53
Then sed looks for either DNAT or SNAT, finds none and does not output MASQUERADE for IPV6.
I'm trying to understand if I have made a mistake somewhere, if I am missing something or somehow the guide was written for an older version of openwrt where the uci stanza above would be expanded as expected by sed. (EDIT: nope, see later)
EDIT: I have also tried "sed" by itself, feeding it input with DNAT or SNAT, but no luck, I'm stuck.
I am actually using it. If you compare the output between iptables-save -t nat and iptables-save -t nat | sed -e "/\s[DS]NAT\s/d;/\sMASQUERADE$/d" you'll verify that all DNAT, SNAT, and MASQUERADE rules are removed. So what is restored to ip6tables is the skeleton of the custom chains and whatever rules were created before you ran that, other than SNAT, DNAT, and MASQUERADE.
I am running my dns-hijack6 custom scripts after I run this firewall.nat6, so I need to create the DNAT and MASQUERADES in the dns-hijack6. I guess if you had run already the REDIRECT before, then it would be transferred over when firewall.nat6 runs, since REDIRECT is not a keyword in sed to be omitted.
1 Like
Ahhhhh, thanks! See, I was indeed missing something 
(old habit of using sed only to transform strings, not to remove them altogether... as a consequence, I didn't look at other lines, just those related to DNS)
I had a look at the post you linked but I haven't tried it, yet.
1 Like
Ok, I have the same results now. I have tried changing
option proto 'tcp udp'
to
list proto 'tcp'
list proto 'udp'
like I have in other rules but it doesn't make any difference (no, this time, I used diff, not my eyes!)
Yup, I also tried asking google via IPV6 about a local domain name and I got an answer, so the queries are being correctly intercepted.
Did you solve your original problem with Netflix? In my case it seems to be working fine, when I query google for netflix I only get answers with IPV4.
@trendy funny thing happens, though:
nslookup www.netflix.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: fdcf......
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Tempo scaduto per la richiesta a UnKnown
However if I run this same query against the non-ULA IPV6 address it works just fine.
According to netstat, unbound is listening for all interfaces:
netstat -a |grep domain
tcp 0 0 0.0.0.0:domain 0.0.0.0:* LISTEN
tcp 0 0 :::domain :::* LISTEN
udp 0 0 0.0.0.0:domain 0.0.0.0:*
udp 0 0 :::domain :::*
I can get an answer using the ULA-address on the router itself, not on the laptop (with firewall off) or on my phone. Weird.
I remember I came across something similar lately. User was complaining that Android device does not work when advertised nameserver is a ULA address.
1 Like
Oh, nice, not 
I'm still puzzled that Windows is also having trouble with that (direct nslookup) but now I see that my Debian desktop barfs, too: a dig to the ULA address returns the "reply from unexpected source" error, which you already encountered.
I have tried with this line:
ip6tables -t nat -A POSTROUTING -d <ULA-address of router> -p udp -m udp --dport 53 -m comment --comment "!fw3: Intercept-DNS - lan" -j MASQUERADE
but I still get the message: it seems the issue is the port number of the reply, the host is correct.
I guess I need a closer look at the rest of your script and account for the fact that I don't have an external DNS server. Out of curiosity, do you reckon it would be possible to express that script only through UCI?
You need the DNAT too, not just the MASQUERADE.
I am not sure how to express the redirect in UCI.
1 Like
To no one in particular: simply blocking outside DNS servers sure is a lot easier
It is, however you'll have some delay each time the hosts are going to reach out to them.
Thing is, I was trying to solve a problem for the fun of it, not because I had noticed this delay.
I should first log the rejections then identify the devices, if any, and only then try to do something about it.
EDIT: apparently the Android phones are not making much of a fuss, the lone attempt I have seen was from the xiaomi tv box, I can live with that
The typetransparent classification is correct (original design goal) for filtering out responses like AAAA and CNAME that cause you grief. That will force Netflix to use IP4. You can also use IPSET to load the firewall with IP6 resolved to "that domain" and block them.
Ensuring your clients only use your Unbound services on your router is different. First you need dnsmasq and odhcpd to announce the router. They may not do this right if dnsmasq isn't treated as primary. Make sure to set option dns ... to your router under UCI dhcp. Second you need to block deviant clients from going to google, quad9, and such. You can use firewall or routing rules to block, black hole, or even funnel queries to Unbound (i.e. all destination ports 53,853 from any LAN on any protocol must only go to Unbound).