On Thu, Mar 20, 2003 at 12:19:13AM +0100, Srebrenko Sehic wrote:
> On Wed, Mar 19, 2003 at 11:27:26PM +0100, Henning Brauer wrote:
> > > 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.
> Well, yeah, they do, but why have pf(4) look at them both on in and out
> and on the same interface?
who says same interface here??
> > > 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?
>
> No clear? Let me rephrase. Why not filter on inbound traffic only, even
> though you have 'block all' in your ruleset?
this is like asking why your car engine doesn't work even given you have
fuel in a tank on the seat.
if you want that, you don't do "block all", but "block in all" and let
outgoing traffic pass unconditionally. easy, eh?
> The commerical firewall I was talking about previously is Cisco PIX.
The first PIX was cool: you could install OpenBSD on it without trouble ;-)
> net_a ------> pf(4) <------- net_b, and _not_
>
> net_a <-----> pf(4) <-------> net_b
yeah, and IPF behaved the same, and this behaviour is stooooopid. makes the
setup I drawed below impossible. you can have the same with pf by passing
outbond unconditionally.
> > > - 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.
>
> Of course, kernel does, pf(4) only looks at the traffic. However, it
> might be useful is certain situations. Like, 10 VLAN's, but I only want
> to filter on 5. With a rule 'block all', all 10 VLAN traffic would be
> blocked, right?
so block only on those interfaces you wanna filter on? like, this is
obvious, hmm?
> To rephrase, it could be nice if I could define which interfaces pf(4)
> should care about. Something like,
>
> set filter interface {vlan01, vlan02, vlan03}
indeed I have something like this in mind, but purely for performance
reasons. might add that after 3.3. perhaps not. we'll see.
> and assuming you have 'block all'. Right?
no, read on.
and HELL, you say all the time you do not want block all, so why are you
doing block all in your ruleset???
> Well, you managed to confuse me now. Let's throw in some simplified
> ascii and sample rules,
>
> $ext_if <-----> pf(4) <----> $int_if
>
> ext_if = "fxp0"
> int_if = "fxp1"
> ext_net = "192.168.0.0/24"
> int_net = "192.168.1.0/24"
> webserver = "192.168.1.2/32"
>
> block in all
> block out all
>
> ## allow traffic on $ext_if to $webserver on 80/tcp and 443/tcp
> pass in on $ext_if proto tcp from any to $webserver port {80, 443} \
> keep state
>
> This would not work. Why? We need to pass out on $ext_if as well (since
> pf(4) filters on both directions). Not only that, we need to pass in/out
> on $int_if as well, since 'block in/out all' applies to all interfaces.
ARRRGGGHHHH!
s/block out all// and you are done! you obviously do not want to block
outgoing, so why do you tell pf to do so? why?
> What could be nice is to have this kind of rule working. pf(4) could
> allow traffic back from $webserver, even though I have 'block in/out
> all'. This is how PIX works.
and this is how ipf worked, and it was majorly stupid, because the setuop I
described is no more possible then, while you just pass outgoing
unconditionally and HAVE what you are asking already, and that since the
first pf incarnation in OpenBSD 3.0.
> Am I being a bit more clear now? Or am I _totally_ misunderstanding
> pf(4) innerworkings? ;)
you are just thinking very wrong. you are telling pf to block traffic which
goes OUT on an interface, and complain that pf blocks traffic which is
outgoing on one interface. but you told pf to! so don't tell it to, pass
poutgoing unconditionally, case closed.
