Added by Marcos M almost 2 years ago. Updated almost 2 years ago.
100%
Description
Tested on 23.01.a.20221213.1812.
With DHCPv4 Server enabled, rules allowing DHCP traffic are not automatically created.
Updated by Marcos M almost 2 years ago
Updated by Jim Pingle almost 2 years ago
Updated by Marcos M almost 2 years ago
Applied in changeset 46c9508efb21a8c809dda5b1cc47a4218399a04f.
Updated by Chris W almost 2 years ago
Looks good. This is present in Firewall-Generated Ruleset.txt:
# allow our DHCP client out to the WAN pass in quick on $WAN proto udp from any port = 67 to any port = 68 ridentifier 1000000461 label "allow dhcp replies in WAN" pass out quick on $WAN proto udp from any port = 68 to any port = 67 ridentifier 1000000462 label "allow dhcp client out WAN"
23.01-DEVELOPMENT (amd64)
built on Wed Dec 14 06:05:14 UTC 2022
FreeBSD 14.0-CURRENT
Updated by Jim Pingle almost 2 years ago
Looks like these changes can cause a pf error if DHCP is enabled on an interface that is disabled. It's worth adding a check here before inserting the DHCP rule into the ruleset to ensure the underlying interface is enabled, and check if it has a valid IPv4 address on the interface as well.
See also: https://forum.netgate.com/topic/176536/rule-error-related-to-dhcp-vlan-prio
Updated by Marcos M almost 2 years ago
When filter_rules_generate() is called in this case, only enabled interfaces are parsed hence there's no need for an additional check. The issue here is due to a config access regression. Fix: https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/989
Updated by Marcos M almost 2 years ago
Applied in changeset c0d7519df5dc1632ba9f2791ab377bdc19f45105.
Updated by Jim Pingle almost 2 years ago
These cases all appear to be solved now, and no more errors/regressions in the ruleset or from config accesses that I can see. Also the user who reported that last rule issue says they no longer get the ruleset error they had, too.
Closing.