[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First time user comments

On Thu, 2005-01-20 at 17:05, Peter Fraser wrote:
> 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.
> Now for the picky ones.
> Could the "syntax error" message, give the position in the line that the
> error occurred, or at least the token that caused it. When you are a
> first time user you syntax errors are not obvious.
> I could find no where in the documentation that says what happens when
> you omit the "on <interface>" clause. The documentation implies that it
> must always be given, and grammar in "man pf.conf" shows it as being
> required, but several examples don't supply one. 
the GRAMMAR section in pf.conf show this:
     pf-rule        = action [ ( "in" | "out" ) ]
                      [ "log" | "log-all" ] [ "quick" ]
                      [ "on" ifspec ] [ route ] [ af ] [ protospec ]
                      hosts [ filteropt-list ]
where "on ifspec" is in [] denoting that it's optional.  in the intro
paragraph of the PARAMETERS section it also states "Most parameters are
optional."  from the above--the only required parameters are "action"
and "hosts" making the simplest rule possibilities:
  block all
  pass all
> I believe that not
> supplying a "on <interface>" means the statement applies to all
> interfaces.
correct.  just like not specifying in|out means the packet can match in
either direction.
> What needs to be quoted in a macro is not documented. One of my first
> mistakes was to write
> 	Internal_net = 192.168.200/24
> I could not find any documentation that said it had to be written as
>       Internal_net = "192.168.200/24"
> with quotes. I also tried 
>   	DebugLog = log
> and got a similar error.
i have never seen an example where the value of a macro was not quoted. 
the exception to this is macros inside of macros, which is pointed out
in the MACROS section of the man page:
  Macros are not expanded inside quotes.
     For example,
           ext_if = "kue0"
           all_ifs = "{" $ext_if lo0 "}"
> I have several (actually three) segments, each of which have their own
> set of IP address. I wanted each segment to be only allowed to send in
> from IP addresses belonging to the segment, (and for good message stop
> the
> firewall from putting out packets onto a segment that they did not
> belong on). I expected an option on the antispoof directive to implement
> this effect, but it was not there so I wrote:
> 	InternalInterfaces = "{" ste1 ste2 ste3 "}"
> 	block in  quick on $InternalInterfaces from !$id:network
> 	block out quick on $InternalInterfaces to   !$id:network      
> and was surprised to get "macro id is not defined". I believe the $id is
> only defined in certain contexts. Now I can get the same effect by
> writing the six statements which is what I did, but I was surprised.
um--that's what "antispoof" is for--source address verification inbound
on a given interface.  as for your good measure(?) of blocking packets
outbound from the firewall...that's what the routing table is for...IMHO
i don't see the "good" in that measure(?).
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
<--snip dns resolving in rules comments-->
> It would be nice if there was a predefined macro for the unrouteable
> address.
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
> 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.
> I could not find a documentation on the output of tcpdump for pf. For
> example tcpdump give a rule number as "rule 68/0(match)" eventually I
> figured out that that the first number was the n'th rule as output by
> "pfctl -s rules". I have no idea what the "/0" is for. The value of the
> flags field also have values in that I can not find documentation for.
> "pfctl -s rules" should number it rules.
it does--use pfctl -vvsr and you get rule numbers.  don't want the
Evaluations et. al. lines in there?  use pfctl -vvsr | grep ^@ 
in general--i despise products that "automatically" define things for
me, and assume things for me; as i would much rather have a product that
just does what i tell it to do--no more, no less.  this happens to be
the reason i absolutely love OpenBSD and pf.
"Oh, so they have Internet on computers now!"
	--The Simpsons