The very nature of the product means that false positives are possible. It takes time, and tinkering, to come up with a result you like. Adguard Home and Pi-hole are no different in that regard. There will always be some sort of trade-off involved, no matter which approach you take to content-blocking.
Per my PM, I think the vanilla config files you have in your repo need possibly one - and only one - change:
In /etc/config/network, move option type 'bridge' from config interface 'kids_lan' to:
config device
option name 'br-kids_lan'
I believe the rest of your repo's config is good enough, and I think that you can achieve your objective without DNAT and custom ports. I suggest going back to your repo and picking up from there, rather than trying to unpick where you are now.
This was the lab I set up in EVE-NG:
And, using your vanilla config files for dnsmasq, adblock, and https-dns-proxy, I got these results when testing the ad-blocking / content-filtering:
The Adult VM shows an interstitial advert:
The Kids VM does not:
Granted, my lab doesn't have Wi-Fi so I had to adjust the interface assignments in /etc/config/network to get connectivity but, as noted above, I think you're almost there. I think one change to the interface/device definitions for the kids_lan should sort you out.
==//==
Later edit:
As noted above, I think your vanilla repo config is almost there, with only one network definition change needed.
That said, I've been banging the drum for alternatives, so I had intended next to prove how Adguard Home would make this easier, but I hit a snag:
Adguard Home does not - yet - support multiple subnets for DHCP. I had forgotten this; it was the reason why I don't use it for DHCP in my own network. And it doesn't look like support is coming any time soon. That's... unfortunate.
However, dnsmasq - as you already know - does support multiple subnets. You're familiar with dnsmasq already, judging by the configurations you've implemented so far. And dnsmasq underpins Pi-hole, should you wish to investigate Pi-hole.
My own setup is this:
dnsmasq handles DHCP for multiple subnets, and local DNS. It then forwards all other queries to Adguard Home, for content blocking. AGH then in turn forwards all remaining queries to Unbound for external resolution. Unbound is what's called a "recursive resolver". It doesn't rely on my ISP's own DNS servers; rather, it goes off and queries the Root Servers directly and then drills down from there.
You're already familiar with redirecting to 127.0.0.1#xxxx so my setup oughtn't to seem that unfamiliar.
Yes everything works as it is now at the home router dns hyjackkng,doh, adblock, ban ip, and sqm qos for both kids and adults.
One problem is that I only have one lan and my access points dont support vlan.
And here lie's my problem, in my workshop down the farm and in the garage I can only host the adults lan and i can only either block the kids or allow them on the adults network.
The idea of seperate ports is to force the adults with known fixed mac adresses via ipsets to use the adults dns using a nonstard port so adblocking is active for everything else reguardless of the interface they attatch to.
The bridge you mention works as it is and i dont think that will fix my port issue.
I think there is a bug it seems alternate dns ports does not seem to work with multiple dnsmasq instances and it is worrying as to why port 53 is not mirrored on the kids lan when it is listed as a bound interface.
Okay... I might possibly have some more encouraging news for you.
I just set up a very rudimentary test, based on using the MAC address in an ipset directive.
I configured a DNAT rule using the MAC address ipset, redirecting DNS queries received on the kids' LAN to the DNS listening on the adults' LAN, along with a corresponding firewall rule (also using that same MAC ipset) to permit the traffic. Both rules were necessary: one to redirect, and the other to permit.
Then I set up a subsequent blanket "deny all DNS on the kids' LAN" rule, just to prove the concept.
The objective of the test was to prove that:
- I could get the MAC address ipset to work successfully in a firewall rule, and;
- The Adult device still got working DNS even when on the Kids' LAN, but all other devices on the Kids' LAN did not get working DNS.
As I indicated yesterday, I believe your vanilla configuration (apart from the incorrect placement of the 'bridge' definition) is good enough: it should be possible to get this to work with each dnsmasq instance bound to one interface on port 53, without conflicts.
On to the test:
This is the lab setup in EVE-NG:
As you can see, the Adult VM is joined to the Kids' LAN.
Here are the corresponding firewall entries:
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'lan2'
list network 'lan2'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
[...]
config forwarding
option src 'lan'
option dest 'wan'
config forwarding
option src 'lan2'
option dest 'wan'
[...]
config ipset
option family 'ipv4'
list match 'src_mac'
list entry '50:00:00:02:00:00'
option name 'Adults'
Note: 50:00:00:02:00 is the virtual MAC assigned to the "adult" VM instance in EVE-NG.
config redirect
option dest 'lan'
option target 'DNAT'
option name 'Adults DNS'
option src 'lan2'
option ipset 'Adults'
option src_dport '53'
option dest_ip '192.168.1.1'
option dest_port '53'
config rule
option name 'Adults DNS on Kids LAN'
option src 'lan2'
option ipset 'Adults'
list dest_ip '192.168.1.1'
option dest_port '53'
option target 'ACCEPT'
config rule
option name 'Block outbound DNS on Kids LAN'
option src 'lan2'
option dest_port '53'
option target 'REJECT'
option dest '*'
config rule
option name 'Block internal DNS on Kids LAN'
option src 'lan2'
option dest_port '53'
option target 'REJECT'
(I'm aware I stuck with "lan" and "lan2" rather than "adults" and "kids", but the principle stays the same.)
And here are the results of trying to perform some DNS resolution from the Adult device when on the Kids' network...
And here are the results from the Kid device on the same network...
As you can see, even on a different subnet the Adult device (identified by MAC address) got working DNS resolution. So you were on the right track by considering a MAC address ipset.
You should be able to take the above test and adapt it to your vanilla repo config without any fiddling with non-standard ports; just two dnsmasq instances, each bound to its own interface on port 53.
And thank you for prompting me to look further into ipset and its capabilities. I learned something!
2 Likes
it looks like this is a workable solution.
Only problem I can't do a not list match adults and match random mac adresses.
Not with your proposed approach, no. Any matching requires known data.
However, you might be able to adopt an "all other devices" approach.
Match against the devices you do know, to apply one particular policy for "known" or "approved" devices.
Then for any devices which can't be matched, have a separate default fall-back policy which applies to them.
You could, for example, take this approach on both networks, to account for kids' devices (or any unknown devices) on the Adults LAN:
Kids LAN:
Match against known MAC ipset? DNAT to Adult DNS without filtering
All other devices? Get Kids DNS and filtering
Adults LAN:
Match against known MAC ipset? Get Adult DNS without filtering
All other devices? DNAT to Kids DNS and get filtering
1 Like
I think that will be my approach but going off the adblock report it seems adblocking is not active on devices forwarded to the kids lan DNS with applying redirects to port 53 and if so it may be a waste of time and I might have to find another solution.
I have to test it further it might be that it is just not capturing the reporting, I might have to ask the author of adblock but I'm not currently sure.