Re: ( don't ) use CiscoVMS to configure PIX firewalls.

In article <1131653702.780883.255520@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
ciscoham <ciscoham@xxxxxxxxx> wrote:
:I've played around a bit with CiscoVMS but find it very disappointing.

:I cannot
:imagine that someone who knows the CLI would start using CiscoVMS to
:manage his PIXES. Does anyone disagree on this ?

I do not disagree about the slowness, or the number of operations
required to enter that which would be simple to do via the CLI.
CiscoVMS does, however, have its uses.

a) CiscoVMS is able (or so it claims) to push a new configuration
out to a remote active firewall. If you have ever tried using the
CLI to configure the very VPN that you are accessing a remote
firewall through, you will know that the process is painful:
the moment you touch the ACL (or any object-group referenced
therein) that defines the VPN tunnel, you have inconsistancies
in your Security Associations (SA's) and may lose the connection.

There are some things you can do to mitigate the inconsistant-SA
problem, but they require essentially duplicating all objects
and ACLs and crypto maps, then activating the new version. But
even then you run into the problem that as soon as you enable
the new crypto map complex on the interface, you have to clear the
SA's in order to put it fully into effect (*strange* things happen
otherwise)... and when you do that, you lose the VPN connection
you are configuring over. This makes it impossible to reliably
push a new configuration out via 'config net' (tftp).

b) If you are working with multiple firewalls in an impure mesh
(only some accesses are allowed between some of the pairs), then
what might seem a simple change can end up requiring a
number of changes which is exponential in the number of firewalls.
For example, adding a udp flow all around to 5 firewalls requires
((2*2) * (4+3+2+1)) = 40 ACL updates. [The udp port as source
+ as destination, times incoming + outgoing ACL, times each of the
mesh pairs.] It doesn't take very long at all before you really
start needing a configuration generator, in which you specify
the flows in a more compact form and have the ACL entries
automatically generated for each of the firewalls. CiscoVMS gives
you that kind of configuration generation potential. It has
notable limitations, and you have to be disciplined to use it
to best effect, but it's a *lot* better to update only four entries
and have that propogate appropriately.

c) I did up a home-brew configuration generator before I found
CiscoVMS. It turned out that using CiscoVMS best requires
the same kind of structuring that I used in my home-brew, but
my generator was text-based so it was a wee bit faster to stick with
it than to go for CiscoVMS. But I'm the -only- person who knows how
my home-brew generator works... it is logical and extensible, but
it isn't something that would be obvious (especially to someone
who hasn't run into the problems that drove me to write the
generator!) If I had done the work in CiscoVMS, I could at least
have handed it over to someone else and they could have read
the documentation and played with the pretty little {slow} GUI,
and placed support calls on it. Technical superiority is not
the only measure of success; it is often not even the most
important measure.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
.

Relevant Pages

  • Re: ( dont ) use CiscoVMS to configure PIX firewalls.
    ... >:I've played around a bit with CiscoVMS but find it very disappointing. ... > push a new configuration out via 'config net'. ... > number of changes which is exponential in the number of firewalls. ... > c) I did up a home-brew configuration generator before I found ...
    (comp.dcom.sys.cisco)
  • ( dont ) use CiscoVMS to configure PIX firewalls.
    ... I've played around a bit with CiscoVMS but find it very disappointing. ... the configuration of a PIX, also the software doesn't recognize several ... command lines from the pixes that I've tried uploading in it. ... interface for users that don't know how to use the CLI. ...
    (comp.dcom.sys.cisco)