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

Re: First time user comments



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. 
> 
> 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 "}"
> 
Note in your example "lo0" is not quoted, nor is $ext_if, but I took
that
to mean that $ext_if was expanded. I expected the text on the right of
the 
'=' to be just gathered unless it was a macro. I still don't understand 
what happens, if quoting is necesary why isn't the lo0 quoted, and how 
is that different than 10/24 or for that matter log?
> > 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(?).
The documentation says that antispoof is
	block in on ! fxp0 inet from 10.0.0.0/24 to any
	block in inet from 10.0.0.1 to any
Which I read as only fxp0 can have packets from 10/24 and it
better not have any packets with its address. Which is fine in
it self.
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.
> 
> 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. 
> 
> 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!
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.