On Tue, Apr 19, 2005 at 02:36:13PM -0400, Okan Demirmen wrote:
> nat on $ext_if from !($ext_if) -> ($ext_if:0)
> block log all
> pass in on $int_if proto tcp from $int_if:network to any \
> port 22 tag INT_INET flags S/SA modulate state
> pass out on $ext_if tagged INT_INET keep state
>
> so here if we initiate a connection from within $int_if:network on
> tcp/22 to something out $ext_if, we go through just fine. however,
> if i want to initiate a connection *from* the pf device itself on
> $ext_if, i will not be able to. so one adds the following:
>
> pass out on $ext_if from ($ext_if:0) to any keep state
>
> so now i can initiate connections from with $inf_if:network as well
> as on the pf device towards whatever lies out $ext_if. however, now
> the "pass out...tagged INT_INET ..." rule becomes redundant since
> the state for the nat is created on the nat rule(well, the ip of
> ($ext_if:0), so the rule with "...from ($ext_if:0)..." matches.
>
> say something here if i've screwed up my logical and/or tests.
>
> in a situation where one wants to, say...limit outbound ports from
> $if_int:network but allow a different set from from ($if_ext:0),
> how may one go about that?
>
> does what i'm explaining make sense?
Yes, and there are several solutions.
1) use rule order to your advantage
a) put the "from ($ext_if:0)" rule first, so packets with the tag
will match the subsequent "tagged" rule last, while packets
without the tag will pass through the first rule.
or
b) add "quick" to the "tagged" rule, so packets with the tag will
not continue evaluation after matching that rule, while packets
without the tag will.
or
2) resolve the overlap between the two rules, by adding
"! tagged INT_INET" (the ! means 'not') to the "from ($ext_if:0)" rule,
so one packet only matches one of the two rules, and their order
doesn't matter anymore.
It's simple problem to solve, once you consider how rule order works and
how you can use it to your advantage.
Daniel
