Solved Interesting pf behaviour

Q

QuesoGrande

I am trying to get an instance of pf running under FreeBSD 13.3 and seeing what I consider to be a problem. For various reasons it is QUITE important to me to have very effective blocking of anything I do not explicitly pass. I am editing /etc/pf.conf and the running pfctl -v -F all -f /etc/pf.conf to load the newly edited rule set, and according to the messages that yields it appears to work. But the following is observed ...

After running simply pfctl -v -F all and then pinging a host out in the world at large, the ping is still passed through. I was lead to believe that the default was to pass nothing . So what gives?

Next edit pf.conf to read
block drop all
block drop inet proto icmp all

and then running pfctl -v -F all -f /etc/pf.conf

ping still passes and runs. Again, what gives?

Am I doing this all wrong, is there something I am missing, am I just snakebit, or is this the way things are supposed to work?

You are right, life is tough when you are trying something new to you. But then "experience is what you get when you expected something else." :)

Thanks,
QG
 
As a matter of fact that is the full pf.conf. I kept stripping it down to the smallest still-failing file and this is it. Also I neglected to mention, even though I intended to, that this is under the 13.3 GENERIC installation.
 
Now, just to confuse the issue, I thought I had this figured out. Changed pf.conf and tried again. New pf.conf contents in its entirety is:
ext_if="igb3"
set block-policy drop
nat on $ext_if inet from self to any -> ($ext_if)
block out on $ext_if inet proto {udp, icmp} from self to any

The result is the same. Now I suspect I am unclear on the concept of "self". Does this not mean that this should block ping traffic generated internally in the pf box as commanded from a console connected to said box, or will this only block traffic coming into the box from the Int_if ( not yet defined )? I really want to block locally generated traffic as well as traffic coming in from the lan destined for the wan.

Sorry for all the manipulations of this, but I suspect it not unusual for someone new to pf, exactly such as I am. :( sigh!

We try again ...
Thanks,
QD
 
Sometimes figuring out the obvious is just what it takes!!

But to bring it to closure, pfctl responds with lists of "stuff" which gives me the feeling it is indeed alive and well.
 
You can try some of these:
pfctl -sr

if log enabled:
tcpdump -n -e -ttt -r /var/log/pflog

tcpdump -n -e -ttt -i pflog0

pf.conf

block log all
 
I THINK I have it working now. I was not clear on the notion of what pf considers "self" to mean. Not sure I can explain it to anyone else yet, but after a little more experience I think it will suddenly become clear to me. Sorry for the upheaval on the forum with this, but sometimes someone says something that sparks the idea even if it isn't exactly the problem, and that seems to have worked here. Thanks be to FREEBUSER for doing just that. And I am not even sure what you said that did the deed, but it is working now.

I believe this one comes under the heading of "I've BEEN thinking ... and it hurt!" ;)

Thanks again
QG
 
You must log in or register to reply here.
Back
Top