Re: weird PF behavior
Ryan Corder wrote:
alternatively, I did this and it seemed to work
pass out on bge0 from inside to { any, !outside }
pass out on bge0 from inside to { any, !llcidr }
The above is an overkill equivalent to
pass out on bge0 from inside to any
which I doubt is what you want.
/Alexander
Re: weird PF behavior
On Fri, 2007-03-16 at 11:09 +0100, Alexander Hall wrote:
Ryan Corder wrote:
alternatively, I did this and it seemed to work
pass out on bge0 from inside to { any, !outside }
pass out on bge0 from inside to { any, !llcidr }
The above is an overkill equivalent to
pass out on bge0 from inside to any
which I doubt is what you want.
this isn't the way it is acting. what i want is
pass out everything except outside
pass out everything except llcidr
and it seems to be working that way.
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
On Fri, 2007-03-16 at 19:29 +0100, Almir Karic wrote:
the {} thingy is strictly text expansion, which means your rules expand to:
pass out on bge0 from inside to any
pass out on bge0 from inside to !outside
pass out on bge0 from inside to any
pass out on bge0 from inside to !llcidr
if you use ''pfctl -sr'' you will see that we were right.
I never disputed that, but in that same vein no one has bothered to
correct my mistake, just continued to point it out.
very simply, this thread could have ended a day or two ago if the
following process would have taken place:
1) is my syntax wrong? YES
2) OK, what is wrong with it? Pointed out and understood.
3) Good, now what is the correct syntax?
number 3 is where we sit. I understand that the {} syntax is for text
expansion. What I don't understand is whether when someone use {}, is
the list evaluated as a logical AND or a logical OR? If AND, then the
following should work:
pass out on bge0 from inside to { any, !outside, !inside }
which would evaluate to 'pass ... to (all AND NOT outside AND NOT
inside)'. But as this is not happening, it leads me to believe that
the {} expansion is evaluated as an OR list. Assuming that is the case,
how does one go about evaluated the list with AND logic?
when you define a table thusly:
table foo const { 10.0.4.0/24, !10.0.4.35 }
according to the documentation, that evaluates to 'the entire 10.0.4.0
subnet EXCEPT 10.0.4.35'. is it just by design that when defining a
table, {} is treated differently than when it is used in a rule?
now. given that I have a default block all rule, is it possible to allow
out ALL traffic EXCEPT those packets bound for the addresses listed in
the outside and llcidr tables without the need for more block rules?
thanks.
ryanc
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
** Reply to message from Ryan Corder [EMAIL PROTECTED] on
Fri, 16 Mar 2007 14:01:38 -0500
very simply, this thread could have ended a day or two ago if the
following process would have taken place:
1) is my syntax wrong? YES
2) OK, what is wrong with it? Pointed out and understood.
Evidently, *not* understood.
3) Good, now what is the correct syntax?
number 3 is where we sit. I understand that the {} syntax is for text
expansion. What I don't understand is whether when someone use {}, is
the list evaluated as a logical AND or a logical OR?
Neither. It does text expansion, as several people have already told
you. *All* it does is transform one rule into several rules;
evaluation is exactly the same as if the original ruleset included the
resulting rules -- there's no AND or OR involved. The *effect* (in
this case) is the same as if the {} construct were evaluated as an OR
within a single rule, but that's not how it's implemented.
Dave
PS: I'm definitely *not* a pf/pfctl expert, but I believe that I do
understand how this bit of it works. If I'm wrong, I'm sure that I'll
be corrected quickly.
--
Dave Anderson
[EMAIL PROTECTED]
Re: weird PF behavior
On Fri, 2007-03-16 at 12:59 -0700, Marco S Hyman wrote:
now. given that I have a default block all rule, is it possible to allow
out ALL traffic EXCEPT those packets bound for the addresses listed in
the outside and llcidr tables without the need for more block rules?
No, you need additional block rules.
pass out on bge0 from inside to any
block out on bge0 from inside to outside
block out on bge0 from inside to llcidr
Last match means that packets directed to outside or llcidr
will be blocked, all others (from inside) will pass.
The last two rules can of course be collapsed to
block out on bge0 from inside to { outside, llcidr }
thank you, that is what I wanted to know. Does the situation require
extra block rules? The answer is yes and I know that for future
reference.
Thank you, Marco, for getting straight to the question at hand.
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
On Fri, 2007-03-16 at 16:30 -0400, Dave Anderson wrote:
1) is my syntax wrong? YES
2) OK, what is wrong with it? Pointed out and understood.
Evidently, *not* understood.
Evidently, you can read my mind and know what I do and do not
understand. That's fricken' amazing!
3) Good, now what is the correct syntax?
number 3 is where we sit. I understand that the {} syntax is for text
expansion. What I don't understand is whether when someone use {}, is
the list evaluated as a logical AND or a logical OR?
Neither. It does text expansion, as several people have already told
you. *All* it does is transform one rule into several rules;
evaluation is exactly the same as if the original ruleset included the
resulting rules -- there's no AND or OR involved. The *effect* (in
this case) is the same as if the {} construct were evaluated as an OR
within a single rule, but that's not how it's implemented.
fine, that is how it is. so that answers my question from the previous
message. {} is treated differently in a table than in a rule.
but it still doesn't answer my question. With a default block all rule,
is it possible to pass traffic out to anyone except those defined in a
particular table without the need for further block rules?
if yes, then I'll figure it out. if not, a simple NO will suffice.
the following is what I'm NOT looking for:
block log all
pass in on bge1 from insdie to any keep state
pass out on bge0 from inside to any keep state
block out on bge0 from inside to outside keep state
block out on bge0 from inside to llcidr keep state
this accomplishes what I want, but I feel the use of more block
statements past the first one is extraneous.
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
why do you bother asking questions if you are not willing to accept answers?
you either need:
pass out on bge0 from inside
block out on bge0 from inside to { outside, llcidr }
or:
block quick out on bge0 from inside to { outside, llcidr }
pass out on bge0 from inside
alternatively you could have a combined table containing both
outside and llcidr sets of addresses, but you can't nest tables
so it's probably more work to maintain.
the PF faq has something on the subject (tables.html, macros.html).
the above post gives you the solutions to this problem, you rejected
one of the solutions with because of a feeling, you didn't bother to
use the second one (tables) nor to read the given docs :/.
--
almir
Re: weird PF behavior
* Martin Gignac [EMAIL PROTECTED] [2007-03-15 02:37]: I think this can be explained by the default state policy (which is floating) in pf. Consult the man page and look for 'set state-policy'. do everything else but that. really. this is never ever your problem, except you do weird things with tunnels or the like. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: weird PF behavior
On 3/15/07, Henning Brauer [EMAIL PROTECTED] wrote: do everything else but that. really. this is never ever your problem, except you do weird things with tunnels or the like. Gotcha. -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: weird PF behavior
On Thu, 2007-03-15 at 01:39 +, Stuart Henderson wrote:
feed the rule into pfctl -nvf - and see how it's expanded.
basically what you would expect...
$ pfctl -nvf -
pass out on bge0 from inside to { !outside , !llcidr } tagged
INSIDE keep state flags S/SA
pass out on bge0 from inside to ! outside flags S/SA keep state
tagged INSIDE
pass out on bge0 from inside to ! llcidr flags S/SA keep state
tagged INSIDE
^C
$
i'm just a bit baffled by this one considering these are the first and
only 'pass out' rules on my external interface and I'm not using the
'quick' keyword anywhere but on the 'pass in' rule on my internal
interface. so, shouldn't these be getting evaluated?
thanks.
ryanc
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
On Thu, 2007-03-15 at 15:32 +, Stuart Henderson wrote:
On 2007/03/15 10:25, Ryan Corder wrote:
On Thu, 2007-03-15 at 01:39 +, Stuart Henderson wrote:
feed the rule into pfctl -nvf - and see how it's expanded.
basically what you would expect...
pass out on bge0 from inside to ! outside ...
pass out on bge0 from inside to ! llcidr ...
i.e.
pass out to everyone-apart-from-outside
pass out to everyone-apart-from-llcidr
This blocks only the intersection of outside and llcidr
(probably nobody).
ok, so I want:
pass out to everyone-except-from-outside
pass out to everyone-except-from-llcidr
would that be:
pass out on bge0 from inside to { any, !outside, !llcidr }
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
On 2007/03/15 16:00, Ryan Corder wrote:
pass out to everyone-apart-from-outside
pass out to everyone-apart-from-llcidr
This blocks only the intersection of outside and llcidr
(probably nobody).
ok, so I want:
pass out to everyone-except-from-outside
pass out to everyone-except-from-llcidr
That's what you're doing now with the { x, y } syntax in a rule,
but it's not what you want: it expands to two fully independent rules,
the first passes almost all traffic from inside, and the second rule
passes almost all traffic from inside.
would that be:
pass out on bge0 from inside to { any, !outside, !llcidr }
No, that would expand to three rules, one passing all traffic from
inside and the other two as above.
you either need:
pass out on bge0 from inside
block out on bge0 from inside to { outside, llcidr }
or:
block quick out on bge0 from inside to { outside, llcidr }
pass out on bge0 from inside
alternatively you could have a combined table containing both
outside and llcidr sets of addresses, but you can't nest tables
so it's probably more work to maintain.
the PF faq has something on the subject (tables.html, macros.html).
Re: weird PF behavior
On Thu, 2007-03-15 at 22:42 +, Stuart Henderson wrote:
No, that would expand to three rules, one passing all traffic from
inside and the other two as above.
you either need:
pass out on bge0 from inside
block out on bge0 from inside to { outside, llcidr }
or:
block quick out on bge0 from inside to { outside, llcidr }
pass out on bge0 from inside
alright, but I already have a default block everything rule, why would
I need additional block rules?
alternatively you could have a combined table containing both
outside and llcidr sets of addresses, but you can't nest tables
so it's probably more work to maintain.
which is too bad.
alternatively, I did this and it seemed to work
pass out on bge0 from inside to { any, !outside }
pass out on bge0 from inside to { any, !llcidr }
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
weird PF behavior
I have a fairly simple ruleset and it doesn't seem to be working right
for me...at least it doesn't make much since.
ext_if=bge0
int_if=bge1
table outside const { 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 }
table inside const { 10.0.4.0/24, 10.0.5.0/24 }
table others const { 172.18.114.35 }
block log all label default block
pass in on $int_if from inside to any tag INSIDE keep state
pass out on $ext_if from inside to { !outside, !others } tagged
INSIDE keep state flags S/SA
here is the problem, from a machine on the 10.0.5.0/24 subnet, I can
connect to any IP and any port on the 10.0.3.0/24 subnet. the way the
two pass rules are written, I was thinking that I would be able to
connect to anything EXCEPT the subnets listed in outside and others.
what am I missing here?
thanks.
ryanc
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
I think this can be explained by the default state policy (which is
floating) in pf. Consult the man page and look for 'set state-policy'.
I think that by default, because you're letting the packets through in
your first 'pass' rule you create state. When you get to the outside
interface you match this existing state (because the state policy is
set to floating) and your second 'pass' rule never evaluates.
One quick way to determine this is to set your state policy to
'if-bound' and then check whether or not you have the same behavior.
-Martin
On 3/14/07, Ryan Corder [EMAIL PROTECTED] wrote:
I have a fairly simple ruleset and it doesn't seem to be working right
for me...at least it doesn't make much since.
ext_if=bge0
int_if=bge1
table outside const { 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 }
table inside const { 10.0.4.0/24, 10.0.5.0/24 }
table others const { 172.18.114.35 }
block log all label default block
pass in on $int_if from inside to any tag INSIDE keep state
pass out on $ext_if from inside to { !outside, !others } tagged
INSIDE keep state flags S/SA
here is the problem, from a machine on the 10.0.5.0/24 subnet, I can
connect to any IP and any port on the 10.0.3.0/24 subnet. the way the
two pass rules are written, I was thinking that I would be able to
connect to anything EXCEPT the subnets listed in outside and others.
what am I missing here?
thanks.
ryanc
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
--
Suburbia is where the developer bulldozes out the trees, then names
the streets after them.
--Bill Vaughan
Re: weird PF behavior
pass out on $ext_if from inside to { !outside, !others } tagged
INSIDE keep state flags S/SA
feed the rule into pfctl -nvf - and see how it's expanded.
