Regression #13754
closedDHCPv4 rules are not automatically created
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 about 2 years ago
- Tracker changed from Bug to Regression
- Status changed from New to Pull Request Review
- Priority changed from Normal to High
- Release Notes changed from Default to Force Exclusion
Updated by Jim Pingle about 2 years ago
- Subject changed from DHCPv4 rules are not automatically created. to DHCPv4 rules are not automatically created
Updated by Marcos M about 2 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 46c9508efb21a8c809dda5b1cc47a4218399a04f.
Updated by Chris W about 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 about 2 years ago
- Status changed from Resolved to New
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 about 2 years ago
- Status changed from New to Pull Request Review
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 about 2 years ago
- Status changed from Pull Request Review to Feedback
Applied in changeset c0d7519df5dc1632ba9f2791ab377bdc19f45105.
Updated by Jim Pingle about 2 years ago
- Status changed from Feedback to Resolved
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.