Does DHCP Relay require firewall rule?

mh2112

@Gertjan I made a typo. The DHCP servers are on my WAN. Thanks for catching it.

mh2112

I also see these in my pfSense DHCP logs:

Jun 29 08:43:24 dhcrelay 3 bad IP checksums seen in 5 packets 
Jun 29 08:43:27 dhcrelay 4 bad IP checksums seen in 7 packets 
Jun 29 08:43:41 dhcrelay 4 bad IP checksums seen in 7 packets 
Jun 29 08:43:41 dhcrelay 3 bad IP checksums seen in 5 packets

Gertjan

Try :

Available in System > Advanced > Networking

mh2112

Great, that took care of the "bad IP checksums". I still see port 67/udp traffic blocked from DHCP servers C and D to my LAN interface though. Not sure why that would be happening. My LAN interface has a static IP number.

Gertjan

A theory :

If the checksum was wrong, packet content might be scrambled.
The client might not understand de server reply, or the server might not understand the client's request and neglect it.
Is "dhcrelay 3" and "dhcrelay 4" related to DHCP servers C and D ?

You say ; blocked.
You have the blocked firewall log rule , The firewall rule number ? Compared that number with "the list" ? ( /tmp/rules.debug)

mh2112

@Gertjan said in Does DHCP Relay require firewall rule?:

Is "dhcrelay 3" and "dhcrelay 4" related to DHCP servers C and D ?

Yes, I think so. I didn't realize pfSense labeled the DHCP servers 1-4, so I called them A-D in this post.

You say ; blocked.
You have the blocked firewall log rule , The firewall rule number ? Compared that number with "the list" ? ( /tmp/rules.debug)

I don't fully understand. Traffic from DHCP servers 3 & 4 is blocked by the default rule which blocks IPv4 traffic. Also, nice tip about /tmp/rules.debug. I did not know about that file.

I now have support from Netgate, so I'll pick this up with them.

Gertjan

Please reflect back here what you found out.

somerino

@mh2112 @Gertjan

I've got the following rules on the DHCP Server interface (all UDP protocol)

1.Allow from DHCP Server (67) to Gateway-IP-Address field (GIADDR) (67) [I think in Cisco language, that's the IP-Helper address). in simpler words, the gateway of the VLAN you're needing the DHCP address.
2. Allow DHCP Server (67) to 255.255.255.255 (68) to offer an address.

On the VLAN Interface without a DHCP Server

Allow VLAN_Interface net (68) to DHCP Server (67). I think that's for renewing or extending the lease time.
Allow VLAN Interface net (68) to This Firewall (67). To be honest, I'm not entirely sure, why this is needed, but hey, I got traffic at the counter :D

Gertjan

@wellcomefit said in Does DHCP Relay require firewall rule?:

1.Allow from DHCP Server

Look at the file /tmp/rules.debug - these are the rules loaded into 'pf', the firewall.

Search for

# allow access to DHCP server on

You'll find as many occurrences as you have LAN type interfaces.
DHCP incoming (into the LAN) is passed by default.

@wellcomefit said in Does DHCP Relay require firewall rule?:

Allow DHCP Server (67) to 255.255.255.255 (68) to offer an address.

The traffic generated by the DHCP server does not use the LAN firewall rules.

@wellcomefit said in Does DHCP Relay require firewall rule?:

Allow VLAN_Interface net (68) to DHCP Server (67). I think that's for renewing or extending the lease time.

There is now renewing if there is no DHCP server listening (on pfSense).

somerino

@gertjan

Thanks for the advice.
I knew there was a rule needed for this, otherwise it makes no sense for me :P
The rules I have mentioned in my previous post, show hits on the traffic counter.

Gertjan

@wellcomefit said in Does DHCP Relay require firewall rule?:

show hits on the traffic counter

Rules are not matched in parallel, but top to bottom.

Because the 'non-GUI' rules (hidden rules) are added after your rules in the GUI.
The last bottom rule is always a 'block all'.

If you add a GUI DHCP pass rule, it will get match before the hidden DHCP rule kicks in.

johnpoz

@gertjan said in Does DHCP Relay require firewall rule?:

Because the 'non-GUI' rules (hidden rules) are added after your rules in the GUI.

I don't believe that is the case... You would actually have to check the rules to validate. But hidden rules are placed first I believe.. With the dhcp rules when you enable dhcp server, they are at the top. Or users could block dhcp with a gui rule, which would be problematic.

I would think it would be the same if you enable dhcp relay - I would think they would be at the top of the rules list when enable it, even when hidden.

I have not dug that deep to be sure, but I would think it better for hidden rules that are created to be at the top of the list. Other then the default deny ;) which do not have "quick" set, while rules like dhcp hidden rules all have quick set on them.

https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html

If you cat /tmp/rules.debug you will the dhcp server rules are above the section of user rules

# allow access to DHCP server on "interface"

then below those sections that you will see

# User-defined rules follow

Gertjan

@johnpoz said in Does DHCP Relay require firewall rule?:

I don't believe

Guess what : me neither ;)
If the build in DHCP rules came first, then the DHCP traffic GUI rules created by @wellcomefit would not get a hits/match.

I looked at :

pfctl -s rules

this shows the principal block rules :

block drop in inet all label "Default deny rule IPv4" ridentifier 1000000103
block drop out inet all label "Default deny rule IPv4" ridentifier 1000000104
block drop in inet6 all label "Default deny rule IPv6" ridentifier 1000000105
block drop out inet6 all label "Default deny rule IPv6" ridentifier 1000000106

nearly at the to of the rule set.

GUI lines are nearly at the bottom.

No rule numbers like ipfw or iptables.

Strange. I'm using pfSEnse but only Sense makes sense to me. I should study 'pf'.

johnpoz

@gertjan those do not have "quick" set so all the other rules are evaluated first no matter the order - when rules are set "quick" is when order matters.

Gertjan

@johnpoz

I knew (something) about 'quick'.

The FreeBSD pf documentation says : look here PF FAQ and there I find a lot of info.

The quick Keyword
As indicated earlier, each packet is evaluated against the filter ruleset from top to bottom. By default, the packet is marked for passage, which can be changed by any rule, and could be changed back and forth several times before the end of the filter rules. The last matching rule wins, but there is one exception to this: The quick option on a filtering rule has the effect of canceling any further rule processing and causes the specified action to be taken. Let's look at a couple examples:

I stand corrected