I received this by mail. But I have a strong enough believe in my self that if I get confused, then others will be confused as well. But I am also badly dyslexic so I know I miss and miss write things and confuse my readers.
The Manual that I was using is http://www.openbsd.org/faq/pf/config.html which gives as "Rule Syntax" quoting: action direction [log] [quick] on interface [af] [proto protocol] \ from src_addr [port src_port] to dst_addr [port dst_port] \ [flags tcp_flags] [state] which shows the "on interface" as being required. also for example quoting from the manual Macros can be defined recursively. Since macros are not expanded within quotes the following syntax must be used: In that case you would think this would work a = "10/8" b = "$a" pass from any to $b It doesn't, and it is best that it doesn't. What the statement probably should have been was: During macro definition the defining text may contain macros which are expanded at time of definition. Reserved words, symbols and addresses must be enclosed in quotes. Because I comment on something does not mean I think it is a bad product. Bad products I don't spend the time to write up comments. But I also believe that any product (and product includes it manuals) can be made better. -----Original Message----- From: Jeff Quast [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 10:26 AM To: Peter Fraser Subject: Re: First time user comments I was going to CC this to the list but I decided it was spam. Any questions or suggestions you pose are already answered in the manual or outright ridiculous. On Mon, 24 Jan 2005 13:40:37 -0500, Peter Fraser <[EMAIL PROTECTED]> wrote: > On comments by Jason Opperisano <[EMAIL PROTECTED]> > > > > > The very broad: I don't understand why there is separate > configuration > > > files for bridges and routing and packet filtering. > > > > routing and bridging are two separate things. > > so are redirecting and NATing. pf encompasses more packet filtering and networking than any other packet filter i've run into (iptables, ipfawdm, ipf, etc.), for instance, the altq directive. in Linux you need to use cheap hacks like http://lartc.org/wondershaper/ and in ipfw its a different config all together. However, It would be disastrous to configure a RIP-capable router inside pf! (http://www.openbgpd.org/). And once a bridge is setup, you can use it in pf just like any other interface. Redirecting and NAT'ing are best taken care of by the packet filter. I'm not sure if your saying there should be seperate configurations for everything, for instance a scrub daemon, a nat daemon, and a redirect daemon, all of which is handeled very nicely by packet filtering. routing and bridging, however, are _extremely_ different issues. > I wanted a further statement, that there should be no other packets on > that network segment other than one with an ip address in 10/24. > Packets that don't belong on the inside network happens to be all > the time. The Microsoft VPN software leaks packets, from outside > often in 192.168/16 space. People connecting portables that still have > foreign ip address on them. I believe and still believe that this > statement is needed > block in on fxp0 from ! 10/24 to any > As for the reverse, block the output, It should not have be necessary, > and maybe I am overly paranoid. You are not overly paranoid, you just don't read manuals very well. This will block any spoofed traffic from leaving the network: block out log quick on $ext_if from { ! $ext_if } to any This will block any 10/24 traffic from entering the network: block in log quick from no-route to any > > as for pf not magically knowing what $id is supposed to mean; I'm not > > sure why you think it would--also not sure why you'd be surprised that > > it would tell you that the macro isn't defined, as you clearly didn't > > define it. the macro $magic_miss_cleo_psychic_logic isn't defined > > either--so it doesn't surprise me when my rules fail to load when i > > reference it. computers do what you tell them to do--they're funny > that > > way. > > My mistake a typo, I meant $if, which pf already knows and can decode in > the label field. I don't mind whether its a special macro which does > exit > of a reserved word like "self", I would still like it. I think, if you read pf.conf(5) from top to bottom, you may come to know some terms and definitions that may explain yourself better. Otherwise this makes absolutely no sense. > > all IP address are routeable, as IP is a routed protocol; unlike say, > > NetBEUI for example... i could be so bold as to assume you mean the > RFC > > 1918 address spaces reserved for private networks, but i would just be > > assuming. maybe you mean the RFC 3330 special-use addresses, sans the > > cable modem 24/8 network. maybe you mean all the network blocks > listed > > on http://www.iana.org/assignments/ipv4-address-space as > > Reserved|Private Use|Returned. ah--but this list is a moving target > > that can be modified at any time--last update was 02Aug2004, fyi... > the > > pf developers; much like the parsing engine, are not > > mind-readers--firewalling is a personal thing: say what you mean and > > mean what you say. how hard is it to define what *you* actually mean > by > > "unrouteable" in a template file that you create your firewall configs > > from? > > > > Yes, its a moving target, And these address constantly appear on my > outside > interface. And yes I put together a list, and I like others will > probably > not ever update my list until something bad happens. > > > > It would be nice if there is only one interface type on the computer > to > > > define a macro automatically for them, I suggest $id0 $id1 etc. That > way > > > pf config files could be more portable, particularly in the case of > a > > > server machine that only has one interface. > > > > not 100% sure what you mean here, but if you mean being able to refer > to > > hme0, hme1, hme2, hme3, and hme4 simply as hme--then it's already > there. > > > > No I meant interface. So have I have, depending up the machine, > fxp0 and ste0 as far as the filter goes there is no difference > between them. I ran into this when I put a local pf up on two > nameservers. > The machines had different interface cards, so two pf.conf that should > have > been identical are not! You said yourself, they don't have identical interface cards!! Thats the silliest thing I've ever read! With several NIC's, I wouldn't know which NIC is my DMZ, external, or internal interface! What a disaster! For instance, in Linux, where your ethernet interfaces are named eth0, eth1, and so on, it becomes extremely hazerdous to change network cards, because the eth2 you just replaced suddenly becomes eth0 and so on. I can't tell you how many times I've had to sit and individually plug in each NIC one by one and pinging things to figure out which NIC is which, even though they are all different brands. > > Some more: > > It would be nice if pfctl could turn or turn off logging by rule number. > Or > another possibility is a logging level i.e. log1 log2 log3 etc > controllable by pfctl. > Please examine the label parameter. Please read the manual. -- :wq!
