This whole discussion is, in my view, extremely absurd. It's not even bikeshedding. It's just weird. It stems from what is clearly a glaring bug in the original NPF implementation. I haven't dug into the source history to see how it got to be that way, but I can only imagine that it was a gross oversight. So far nobody has given an actual example of any firewall or filtering system that expects a network address be given when specifying an address range using an "addr/mask" or "addr/masklen" notation. Some have suggested they've "seen warnings or rejects" before, but nobody has given a concrete reference, except for me [tcpdump, where it causes nothing but annoyance and requires extra effort to work around]. Any amount of searching on the internet for descriptions of this subnet notation will ultimately describe their interpretation almost exactly as I have done so in previous messages. Yes, in some respects this is related, tangentially, to routing. But it's not about routing, it's about specifying subnet ranges for IP filtering. It's only about the notation used to express subnets that define address ranges. Describing the notation as "CIDR Style" is a metaphor -- that's where we consider it to have come from -- we're not concerned that the "R" in CIDR stands for "Routing". Hector went on a deep dive into how IP routing may be relevant, but that is distraction, if not a complete misdirection. The "address" part can be the network number, the broadcast number, or any number in-between. Why would any other address between the network number and the broadcast number be any different, in any context, than the network number??? In a routing context an expression of a subnet as an address within the subnet, along with the netmask, is quite clear, and BSD route(1) is happy to oblige: # route add -net 192.168.34.7/24 10.0.1.130 add net 192.168.34.7: gateway 10.0.1.130 # route add -net 192.168.33.136/28 10.0.1.130 add net 192.168.33.136: gateway 10.0.1.130 10:28 [1.2522] # netstat -rn | fgrep 192 192.168.33.128/28 10.0.1.130 UGS - - - xennet0 192.168.34/24 10.0.1.130 UGS - - - xennet0 In a filtering context there actually is NO question what "pass from 192.168.64.7/24" means for any concrete implementation I've ever used or been able to find. They all work as I have described. That goes for IPFilter, IPFW, PF, Cisco PIX, Linux iptables. In no case, ever, would a "pass" rule imply any blocking. That would be absurdly wrong and clearly inconsistent. At Sat, 24 May 2025 16:50:09 +0200, Christoph Badura <bad%bsd.de@localhost> wrote: Subject: Re: Proposal to apply mask to IP address set on rule > > On Sat, May 24, 2025 at 01:23:41PM +0200, Martin Neitzel wrote: > > GT> So far nobody has given examples of actual misconfigurations that would > > GT> benefit from warnings. > > > > Let's firewall a subnet for 16 hosts -- QUICK!: > > Is 192.168.33.136/28 on a /28 boundary or not? > > I see what mean. And I've seen that happen. This example is most absurd! Where did the "192.168.33.136" come from? Where did the "16" come from? (no IPv4 subnet has 16 hosts! 16 addresses, yes, but not 16 _hosts_) How is this possibly related to firewall rules? What's the rational? What does it even mean to ask "is this on a /N 'boundary'?????". Why do you need to know, or care? I'm not even sure what you're trying to imply here Christoph. For the code it is simple. Read the address. Read the mask. Apply the mask to the address. Use the masked address (which will be the network number for the subnet), with the mask (which defines the range of the subnet), to define the range of addresses which match the rule. If you, the human, need confirmation for what the range covers, then do the math, or find/create/use a tool that can do the math for you, e.g. https://github.com/pyr/ipcalc.git: $ ipcalc 192.168.64.136/28 address : 192.168.64.136 netmask : 255.255.255.240 (0xfffffff0) network : 192.168.64.128 /28 broadcast : 192.168.64.143 host min : 192.168.64.129 host max : 192.168.64.142 hosts/net : 14 In a real-world case of wanting to block a "neighbourhood" of possible offenders: - "192.168.33.136" would be the address of an offending remote host. - "16" would probably come from a WHOIS lookup for the assignment of that address showing that the address belongs to a block of 16 addresses, a "/28", assigned to a particular customer. In a real-world case of wanting to block local subnet from access to something then one will know what the sub-netting scheme, including at least one of either (a) the interface address for the subnet, or (b) the actual network number of the subnet, or maybe (c) the broadcast address of the subnet, or lastly (d) an important address within the subnet; any of which would be appropriate to use in the rule. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpD7pE1hk4_i.pgp
Description: OpenPGP Digital Signature