[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pf(4) schemantics



On Thu, Mar 20, 2003 at 06:11:28PM +0100, Srebrenko Sehic wrote:
> 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.
huh? well, then pass these. or simply do "pass out all keep state".
> > > 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.
I will do this to prevent ruleset traversals on interfaces where you do not
want to filter at all, eventually. wether this makes sense or not is a pure
performance question.
> > > 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?
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.
arrrrrrgggh! EITHER you have trusted interfaces like kjell suggested, OR you
do not block out as I suggested, or you have to filter in both directions on
both interfaces.
your expectations and your ruleset just don't fit.
Just the fact that crisco is doing stooopid things doesn't mean we need to
follow.
> > 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.
well, you still can pass this stuff explictely, you can use the model kjell
suggested and filter only on one interface at all (self-protection only on
the otehrs perhaps), and you have 136733933 more possibilities.
> I'll post a ruleset explaining issues I'm having. It _just_ might make
> things clearer.
no, not at all. this would bring us back to the stone age (ipf).
> Case (almost) closed.
for me it's closed.