[j-nsp] When will ASM/ASPIC configuration gain prefix lists?
Michael Loftis
mloftis at wgops.com
Fri Mar 3 08:20:45 EST 2006
--On March 3, 2006 1:04:24 PM +0300 Alexander Tarkhov <karabass at gmail.com>
wrote:
> Hi Michael,I'm not sure what you are actually trying to do with packets...
>
> In general I still think it is possible to select some packets for
> statefull processing based on a prefix-list match. And this requires
> applying service-filter at the same point where you also apply the
> service-set. Missing service-filter is equivalent of "always match", so
> that every packet goes through service-set.
>
> May be if you have multiple service sets and would like to select one of
> them based on a prefix-list match... not sure if that is allowed. I have
> to look at it in the lab.
Yeah I'm not sure about the behaviour of 'skip' -- from what I can tell
this would require a service-filter and a post-filter in order to work.
Because in my mind if you 'skip' service processing for a packet you don't
automatically discard or reject it.
Basically the 'common' thing I need to do is allow access to various
management ports from only specific hosts, but allow access to public ports
(like HTTP, HTTPS) from the world. That's the most usual form that I need
to be able to maintain like this. It means essentially maintaining *three*
copies of the rules, though since the rules are more static than the lists
of hosts this is probably better/easier but still prone to potential
errors. One to select for service processing, the service processing, then
the non-service processing (IE skip-ed packets) unless one can do multiple
service sets and they're applied in-order or something. It's something
I'll be poking at in the lab myself. Though my 'lab' is a non-production
interface on my production M7i (not gifted with nearly a fat enough budget
to get an M7i just for testing).
It's silly because all that really needs to happen is a 'macro
preprocessor' on the stateful firewalls to allow it to understand prefix
lists. I'm not looking for arbitrarily large ones like the filter's can
support, just something to cut down my maintenance.
More information about the juniper-nsp
mailing list