At Fri, 23 May 2025 18:18:27 +0000, Emmanuel Nyarko <emmankoko519%gmail.com@localhost> wrote:
Subject: Re: Proposal to apply mask to IP address set on rule
>
> bad@, let me explain my question to you again.
>
> let's say you want to exclusively allow packets from the
> 192.168.64.0 neighborhood for some whatever security reasons.
"192.168.64.0" doesn't really mean much these CIDR days.....
I presume you meant either 192.168.64.0/24 or 192.168.64.0/255.255.255.0
> group “ext” on $intf { pass from 192.168.64.7/24
> }
>
> group default { block all
> }
>
> The above rules will not match any packet from the 192.168.64
> neighborhood hence goes to default and block them. (But you
> actually intended to pass them.) this is because, when say a
> packet coming in has src addr to be : 192.168.64.2,
>
> NPF applies the mask to the incoming packet: (192.168.64.2 &
> 255.255.255.0) ==> 192.168.64.0.
>
> Then BPF directly compares 192.168.64.7(on rule without mask) to
> 192.168.64.0(masked ip from packet) Since 192.168.64.7 !=
> 192.168.64.0, hence skips that packet.
That's _really_ messed up, at least to me as an IPF (or Cisco, or
iptables, or [I think] pf, etc., etc., etc.) user!
"pass from 192.168.64.7/24" should mean _exactly_ the same thing as
"pass from 192.168.64.0/24" or "pass from 192.168.64.255/24", or
anything likewise with any other final octet value.
In other words: "192.168.64.7/24" means the "/24" subnet range that
includes "192.168.64.7".
I.e. when one specifies an IP address with any subnet mask other than
"/32" (and "/32" is implied if a netmask is missing), that means "the
CIDR subnet range that includes the given IP-address". This is almost
universal in how people understand address specifications for IP
networking (with tcpdump(1) being the obvious "odd man" out).
Of course for historical purposes the netmask can also be specified as a
dotted quad of octets.
Read the address and mask, apply the mask to the address, use the
resulting values.
I would apply the mask immediately upon parsing the specification from
the configuration file. The internal implementation need not know that
there were host bits set in the original text specification.
--
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:
pgpFWXvRg44Q8.pgp
Description: OpenPGP Digital Signature