From: Stephan A. Rickauer [mailto:[EMAIL PROTECTED]
> Gaby vanhegan wrote:
> > $if_in="xl0"
> > $if_out="xl1"
> > pass in on $if_in keep state
> > pass out on $if_out keep state
>
> Ok, let's stick to that example. Imagine a firewall having three
> interfaces connecting Internet, LAN and DMZ. When I would
> like to allow
> SMTP traffic to my mail server in the DMZ, from LAN _and_ Internet,
> where would you filter?
Look at this netfilter rule again:
iptables -A FORWARD -i in-iface -o out-iface ...
You're simply allowing any traffic which comes in on 'in-iface' and goes out
on 'out-iface'. Put simply by itself, all its doing is allowing traffic to
cross interfaces (as someone said before, not originating from the firewall,
not destined to the firewall. Contrary to what others said, the FORWARD
chain is not for any form of NAT.) Your "..." doesn't say what else you're
doing, like passing through the state module, or whatever, but we'll assume
you are.
PF allows you to match (filter) on the incoming interface ("pass in on
$ifname ..."), and then you need to specify where you are going to allow the
traffic to. Depending on your configuration and topology, you can accomplish
what you want in more than one way. You will want to read pf.conf(5), and
then re-read it, and then go back and re-read the most important parts (to
your situation) again. Also read the PF FAQ on www.openbsd.org.
So you have a mail server in the DMZ, and you need to allow access to it
from your LAN and from the Internet. If you choose (like many do) to apply
your filters on the incoming interface - so that the packet gets droppped
before traversing the firewall in the event that it is prohibited
communication - you can safely end up with two rules.
pass in on $ext_if proto tcp from any to $smtpsvr port 25 keep state
pass in on $lan_if proto tcp from any to $smtpsvr port 25 keep state
Or you can group interfaces for one rule:
nodmz_ifs = "{" $ext_if $lan_if "}"
pass in on $nodmz_ifs proto tcp from any to $smtpsvr port 25 keep state
Point being, you're not going to find a 1-to-1 mapping for all of your
netfilter rules into PF syntax. Rather, you should take the concept of what
your netfilter ruleset is accomplishing, and map that into PF. This is real
"migration." You will likely end up implementing some rules differently. You
could end up with more rules per count, or maybe less.
DS
