Project

General

Profile

Actions
Copy link

Regression #13754

closed

DHCPv4 rules are not automatically created

Added by Marcos M almost 2 years ago. Updated almost 2 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.

Actions
Copy link
 #1

Updated by Marcos M almost 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
Actions
Copy link
 #2

Updated by Marcos M almost 2 years ago

  • Description updated (diff)
Actions
Copy link
 #3

Updated by Jim Pingle almost 2 years ago

  • Subject changed from DHCPv4 rules are not automatically created. to DHCPv4 rules are not automatically created
Actions
Copy link
 #4

Updated by Marcos M almost 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #5

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

Actions
Copy link
 #6

Updated by Chris W almost 2 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #7

Updated by Jim Pingle almost 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

Actions
Copy link
 #8

Updated by Marcos M almost 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

Actions
Copy link
 #9

Updated by Marcos M almost 2 years ago

  • Status changed from Pull Request Review to Feedback
Actions
Copy link
 #10

Updated by Jim Pingle almost 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.

Actions
Copy link

Also available in: Atom PDF