I'm curious about what you think. I believe the logging of dropped/rejected incoming packets other than the WAN interface doesn't work.
All my interfaces have this option
option log '1'
All reject log entries originate from WAN. Yet I know there where other rejects happening, too.
When I look at nftables there is only a chain called reject_from_WAN but there is no reject_from_MGMT for example for my MGMT interface.
This is a screenshot from my MGMT Firewall zone setting:
For the creation of that chain the INPUT policy for the MGMT zone must be set to REJECT, or there must be at least one traffic rule with src MGMT -> dest Device and target/action set to REJECT.
The logging rules will not be created until you attach an interface to the zone.
I'm especially interested in logging rejected forwarding packets rather than input. That's why my input is set to Allow and forward to Reject.
For testing I configured a device in "Covered devices". The resulting nftables did not change though.
The log option does not really apply to inter-zone forwarded traffic due to the nature of the chain setup.
Log rules are only hit for:
dropped/rejected input traffic on a zone
dropped/rejected forward traffic among interfaces of the same zone (in the majority of cases, zones only have one interface)
dropped/rejected output traffic on a zone
Traffic from one zone to another which does not match any of the specific whitelistings will end up in the generic handle_reject chain or the drop policy of chain forward. The per-zone log options do not really apply there since those locations are not zone specific.
I guess the ruleset generation could be extended to add final log rules to forward_$zone chains in case the global forwarding policy is either reject or drop but this is not the case right now (and was not supported in fw3 either).
Edit: Here's a lightly tested patch that should implement the behavior you were expecting:
You should be able to add the change locally to /usr/share/firewall4/templates/ruleset.uc on your system. Make sure to make a backup of the original file before editing it.
No, not ruby. But the template tag syntax is inspired by Jinja.
Yeah, you likely added the modification at the wrong spot, at least it works locally here. I added the complete modified file as Github gist here, so you can try replacing the entire file:
@jow A different logging issue is the re-use of the name as the log prefix. Without a trailing space in the log prefix text, the name runs into the rest of the log message.
Before (rule name "DNS Intercept"):
Sun Sep 25 17:32:19 2022 kern.warn kernel: [66718.246809] DNS InterceptIN=eth0 OUT= MAC=...