Thanks to Jan for pointing out I neglected to include the macro defs
for the nets (though they're vanilla and what you'd expect). Here's
the full source for the first rule, the one I think should catch the
bogon packets but doesn't:
int_net = "192.168.5.128/25"
wls_net = "192.168.10.128/25"
ptr_net = "192.168.99.128/25"
table <unroutable_ips> const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32
}
block drop in log quick on ! lo0 inet from <unroutable_ips> to any
label "block unroutable ip"
The rest of the question below remains the same.
thankee much /david/
On Wed, Mar 27, 2013 at 10:12 AM, David Ruggiero
<thatseattle...@gmail.com> wrote:
> The very, very first rule in my pf ruleset is part of a fairly vanilla
> anti-spoof/sanity check set, intended to catch incoming bogon/martian packets:
>
> table <unroutable_ips> const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
> !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
> 127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32 }
> block drop in log quick on ! lo0 inet from <unroutable_ips> to any label
> "block unroutable ip"
>
>
> I can see it being evaluated using "pfctl -v -s rules", but so far (~40hrs
> uptime) it hasn't matched anything yet. That would normally
> not be of concern, except I'm seeing stuff like this in the pflog that I
> think it should have caught - but had to get caught by a later,
> fail-safe rule at the bottom of the ruleset. In particular, I'm seeing lots
> of bootp packets from badly-configured Windows clients:
>
> Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on em0:
> 0.0.0.0.68 > 255.255.255.255.67: xid:0x64f14f [|bootp] (DF) [tos
> 0x10] (ttl 64, id 0, len 330)
>
> So:
> - Is there something wrong with my first rule that I'm not seeing that causes
> these 0.0.0.0 bootp packets to miss it, OR
> - Is there something special about the bootp packets [remember, bootp uses
> UDP] that they won't match that rule, even
> though the source is in the unroutable_ips table?
>
> Thanks for any insight, or other debugging ideas I can test.
> /d/
>
> PS: Notice the "quick" keyword in the block rule - this isn't a "last rule
> that matches" issue, in case you're tempted to reply with
> something about that - I would think a packet from 0.0.0.0 should hit the
> rule, match, and then due to "quick" undergo no further
> evaluation, end of story.
