I’m afraid I know just enough to think an answer is correct but not enough to vet it completely or understand its reasoning.
Is 0/24 wrong?
0/24 only matches 0.0.0.0 - 0.0.0.255 … just 256 addresses.
0.0.0.0/0 is what matches the whole IPv4 address space.
I’ll change it, thank you
Unfortunately that error probably would account for my larger issue: the inability to have an lxd container using lxdbr0 answer requests made to the host computer on udp/tcp 53 despite what appears to be correct forwarding rules.
to understand this better, the number after the / is how many bits to compare between the rule and the packet’s destination address. so /0 basically means don’t compare the address at all and /32 means to compare the whole address. in IPv6 we need /128 to compare the whole address.
Very cool, thank you!
As as been very well explained while I was elsewhere, you are unfairly limiting your DNS server here.
I think your ufw rule looks like
to 0.0.0.0/24 port 53
while mine looks like
to any port 53
‘any’ is a convenient nickname for 0.0.0.0/0
I have never thought of using lsof to debug network accesses. What does it bring ? ufw log is showing your directly what is rejected.
If all else fails, tcpdump is the last recourse help.
if you are in doubt, you can also do
sudo ufw default allow routing
if it works, your routing rules are wrong. You should always remember that what is in before.rules is ‘PRErouting’, then comes ‘routing’. Both should accord to get your packets to go where you want them. You can also make your life simpler and keep default routine on at all times, of course. Probably many people are just doing that.
These are two most prevalent (by a long shot) entries in my ufw log:
Jun23 07:34:44 KubuntuOptiPlex3040 kernel: [52416.551093] [UFW BLOCK] IN=enp2s0 OUT= MAC=18:66:da:0f:e7:f7:b0:2a:43:ba:27:7d:08:00 SRC=192.168.86.1 DST=192.168.86.100 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=25053 DF PROTO=TCP SPT=48556 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
Jun 23 08:07:34 KubuntuOptiPlex3040 kernel: [54386.539237] [UFW BLOCK] IN=lxdbr0 OUT= MAC=fe:08:ae:ca:67:f9:00:16:3e:3a:e4:5c:08:00 SRC=10.96.103.127 DST=10.96.103.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=25796 DF PROTO=UDP SPT=46776 DPT=5351 LEN=20
As always, I am not entirely sure what is being said. It doesn’t even appear that anything is knocking on port 53 despite pointing the router’s DNS field directly at “192.168.86.100”
Err, this is beginning to look like a discussion of ufw, it’s drifting a bit off this forum subject.
Let’s pretend that it’s to avoid you any mistake in interpreting this as something related to your problem of DNS in LXD container…
First line is a TCP (proto=tcp) connection attempt (SYN) from 192.168.86.1 (looks like a typîcal router address but I can’t know really) to 192.168.86.100 (that’s probably your ethernet interface) on port https (DPT=443) and get blocked by the default blocking input rule.
Second line comes from a container at 10.96.103.127 (that’s not your Pihole I think it was 252) to the LXDBR0 bridge on port 5351 with protocol UDP (connecton less). Some app tries to connect to the internet (probably) and is blocked by the default routing rule. 5351 is multicast DNS, not sure what could do that, probably some system package called avahi that’s totally redundant with a DHCP server or fixed IPs (the two most commonly configurations used for very small networks)
Nothing related to DNS here, to check if DNS is blocked you should search for DPT=53 or SPT=53.
If you don’t see such packets in UFW log, they are probably going in or out…
I appreciate the response and I think you are quite right about the subject drifting. I’ve been working on this for bits and pieces of a month. If I don’t get it done tonight I think I may just take a few weeks off. Thank you, again. Cheers.