The MAC address 52:54:00:0c:d8:05 is the address of my machine. 10.100.100.5 is the address of my machine. 38:f9:d3:5c:84:b7 and 10.100.100.125 is a machine on my guest network. So this looks like a DNS reply from my machine to my client… but it was blocked!
So why did this hit the outgoing filter?
For completeness
# Clear out all the rules
flush ruleset
# Create empty structures
add table ip filter
# Define the 3 standard filters:
# INPUT: Traffic targeting this machine
# OUTPUT: Traffic originating from this machine
# FORWARD: Traffic goin through this machine
add chain ip filter INPUT { type filter hook input priority 0; policy accept; }
add chain ip filter FORWARD { type filter hook forward priority 0; policy accept; }
add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; }
# Log rules for input and forwarding
add chain ip filter LOGGER
# Logging rule for INPUT drops
add rule ip filter LOGGER limit rate 2/minute burst 5 packets counter log prefix "IPTables-Dropped: "
add rule ip filter LOGGER counter drop
# LAN can see everything
add rule ip filter INPUT iifname "ens2" counter accept
# Guestnet can DNS, DNS/TLS, DHCP, NTP
add rule ip filter INPUT iifname "ens8" tcp dport 53 counter accept
add rule ip filter INPUT iifname "ens8" udp dport 53 counter accept
add rule ip filter INPUT iifname "ens8" tcp dport 853 counter accept
add rule ip filter INPUT iifname "ens8" udp dport 853 counter accept
add rule ip filter INPUT iifname "ens8" udp dport 67 counter accept
add rule ip filter INPUT iifname "ens8" udp dport 123 counter accept
# IoT can DNS, DNS/TLS, DHCP, NTP
add rule ip filter INPUT iifname "ens9" tcp dport 53 counter accept
add rule ip filter INPUT iifname "ens9" udp dport 53 counter accept
add rule ip filter INPUT iifname "ens9" tcp dport 853 counter accept
add rule ip filter INPUT iifname "ens9" udp dport 853 counter accept
add rule ip filter INPUT iifname "ens9" udp dport 67 counter accept
add rule ip filter INPUT iifname "ens9" udp dport 123 counter accept
# Block all other incoming traffic and log it
add rule ip filter INPUT counter jump LOGGER
The really confusing bit is that the SRC/DST conflict in the same log line
Yeah, originally I just had a “drop” rather than a log entry and it was the non-zero count that made me wonder what machine was doing “bad stuff” so I added the logging rule to see what was going on.
And this just made me more confused because, as you say, it’s only on the input chain.
Looking at the counts now, I can see the numbers match; there are now 11 packets that hit the “jump to LOGGER” rule at the end of the input chain, and 11 packets passing through the log line, and 11 packets hitting the drop (all as expected, so nothing else is calling LOGGER). And this matches 11 entries in dmesg, all referring to the same machine.
The MAC address field in log output always has two address in it; e.g on my router/firewall I log incoming attempts to access my SSH server and the MAC field has the address of my machine and my ISPs gateway; e.g.
My MAC is 00:0d:b9:43:9c:cd; the ISP gateway is 42:a6:77:4d:c0:f2. I’m not sure what the final 08:00 is
II this is a race condition then it’s repeatable 'cos I see the same thing 11 times in the past 12 hours, all referring to the same machine! The race would not be in the LOGGING; previously I had a simple “drop” rule and that was showing packets hitting it, and that’s when I added the log rule to see what was going on.
The incoming packet being dropped was an “ICMP Port unreachable” (type 3, code 3) message and that packet was sent in response to a DNS answer my machine sent out; the original outgoing packet is inside the square brackets.
So my guess is the client machine may make DNS requests to multiple sources at the same time and when it gets a response from one of them it stops listening for any other responses, and so rejects any later “slower” packets.
And here we go; on this machine I can see this DNS query:
So, yeah, the client made the same request of two DNS servers, got a response from one and rejected the response from the other. And it was that rejection that got logged.
ct state { established, related } accept
meta l4proto { icmp, ipv6-icmp } accept
could be the ones that would allow the type 3, code 3 ICMP reply in. Particularly the “established, related” ought to cover majority of packets (the existing connections) and leave only the new connection attempts for the later rules.