Clients able to obtain DHCP addresses despite firewall rules

[hypernova]

I have the following firewall rules in place on the input chain.

add action=accept chain=input comment="accept established, related, untracked" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept icmp" protocol=icmp
add action=accept chain=input comment="accept from LAN" in-interface-list=LAN
add action=accept chain=input comment="accept from PUBLIC_LAN" disabled=yes in-interface-list=PUBLIC_LAN
add action=drop chain=input comment="drop everything else"

Note that the rule associated with the PUBLIC_LAN interface group is disabled.

Clients using the PUBLIC_LAN interface are able to obtain IP addresses via DHCP. I find this surprising, as I thought the input chain rules would prevent this.

Is someone able to clarify the situation? Thanks in advance

[CGGXANNX]

As I wrote yesterday in your previous thread: Is it a good idea to explicitly block ports for running services from WAN? If so, how? - #9 by CGGXANNX, DHCPv4 is not affected by the usual firewall filtering. The reason is because the DHCP client and server have to use special raw sockets. For more details you can read this past discussion:

BOOTP/DHCP bypasses NAT firewall

My MikroTik router acquires dynamic WAN IP from ISP even when I set input chain to drop all traffic from WAN and set output chain to drop all traffic to WAN. How is that possible? Such rules should be blocking all layer 3 packets to router from WAN and from router to WAN. That includes UDP ports 67 and 68 used for BOOTP/DHCP. If those ports are blocked, then how can router acquire dynamic WAN IP address from ISP?

Instead of trying to block with the firewall, just don't put the IPv4 DHCP Client or Server instances on the interfaces of the PUBLIC_LAN list. Who forced you to enable the instances on those interfaces?

[hypernova]

Ahh of course. DHCP uses raw sockets.