Blocking Bogon IPv4 Networks on an Interface also blocks DHCP

[IsaacFL]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[-] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[-] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
With bogons blocked on an internal interface, DHCPv4 client is unable to connect.

The automatically generated rules for DHCP should not fall after the Block Bogon Rules.

Since DHCPv4 uses 0.0.0.0 as a source address, it gets blocked by the bogon rules before the "allow access to DHCP server" rule can pass it.

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce
Steps to reproduce the behavior:

1. Select "Block bogon networks" on an interface.
2. Go to the Firewall Rules for that interface, and expand Automatically generated rules
3. You will see the rules to allow DHCPv6 first, followed by the 2 Block bogon rules, then followed by the "allow access to DHCP server" rules.

Expected behavior
Bogons block rules should probably be the last auto generated rules.

Screenshots
Not sure how to post a screenshot

Relevant log files
N/A

Additional context
I don't normally select "block private" but during a test I saw that blocking private was also before the allow dhcp. That probably doesn't impact DCHP, but allowing DHCP should still be before blocking private addressess and bogons.

Environment
Software version used and hardware type if relevant.

OPNsense 20.1.7-amd64
FreeBSD 11.2-RELEASE-p20-HBSD
OpenSSL 1.1.1g 21 Apr 2020

[AdSchellevis]

I don’t think I agree here, if you choose to enable all bogon and/or private nets, from a security perspective it sounds a bit odd to allow it partially anyway.

If the intend of the toggles isn’t clear enough, I don’t mind accepting pull requests to better explain them (either in docs or in the help texts). Opening ports, which the toggles state are closed , will lead to questions further down the road, these are way harder to explain in my opinion.

[IsaacFL]

A valid option would be to block bogons from flooding other subnets and going out to WAN because they have no legitimate use going through the router. But allowing DHCP service in the router is considered a legitimate use.

In the current configuration this is not possible, so you must allow bogons out to the WAN to use DHCP locally.

I think that the expectation is if you turn on the DHCP service on the router, then the firewall allows the required traffic to the service. Even if you are blocking bogons from going elsewhere.

[IsaacFL]

I don’t think I agree here, if you choose to enable all bogon and/or private nets, from a security perspective it sounds a bit odd to allow it partially anyway.

I did some further testing, and if you turn off DHCPv4 service on an interface, then the DHCP rules do not get auto generated. So there wouldn't be a case of it being partially allowed, unless you explicitly enable DHCP service.

[AdSchellevis]

Some services auto generate rules indeed, personally I would rather see people opening ports explicitly, but since that’s difficult to explain in some cases for functionality we inherited, we’ve chosen to increase visibility of these rules.

If I’m not mistaken you can still allow the DHCP traffic with a quick rule, which should be good enough. Trying to avoid this would either run into an endless discussion which priority the bogon/private nets should have or sorting them at the bottom (lowest prio) leading to the concerns raised earlier.

[IsaacFL]

The block bogons rule is quick, so I don't think it is not possible to do what you say for DHCP.

block in log quick on hn4 inet from {<bogons>} to {any} label "15f2d7ab2c9ee21a4d232881700f30f9" # Block bogon IPv4 networks from VIRT
Also the DHCP are already quick.
pass in quick on hn4 proto udp from {any} port {68} to {255.255.255.255} port {67} label "7a4bc76014310d96b161abe7b1672f4c" # allow access to DHCP server pass in quick on hn4 proto udp from {any} port {68} to {(self)} port {67} label "c843c49db83786e6e5a7f7a404a42b96" # allow access to DHCP server pass out quick on hn4 proto udp from {(self)} port {67} to {any} port {68} label "e1d80d9bcab29cae8a1a7c5081e89887" # allow access to DHCP server

The correct way would be to keep both set quick but to move the above DHCP rules before the above bogons rule.

I don't have a pfSense handy to check but my memory is that blocking bogons rules are shown visibly at the at the top of the interface firewall rules. My assumption is that DHCP rules which are never shown is done before the interface rules that are visible.

[AdSchellevis]

I don’t think we changed the ordering, but let me check next week when I’m around an OPNsense machine.

[IsaacFL]

I was thinking, if it turns out to be a major effort, then for myself I think I can probably write a rule going out on the WAN interface that would do what I want to do.

Probably, and this would be a new feature, the most flexible and maybe more productive use of your time, would be to expose bogons and bogonsv6 as an alias that can be used in user defined rules, and let the user choose how and where to place them.

So I am ok with withdrawing the issue.

[AdSchellevis]

Exposing otherwise “hidden” aliases is certainly a good plan.

[IsaacFL]

More information for you, I noticed it is the same on the WAN interface. Blocking Bogons and Private addresses are before DHCPv4 rules.

I do happen to have kept a copy of my old pfsense rules.debug file, and they block bogons and private addresses after the dhcp rules for the WAN at least. I wasn't blocking on the lan side.

[AdSchellevis]

The source on their end suggests only DHCPv6 is allowed before bogons (https://github.com/pfsense/pfsense/blob/57bb85a34ea3ab6d1ed89f3936a37c5c00d99b32/src/etc/inc/filter.inc#L3459, https://github.com/pfsense/pfsense/blob/57bb85a34ea3ab6d1ed89f3936a37c5c00d99b32/src/etc/inc/filter.inc#L3566)

I think it would be better to close this issue as you suggested and open a new one to allow the use of "hidden" aliases, the ordering itself is likely better left as it is now.

[IsaacFL]

Close in favor of allowing use of "hidden" aliases

[fichtner]

@IsaacFL 24dd5c3 should do the trick:

# opnsense-patch 24dd5c3

backref: https://forum.opnsense.org/index.php?topic=34363.0

Cheers,
Franco

[geekonamotorcycle]

I am also experiencing this issue all of a sudden with spectrum internet service on the gulf coast of florida. I have had to resort to allowing bogons in order to get ipv6 working correctly in my network,