Borked Pseudo Mailed wrote:
> Christian Weisgerber wrote:
>
> " Unless you explicitly set addresses and routes or enable
> autoconfiguration, IPv6 is effectively disabled. "
>
> My OpenBSD 4.0 system disagrees with you. I have icmp6
> packets being generated and sent out every day , at boot.
> PF cannot block them. Make a copy of /etc/rc and remove
> the pass rules from your default /etc/rc ,
> set /etc/pf.conf to block drop log all IN and OUT , comment-out
> any pass rules in /etc/pf.conf
> except for inet lo0 if you wish , reboot , when you get a
> prompt check pfctl -si , and see for yourself.
>

Clever Monkey wrote:

" Can you capture this traffic from the outside?




***** I don't have another computer I can use to do this.
Why would I need to do this when I don't need to do this
with IPv4? A given piece of software either is or is not
a firewall. Has PF been downgraded to being the equivalent
of a Windows firewall now , if it is not installed separately
from the OS it is protecting? I know that dedicating a machine
to use PF is more of an ideal , but it should still work
effectively when protecting itself when running on an OpenBSD
Desktop. It HAS done so for 2 years using IPv4.




Your pf.conf means nothing on early boot, is my understanding.




***** It should mean something if you have deleted the pass rules in
/etc/rc and are still seeing packets passing out AFTER /etc/pf.conf
has loaded.




Furthermore, someone mentioned in another thread that pf statistics are
not relevant or accurate for some reason or another. Perhaps someone
can jump in here and suggest why this might be so.




***** If the statistics are not accurate , then this is not Correct behavior.
The PF manual has no mention of this , the PF manual should be updated
and kept accurate. The packets that pass out and the packets that are
sent out and are blocked and dropped are variable , differing numbers of packets get
appended to my logs as well. In addition , other commands report these packets (and the
packets that go out before PF is enabled) , netstat -ss also reports the generation
, direction , and identity of these packets.




That is, using this single box to diagnose things after the fact is not
any sort of real proof. Do you see these packets leave any interface
with a default deny, pass none ruleset in both the rc.conf and then
later in pf.conf?




***** My normal default policies are block drop in log all and block drop out
log all. The only pass rules I have in my default ruleset are for inet
lo0 (IN and OUT). Yes , I removed all of the pass rules from /etc/rc a
very long time ago. Yes , I have tried calling /etc/pf.conf from /etc/rc
from an early point shortly after where /etc/netstart is called from , but
it made no difference.




Really, the only proof you can offer at this point is a tcpdump capture
showing these packet. "




***** I shouldn't need to show such proof , these "problems" are not "my
problems" , they are our problems. I should have given enough information
for others to try to replicate what I am observing. If these are flaws they
will threaten all users. Self-interest should be a very strong motivator.
There are some users who are actually using IPv6 at present. I have very
restrictive firewall rules globally. I am inside of a protected network.
I will probably be one of the last to be directly affected should attacks
commence. I posted originally , and then additionally , to warn others.
I did also wish to find more variables that I could test , in the off-chance
that I somehow missed something , made a silly mistake , and somehow caused
what I have observed to happen. Before I originally posted I methodically
tried a wide-range of things that might have been even tangentially responsible ,
I found none of these had any effect on whether the packets were passed out.




***** An Odd User.