[j-nsp] Re: Re: Re: Re: Interfaces, deactivate vs disable

[Daniel Roesen]

On Thu, Jun 09, 2005 at 06:05:41PM -0400, Richard A Steenbergen wrote:
> I think you're over-complicating it. Just as we now have:

Probably.

> filter blah {
>     term foo {
>         ....
>     }
>     term bar {
>         ....
>     }
>     then {
>         default action which always stays on the bottom here;
>     }
> }
> 
> This only seems logical, since most firewalls will have some default 
> action for that which doesn't match (a default reject, accept, log, etc). 

Yes, but I'm always uncomfortable with mixing the terms syntax with
the no-terms syntax. I just doesn't look "right". Perhaps "then"
without a covering term should be forbidden if other terms do exist,
and instead call it "default". THAT would make sense to me. And this
could work the same way in policies.

So you can have either:

filter/policy blah {
    term foo {
        ....
    }
    term bar {
        ....
    }
    default {
        default action which always stays on the bottom here;
    }
}

but still policies like:

policy blah {
    then {
        ...
    }
}

or

policy blah {
    from {
        ....
    }
    then {
        ....
    }
}

> Of course what I would really kill for is chained firewall filters like we 
> have chained policies, but lets start with this dirt simple feature first.

Oh indeed. I have that on my long christmas wishlist too. :)

$ grep "filter chain" vendor/juniper/JunOS-featurerequests
- support firewall filter chains on interfaces

That would make it easy to combine generic filters with
interface-specific ones... which isn't possible atm.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0