On 4/19/05, Okan Demirmen <[EMAIL PROTECTED]> wrote:
> hi all -
>
> i'm curious as to the behavior the following scenerio is/should be
> and what might i do to change it.
>
> quick ruleset:
>
> nat on $ext_if from !($ext_if) -> ($ext_if:0)
Would you really want to translate every packet that is not from your
$ext_if to $ext_if's first address? I mean, translate something from
lets say, lo0/127.0.0.1 to your to $ext_if's first address. me
neither.
> 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:
>
obviously due to the block rule.
> 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.
>
your logic is not screwed. I recently introduced NAT to my network.
any it basically goes like this:
A packet coming from $int_if:network will come *in* from $int_if, pf
will try to find the nearest matching rule according to infomation
contained inside the packet; the last matching rule wins, if it is a
pass rule then pf will hand the packet to the kernel to do the routing
& other magic etc.
Then this same packet will come back to pf, this time as an *out*
going packet on $ext_if although this time before any filtering it can
see a NAT rule that wants to translate any packets originating from
the $int_if:network to appear as though it has come from $ext_if's
address, thus then creating a state tracking table.
Finally it looks for the nearest matching rule according to infomation
contained inside the packet, finds a pass rule then escapes to your
ISP, then does a similar thing again.
> 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?
>
The above should give you a moderate clue, but me being a nice person
will give you a head start:
# PUBLIC DOMAIN
#
# THE CODE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS CODE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS CODE.
ext_if= "" # External interface (Outside)
int_if= "" # Internal interface (Inside)
lpb_if= "lo0" # Loopback interface
# Translate any TCP/UDP packets from $int_if:network
# that going anywhere, except $int_if:network
# tagging the packet too!
nat on $ext_if inet proto { tcp udp } \
from $int_if:network to !$int_if:network \
tag INT_NAT \
-> $ext_if:0
pass quick on $lpb_if # Pass packets on loopback
# Block any packet to/from $ext_if
# make sure we are quiet and log them to
block drop log on $ext_if
# Block any packet to/from $int_if
# make a noise and log them as well
block return log on $int_if
# Pass any "packet" from/to $int_if:network
pass quick on $int_if \
from $int_if:network to $int_if:network
# Allow TCP/UDP packet tagged INT_NAT to pass out of $ext_if
pass out on $ext_if inet proto { tcp udp } \
from any to any \
flags S/SA modulate state \
tagged INT_NAT
# EOF
> does what i'm explaining make sense?
>
yes.. :)
> thanks,
> okan
>
> --
> Okan Demirmen <[EMAIL PROTECTED]>
> PGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB3670934
> PGP-Fingerprint: 226D B4AE 78A9 7F4E CD2B 1B44 C281 AF18 B367 0934
>
Regards
PS. sorry about double post ;o)
--
Kimi
