PF FAQ clarifications & comments.

Sherwood Botsford <[email protected]>
Newsgroups gmane.os.openbsd.www
Message-ID <[email protected]>
(This is the only email I've found on the PF page.  If you are 
not the person to who I should be speaking, let me know...)

Thanks overall for this intro and tutorial on pf.  Without it I 
would be up a creek.  (Even with it, the water is shallow and 
rocky. Rueful grin.)

Here are a bunch of suggestions for the next iteration of the PF 
FAQ.  Let me know if I'm confusing, confused, or if you want any 
help/assistance on this.

Item 1.
pf=NO in /etc/rc.conf;
There is no pf in /etc/rc.conf.local
It is not clear whether pf can be set to yes in /etc/rc.conf
or whether it should remain no there, and the full rule set be 
read in later.  Perhaps a paragraph explaining why it should be 
NO in rc.conf and yes in rc.conf.local

Item 2.
The getting started makes no mention of sysctl.
By default
net.inet.ip.forwarding=0       # 1=Permit forwarding (routing) of 
packet

Editing sysctl.conf for long term, and running sysctl -w... 
during setup probably should be mentioned.

(This one caused me no end of grief:  I am in the progress of 
building a new firewall.  The old one on 3.7 is on a pentium 333 
with 128 MB ram.  Adequate horsepower, but about twice a week it 
spontaneously reboots.  No messages.  I figure the hardware is 
getting flaky.  The new one is a small 5 year old dell poweredge 
server.  More processor than I need, but it means I can split 
squid's cache over multiple spindles.

Anyway, after building the new box, I carefully copy over the pf 
stuff from the old box.  Start pf.  No problems at all.
Announce 3 days in advance that the internet will be down for an 
hour on Friday afternoon.  Bring the oldbox down, swap addresses 
so the new one appears at the address all the clients are 
expecting, move the ethernet cable from the satellite modem over 
to the new box, and presto! nothing works.


Item 3.
Best Practice.  Rules requiring non-local dns lookups should NOT 
be in pf.conf.  This is especially true if the firewall is NOT 
the dns server, and the dns server is inside the firewall.

I shot myself in the foot with this one once.  pf wouldn't load 
rules until it could finish dns lookups.  Pf wouldn't let the dns 
server do the lookups until the rules were loaded.

I now keep pf.conf purely internal, and relatively permissive for 
outbound traffic, then later load pf.run that has my lists of bad 
guys.

Would it be a good idea to have a section on BPs?

Item 4.
Is it worth mentioning interfaces to pf for constructing the rule 
sets, such as fwbuilder?  (I've just gotten it to compile, 
haven't figured out how to use it yet, but just as SWAT made 
samba a bit less arcane, perhaps this could be a tool to make pf 
a bit more accessible for newbie sysadmins.)

Item 5.
Trouble shooting:
A:  Checklist of overall things (such as that sysctl) that need 
to be changed.
B:  use of tcpdump on the pflog0 interface.
C:  use of tcpdump on $world interface.

(I've aliased fwdump to tcpdump -s256 -len -i pflog0)

[demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of sbotsford.4012DEFANGED-vcf]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.