Help with dnsmasq instances

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 :smile:

Hello @vgaetera :slight_smile:
i did everything from the how-to, but i can't get it to work so i need further help :frowning:
(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 :slight_smile: 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.*/*

damn this is SO long :slight_smile:

thanks!

2 Likes

looking at your config, i think I underestimated you :slight_smile: (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 :frowning:

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 :slight_smile: 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 :frowning:
indeed, i could not understand the "race condition" part of the howto, but i copied it anyway :slight_smile:

1 Like

i just copied and pasted it, even if i don't know what i'm doing :slight_smile:
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 :frowning:

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 :slight_smile:
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
  1. 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)

  2. 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
  • Solves the race condition with firewall, dnsmasq and ipset-dns startup timing.
  • Custom files to back up and survive Sysupgrade.

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 :slight_smile:
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 :slight_smile: