FW: First time user comments
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
Re: FW: First time user comments
On Thu, Jan 27, 2005 at 01:00:32PM -0500, Peter Fraser wrote: 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. Yes, that part of the web page is wrong (or, rather, outdated) now. The more authorative source is the man page, pf.conf(5), which contains this: pf-rule= action [ ( in | out ) ] [ log | log-all ] [ quick ] [ on ifspec ] [ route ] [ af ] [ protospec ] hosts [ filteropt-list ] Therefore, yes, the 'on interface' part is optional. Reporting errors in manuals (including web pages) is of course welcome. The confusion in this case was that you didn't previously mention the source, or just called it 'manual'. When I checked the man page, there was no error, hence the report seemed wrong. 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. I don't see an obvious improvement in your wording, for me 'are not expanded within quotes' expresses precisely that, while in your sentence, I don't know what 'symbols' would refer to. Macro names? Daniel
Re: First time user comments
Peter Fraser [EMAIL PROTECTED] [2005-01-21 00:54]: Could the syntax error message, give the position in the line that the error occurred, or at least the token that caused it. no - that is not how parsers work. syntax error actually says it didn't match any production from the grammar. if we don't know what production it should have matches, how should we tell which part didn't? that is just not how parsers work, sorry. Parsers I know, I am assuming that pf is using Bison. Productions fail because they are given a token that they cannot shift. Each token has a location in a file, the token can be printed (by modifying yyerror), or with a bit more work yylex can keep tract of the character number within the line of the token.
Re: First time user comments
On Mon, Jan 24, 2005 at 12:04:12PM -0500, Peter Fraser wrote: Parsers I know, I am assuming that pf is using Bison. Productions fail because they are given a token that they cannot shift. Each token has a location in a file, the token can be printed (by modifying yyerror), or with a bit more work yylex can keep tract of the character number within the line of the token. The nice thing about claims of infeasibility is that it only takes one counter-example to prove them wrong :) If you can provide a patch to pf's parse.y that produces more useful errors instead of the generic 'syntax error', and which works with the hackery already present there (like ungetc() and all that), you win. A good test would be to go through the regress tests and check each changed output message (for errors), and verify the additional output is not misleading in a significant number of cases. Daniel
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,
Re: First time user comments
* Peter Fraser [EMAIL PROTECTED] [2005-01-21 00:54]: Could the syntax error message, give the position in the line that the error occurred, or at least the token that caused it. no - that is not how parsers work. syntax error actually says it didn't match any production from the grammar. if we don't know what production it should have matches, how should we tell which part didn't? that is just not how parsers work, sorry. I believe that not supplying a on interface means the statement applies to all interfaces. yes. 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. that will be solved by interface groups. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
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
way.
--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
from?
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
