Yes, apply the how-to as-is, only changing the source zone and the target:
uci set firewall.filter_fwd.src="iot"
uci set firewall.filter_fwd.target="ACCEPT"
uci set firewall.filter6_fwd.src="iot"
uci set firewall.filter6_fwd.target="ACCEPT"
uci commit firewall
/etc/init.d/firewall restart
And then remove the firewall forwarding from IoT to WAN.
In this case, you don't actually need the second Dnsmasq instance.
1 Like
thank you vgaetera, i'm not sure i got it, but i'll try to sort it out this weekend.
Indeed, if i can create a list of domains for the firewall rule, i could avoid the filter of the second dns instance.
Sadly, it's possible i'll need some more help, i'm sorry
Hello @vgaetera
i did everything from the how-to, but i can't get it to work so i need further help
(side note: the help page says that luci can manage this. It is not the case, luci seems to totally ignore ipset)
now, the domains i add to the list (i'd like to add..) simply can't get resolved, neither from clients, nor by the router itself. it seems the dns server @127.0.0.1:53001 is not even answering, indeed the lists are empty
i can't see anything strange or wrong from the output of the "troubleshooting" section of the howto, let me know if something specific can help me fixing this
Probably it's because i can't fully understand what single steps are doing..
- what is the firewall.ipset file doing? it seems to restart both ipset and dnsmasq, but based on what? a dnsmasq restart is breaking almost everything, so i'm not that happy to restart it often i assume this is called by the firewall, but when?
- what about the sysupgrade.conf file, that is never used in the howto?
- in the first part, domains are added to the dns instance, but at the end (for the pre-resolving) they are added to the firewall rules, what is correct? (i added them to the dhcp file)
Just to be sure, i assume the working mode should be: dnsmasq for the listed domains tries to resolve them sending the request to ipset-dns, that forwards the request to the default server, answers to dnsmasq with the resolved ip and updates the list. right?
so it seems it's just not answering, but it seems online
root@RUTTO:/mnt/sda1/tmp/adblock/dns# logread -e ipset-dns; netstat -l -n -p | grep -e ipset-dns
udp 0 0 127.0.0.1:53001 0.0.0.0:* 18800/ipset-dns
root@RUTTO:/mnt/sda1/tmp/adblock/dns# pgrep -f -a dnsmasq; pgrep -f -a ipset-dns
19082 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg03411c -k -x /var/run/dnsmasq/dnsmasq.cfg03411c.pid
18800 /usr/sbin/ipset-dns filter filter6 53001 4.4.4.4
Collect the diagnostics and post it to pastebin.com redacting the private parts:
uci show network; uci show wireless; uci show dhcp; uci show firewall; \
ip address show; ip route show table all; ip rule show; iptables-save; \
head -v -n -0 /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/*
looking at your config, i think I underestimated you (it is more complex than mine)
note1: your dnsmasq config seems to be missing the ipset-dns lookup config section of the guide (if you are still trying to do ipset-dns and not the more recent solution) aka... this section...
# Configure domains to filter
uci add_list dhcp.@dnsmasq[0].server="/example.com/127.0.0.1#53001"
uci add_list dhcp.@dnsmasq[0].server="/example.net/127.0.0.1#53001"
uci commit dhcp; /etc/init.d/dnsmasq restart
(so best to check each section of the guide 1 by one and ensure you have a similar section)
1 Like
i can't understand 90% of my config LOL
1 Like
Sorry, my fault.
In this dir option confdir '/mnt/sda1/tmp/adblock/dns'
i put a file with just an example domain in this way: server=/<test domain>/127.0.0.1#53001
As you can see from the logread of dnsmasq it is correctly read:
using nameserver 127.0.0.1#53001 for domain <example domain>
Obviously i also tried adding directly the option to the dhcp config file with same effect
1 Like
yes... it needs to be under that instance... (as opposed to the guide)... either in /etc/config/dhcp or as you have done in the masq format under confdir or similar...
(looks ok... sorry... my brain does not assimilate quickly if something is not in front of me)
(yes the 20|21 firewall rules were ok... different families they looked the same to me at first)
(at two mistakes... I will stop trying to help there... but syptoms are pointing to issues with the actual client requests reaching the router properly)
yes, i litterally copied and pasted every line of that howto i just edited details in the firewall rules (indeed, a name is doubled, but it is a typo, it's ipv4 vs ipv6)
1 Like
Firewall zone names are case-sensitive.
Also, you'd best enable bridging for the Guest and IoT networks to avoid race conditions:
uci -q delete network.Guest.type
uci set network.Guest.device="br-guest"
uci set network.IOT.device="br-iot"
uci -q delete network.guest_dev
uci set network.guest_dev="device"
uci set network.guest_dev.name="br-guest"
uci set network.guest_dev.type="bridge"
uci -q delete network.iot_dev
uci set network.iot_dev="device"
uci set network.iot_dev.name="br-iot"
uci set network.iot_dev.type="bridge"
uci commit network
/etc/init.d/network restart
That's another possible race condition.
1 Like
Good catch! Fixed, but same impossibility to resolve domains..
on the other hand, i lost you on the bridge topic
indeed, i could not understand the "race condition" part of the howto, but i copied it anyway
1 Like
i just copied and pasted it, even if i don't know what i'm doing
btw the point is the same, i cant get the listed domains resolved (also from my client on normal lan)
(and thanks for the bridge fix)
Try removing this and restarting the service:
If the issue persists, revert the Dnsmasq configs to factory defaults, only adding DHCP pools.
You can also disable Adblock, BCP38, banIP and QoS to isolate the problem.
1 Like
nothing, still no sign of life from the port 53001
at this point i think i'll try with @anon50098793 method, but i'm unhappy with not being able to make this work
you need to strip back your firewall to the bare essentials... or make a backup then try from scratch the same method just on the typical LAN... you have too many things going on to see whats happening clearly...
2 Likes
do you want to hear a fun story?
this is the command line used for ipset-dns
/usr/sbin/ipset-dns filter filter6 53001 4.4.4.4
and you know what? google does not agree withh me for their dns server address
Configure your network settings to use the IP addresses 8.8.8.8 and **8.8.4.4** as your DNS servers.
i was trying to debug ipset-dns, so i just tried changing the dns server and it works! shame on me
now just curious to see if also the firewall rule works..
Thanks guys!
Edit: Damn, it works!!
Still wondering what the /etc/firewall.ipsetdns
and /etc/sysupgrade.conf
files are for, but it works!!
3 Likes
-
is to ensure correct service state/coherency when implementing/messing with interfaces (they may also flush learned set entries so they don't get stale over time)
-
carries (1) to your next install as it is outside of /etc/config/
they may not be 'strictly' needed but for wiki guide certainly assist...
1 Like
thank you guys, it's perfect and i've just realized that sysupgrade.conf is the file i use to take my file to the new builds, it has a lot of stuff in it
i just need to add ipset-dns to my next build and everything is working.
thanks!
Edit: i also assume that ipset-dns can also work with https-dns-proxy, just using 127.0.0.1:5053 as dns server, right?
Still not planned, but i'd like to pass to dns over ssl in the future