On Thu, Mar 20, 2003 at 12:43:52AM +0100, Henning Brauer wrote:
> > 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?
Sure. However, if you only "block in all", you will end up in situation
where TCP_RESET for tcp and ICMP_UNREACAHBLE for udp can't get back to the
source.
> > 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.
I guess we could tweak a bit more out of pf(4) if we had this. Let's
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???
When did I say that? I'm a big fan of 'block all' and everybody should
;) No?
> > 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?
I do want to _block_ outbound as well. Call me paranoid, but I like to
define what can pass in and out, even on the same interface. Sure, this
makes things more difficult, but it's worth the trouble.
> > 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.
Never really used ipf, but it works like a charm on PIX.
> > 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.
Which can make clients 'hang' waiting for a TCP_RESET/ICMP_UNREACHABLE.
I'll post a ruleset explaining issues I'm having. It _just_ might make
things clearer.
Case (almost) closed.
