Iptables rule to capture DHCP I/O fails

I have stumbled upon a peculiar issue with Iptables. I am not seeking a solution to a problem, but an explanation of some strange behaviour of iptables.

My platform is Ubuntu 22.04.2 LTS with 5.19.0-43-generic kernel, using a wireless interface "wlp1s0" (Intel Wi-Fi 6 AX200 M.2) managed by NetworkManager.

While trying to optimize my laptop iptables configuration for existence on insecure networks like free airport WiFi nets, etc. I started looking into how I could limit DHCP traffic. To this end I first started with some rules to log DHCP activity to see how it worked and compared to the IETF DHCP RFC:

So in table "filter" I added the following rules:

-A INPUT -i wlp1s0 -p udp --sport 67 --dport 68 -j filter-log   
-A OUTPUT -o wlp1s0 -p udp --sport 68 --dport 67 -j filter-log
-A filter-log -m limit --limit 5/min --limit-burst 10 -j LOG --log-prefix "[MYFW FILTER-LOG] "
-A filter-log -j RETURN

INPUT channel default policy was "DROP"

After doing that I then provoked the network to re-negotiate a connection like this:

1. sudo sysemctl restart NetworkManager
2. use NetworkManager to "forget" my connection and then re-establish anew
3. waited for an automatic renewal of the lease (12 hours after establish connection)

Now, much to my surprise I saw no logging and "iptables -L -nv -t filter" confirmed that there were zero counts, for scenarios 1+2, but the automatic renewal showed up in logs as expected. I checked with "Wireshark" and indeed it showed the expect DHCP commands "Discover", "Request" and "Ack", and it had filled in all the expected option fields as described in the RFC, so the communication did happen as expected, but the logging in iptables just did not. When I moved the "INPUT" rule to PREROUTING channel using filter "raw", then the DHCP reply from the server showed up in iptables, but I could not find any rule to get iptables to log the outgoing initial DHCP "Discover" or "Request", regardless that Wireshark showed that it happened.

The analysis showed that I do not need any specific INPUT channel ACCEPT rule for DHCP since it is initiated by the laptop and the reply is accept by a "RELATED,ESTABLISHED" rule.

But for my understanding it would be good if anyone could explain the described behaviour.

AFAIK The DHCP protocol has some odd requirements and to work properly clients and servers typically (prefer to) open a raw network socket rather than or in addition to using the conventional network stack. Background: https://kb.isc.org/docs/aa-00378 and for example https://stackoverflow.com/q/14774668/2952385

Matching DHCP protocol requests and replies therefore requires filter rules in the raw tables. With raw sockets packets get injected/received directly, they don't pass through the higher level TCP stack and can't be observed in the default filter table.

I find the diagram below from https://stuffphilwrites.com/2014/09/iptables-processing-flowchart/ useful for context on where netfilter/iptables rules need to be applied.