Re: PIX 525 and swapping interface definitions

In article <2b0c93f0-2129-44d1-b5be-5722cbacaab1@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<Bod43@xxxxxxxxxxxxx> wrote:

Well this is a first - I absolutely never thought that I might
give any form of pix advice to Walter, or anyone else
for that matter.

Maybe it's new but I have been doing a bit of pixing recently
and on 6.3.4 if you do something like

access-list fred line 4 your.acl.spec

It puts it in BEFORE the existing line 4 as shown
in the show access-list command and the acl is
renumbered immediately.

Unfortunately that isn't reliable in this situation. When you do that,
the existing "line 4" is still there and would still reference the
other interface. If the ACL is used in a crypto map or static or nat
statement, then the extra ACL line referencing the old interface
will quite likely mess up the configuration, probably in
very subtle ways (i.e., you will likely end up with operational modes
that do not match the configuration, and then have a heck of a time
trying to figure out why you are having problems!)


If you have an ACL used in a crypto map, and you need to modify that
ACL, then there are only two reliable routes:

a) disable the VPN on that interface (completely, for -all- peers),
clear off the old ACL, build the new ACL, re-issue the crypto map
command that references the ACL, and re-enable the VPN; OR

b) build complete new crypto maps and ACLs with new names,
activate the new crypto map on the interface, and then clear off the
old crypto maps and ACLs. This approach has the advantage of
minimal downtime for the VPNs; the tunnels whose crypto map
access-list entries stay functionally the same sometimes even stay up
without interruption when this approach is used.

In particular, it is NOT reliable to leave the VPNs active but to
change an ACL referenced in a crypto map access-list entry, and
it is NOT reliable to leave the VPNs active but to remove a crypto map
access-list command and then add the replacement crypto map access-list
command (and in PIX 6 you must proceed by removal and then insertion
as it will not allow you to change that line by issuing an updated
version of the line: it will complain that there is already an
existing access-list for that policy.) It is also NOT reliable to
remove a complete crypto map policy with a lower policy number
(higher priority) than another policy (for a different peer) and then
to put the old lower-numbered policy back in place: unless the
access-lists were absolutely mutually exclusive by design, this
approach *will* mess up your VPNs in ugly ways.


This discussion is, of course, all predicated upon the assumption
that you have an access-list or nat or static that references the
interface being renamed. If you do not (i.e., if you only use public
IPs and do not PAT anything through the PIX interface itself and
have not configured your crypto maps so that your remote peers can
respond to pings initiated from the PIX itself) -- if your configuration
is interface clean, then probably all you have to do besides
issueing the new nameif commands and re-issuing the commands to assign
the public IP to the new interface, is to disable the crypto map against
the old interface and apply it against the new interface. But if your
configuration is not interface- clean, such that you might be
considering using access-list line # to edit ACLs in place to
adjust for the new interfaces, then your configuration is probably
complex enough that you risk the PIX gumming up its internal state
if you do not make the change cleanly in the manners I outlined.
.

Relevant Pages

  • Re: [fw-wiz] PIX 501 to PIX 515 IPSec VPN failure, when the 515 already has a VPN
    ... have an acl entry there matching your interesting traffic acl for the ... to remove the crypto map from the 515 before adding the second 505, ... and then re-apply it to the interface. ...
    (Firewall-Wizards)
  • Re: [fw-wiz] PIX 501 to PIX 515 IPSec VPN failure, when the 515 already has a VPN
    ... to remove the crypto map from the 515 before adding the second 505, ... and then re-apply it to the interface. ... It looks like the ACL and maps could get corrupted, therefore, before ... and FG already have an IPSec lan-to-lan VPN between them that works fine. ...
    (Firewall-Wizards)
  • PIX-515E Default routing and cryptos
    ... should be pumped out and natted to which interface. ... fixup protocol dns maximum-length 512 ... crypto map outside_map 20 match address outside_cryptomap_20 ... isakmp policy 20 authentication pre-share ...
    (comp.dcom.sys.cisco)
  • Re: Pix 515 VLAN NAT0 issues
    ... that ACL will be exempt from NAT. ... the packet at the time the PIX receives the packet. ... ACL applied to an inside interface would have the internal IPs as ... accepted as having a translation and satisfying the security policies. ...
    (comp.dcom.sys.cisco)
  • Re: IPSEC to PIX 515
    ... as for the "savvis" interface - we are in teh midst of switching from ... access-group savvist in interface savvist ... crypto map outside 1 match address savvis ... fixup protocol dns maximum-length 512 ...
    (comp.dcom.sys.cisco)