On Wed, Mar 19, 2003 at 11:04:26PM +0100, Srebrenko Sehic wrote:
> While working on a pf(4) tutorial/article, I started wondering about the following,
>
> 1. What's the reason why packets 'travel' across an interface twice
> (both in and out)? This makes, IMHO, writing very tight rules a bit
> tricky. Especially if you want to start off with 'block all'.
?
they come in on one interface and eventually go out on an interface. might
be the same, might be different, depending on routing table and destination.
> 2. Say I 'block all' and then want to pass some traffic from $net_a to
> $net_b. First, I need 2 rules to allow {in,out} traffic from $net_a and
> then 2 rules to allow {in,out} traffic back from $net_b. Sure, you can
> group the {in,out} rules in one, i.e. pass from $net_a to $net_b.
>
> Now, what could be very nice is to pf(4) behave more like the following,
>
> - from pf(4) point of view, there is only inbound traffic from an
> interface. I.e. all traffic originating from $net_a towards other
> networks is always inbound for pf(4).
> - when I write a rule like 'pass from $net_a to $net_b', I don't need
> to write another rule saying 'pass from $net_b to $net_a'. pf(4) takes
> care of that (we are statefull, right?)
eek?
> - say I have 5 interfaces (or 10 VLANs) I filter on. However, not all of
> the networks need to talk to each other. I.e. I could have a $net_c
> that will not talk to $net_a, but will talk to $net_b. It could be
> nice to be able to define this. Otherwise, the traffic never gets
> routed by pf(4).
what? pf never routes traffic until explicitely told to route via route-to.
then what you want in these cases with a shitload of (probably
vlan-)interfaces, is to define the policy on each. wait, ascii art.
-----------------------
----vlan1----| |
----vlan2----| |
----vlan3----| |-----uplink1
----vlan4----| |
----vlan5----| OpenBSD |
----vlan6----| |
----vlan7----| |-----uplink2
----vlan8----| |
----vlan9----| |
----vlan0----| |
-----------------------
hmm, suprise, that looks exactly like my setup ;-)
so, let's go on. in vlan01, you have just a webserver. the policy is easy:
pass out on vlan1 proto tcp to $vlan1_webserver port { 80 443 } \
keep state
pass in on vlan1 proto { tcp udp } to $resolvers port 53 \
keep state
that's it, basically. might want to add ssh.
in vlan02, you have just a smtp server, and apply similar rules.
on the external interfaces, let's call them dc0 and dc1, you just do spoof
protection.
int_nets="{ vlan1-network vlan2-network .. vlan10-network }"
ext_ifs="{ dc0 dc1 }"
block on $ext_ifs
pass on lo0 quick
block in quick to self
pass in on $ext_ifs to $int_nets keep state
pass out on $ext_ifs from $int_nets keep state
that's it, basically. add some rules to allow some icmp, the box itself to
reach its resolvers etc, and you are done.
with hammering the policy for each vlan on the vlan interface, you have
something very nice achieved. if a box on vlan1 wants to reach a box in
vlan7, it needs to pass the outgoing policy for vlan1 as well as the
incoming one for vlan7.
the only little confusing thing is that all directions are logically
backwards. passing traffic to a webserver _IN_ results in a rule like "pass
_OUT_ on vlan1 ..." (emphasis added, of course). but that you get used to
quickly.
so, I really don't get what you are proposing.
> People that know a certain commerical firewall will recognize this
> behaviour. Don't get me wrong, I love pf(4), but there might be room for
> improvement.
sure, there always is.
> Comments?
explain better ;-)
--
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)
