Project

General

Profile

Actions
Copy link

Regression #13754

closed
MM MM

DHCPv4 rules are not automatically created

Regression #13754: DHCPv4 rules are not automatically created

Added by Marcos M over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Marcos M
Category:
DHCP (IPv4)
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Force Exclusion
Affected Version:
2.7.0
Affected Architecture:

Description

Tested on 23.01.a.20221213.1812.

With DHCPv4 Server enabled, rules allowing DHCP traffic are not automatically created.

MM Updated by Marcos M over 3 years ago Actions
Copy link
 #1

  • 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

MM Updated by Marcos M over 3 years ago Actions
Copy link
 #2

  • Description updated (diff)

JP Updated by Jim Pingle over 3 years ago Actions
Copy link
 #3

  • Subject changed from DHCPv4 rules are not automatically created. to DHCPv4 rules are not automatically created

MM Updated by Marcos M over 3 years ago Actions
Copy link
 #4

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100

Applied in changeset commit:46c9508efb21a8c809dda5b1cc47a4218399a04f.

CW Updated by Chris W over 3 years ago Actions
Copy link
 #5

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

CW Updated by Chris W over 3 years ago Actions
Copy link
 #6

  • Status changed from Feedback to Resolved

JP Updated by Jim Pingle over 3 years ago Actions
Copy link
 #7

  • 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

MM Updated by Marcos M over 3 years ago Actions
Copy link
 #8

  • 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

MM Updated by Marcos M over 3 years ago Actions
Copy link
 #9

  • Status changed from Pull Request Review to Feedback

Applied in changeset commit:c0d7519df5dc1632ba9f2791ab377bdc19f45105.

JP Updated by Jim Pingle over 3 years ago Actions
Copy link
 #10

  • 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.

Actions
Copy link

Also available in: Atom