SEO

Daniel:


The additional explicit Block Drop Quick inet6 rules didn't
work , oddly they made things slightly worse.

Before I was having 3 unloggable "ipv6/inet6?" packets
passing out with 2 loggable icmp6 (multicast listener report)
packets being blocked and dropped by PF.

With the additional explicit rules in place i've booted cold
once and rebooted twice. The number of packets attempting to
pass out has remained five in total and all packets are still
being listed as IPv6 by pfctl -si. Netstat -ss is still
reporting 7 packets being sent out , so 2 packets are
still presumed to be going out before PF is enabled.

The cold boot had 4 packets passing out with 1 packet
being blocked and dropped. The first reboot reverted to
3 out and 2 blocked and dropped. The second reboot had
4 out and 1 blocked and dropped. Before the first reboot
occurred I removed "::1 myhost myhost" from my /etc/hosts.
I don't think it had any bearing on the problem.

I can't comment on INCOMING "ipv6/inet6?" packets as i've
never received any. But as I now have both default BLOCK
Drop Log All rules and additional explicit Block Drop Log
Quick rules for ipv6 , ipv6-icmp , ipv6-nonxt , ipv6-opts ,
and inet6 that are not able to prevent some of these packets
from being passed out , PF must be having some difficulties
with OUTGOING packets. I assume that all of the affected
packets are from among the ones listed by netstat -ss in my
first post.

Is there a way to either delay the sending of these
presumably OpenBSD-generated packets until after PF has
come up fully or perhaps enable PF sooner? I'm wondering if
the timing of these packets could be important ; and the fact
that two packets always appear to be leaving my system before
PF even has the ability to track them.


A sysctl setting to DISABLE any protocol or address-family
containing a "6" would be greatly appreciated just now. Or
maybe an inet-ONLY GENERIC kernel could be made available ,
I imagine most users would opt for one of these if they were
made available?


Best Regards.

On Sat, 27 Jan 2007 17:50:05 +0100 (CET), Nomen Nescio wrote:

> Is there a way to either delay the sending of these
> presumably OpenBSD-generated packets until after PF has
> come up fully or perhaps enable PF sooner? I'm wondering if
> the timing of these packets could be important ; and the fact
> that two packets always appear to be leaving my system before
> PF even has the ability to track them.

Take a look at the temporary ruleset in /etc/rc. This is loaded
before your real /etc/pf.conf, and is briefly active. If you
want to block inet6 there (which is not recommended in general),
feel free to do so.

Obviously, pf cannot see, count, or block any packets before
it has been activated with the 'pfctl -e' call in /etc/rc.
Anything going out before that point will simply pass.

I'm not sure I understand why you'd obsess over a couple
of IPv6 neighbour solicitation packets going out (to the
local network) on boot. I guess for most people, this is not
an important point, and you'll have to tweak your rc scripts
if you really want to prevent them.

Daniel