PIX 525 and swapping interface definitions

Discussion in 'Cisco' started by pfisterfarm, Mar 28, 2008.

  1. pfisterfarm

    pfisterfarm Guest

    I've got a PIX 525 with a FastEthernet connection to a 2900 switch
    (which is the outside interface). The switch is going to be replaced
    by a 3560G and at the same time, the connection will be upgraded to
    Gig Ethernet over fiber (the PIX already has Gig ports, and the inside
    interface is GigabitEthernet0). Is the change to the PIX as simple as:

    - renaming the current outside interface (Ethernet0) to something else
    and disabling it (changes would be done through the inside interface)
    - removing the ip address and subnet mask from Eth0 and putting it on
    - changing the security levels

    Can I do it this way and not lose any of the config?

    pfisterfarm, Mar 28, 2008
    1. Advertisements

  2. pfisterfarm

    Merv Guest

    well what ever you decide to do the first thing to do is make a backup
    ( perhaps several) of the working config
    Merv, Mar 29, 2008
    1. Advertisements

  3. Probably not.

    Anywhere the interface name appears in the configuration past the
    'nameif' statement that defines the interface name, internally
    the PIX stores the hardware interface name, not the software name.
    Thus if you rename the interfaces and then look in the configuration
    you will find that those lines suddenly refer to the new name for
    the old interface, whereas what you want is for them to refer to the
    new interface.

    Probably the easiest solution is to upload your configuration to
    a tftp server (on an interface that is not changing!), and edit
    the configuration there to have the new 'nameif' statements,
    and put a bunch off 'clear' statements in that version of the configuration
    (e.g., clear each access-list in a statement immediately before the
    access list is defined in the configuration.) Once you've done that,
    tftp the modified configuration over to the 525 (e.g., use
    'config net' in configuration mode if it is PIX 6).

    This method of changing the configuration -will- disrupt services
    for a couple of minutes.

    If it is important to keep the service disruption to a minimum, then
    tftp as per the above, but instead of 'clear' the old access-lists,
    discard any access list that doesn't reference the old interface, and
    in the config file, change the access-list names of whatever is left,
    and trim the config file down to just the statements (such as static
    and nameif) that reference the interface. Use some temporary interface
    name in the ACL statements. After all the revised ACLs, put in
    appropriate access-group statements referencing the temporary interface
    name, and 'no access-group' the old ACL name off of the old interface
    name. Then have nameif statements that rename the old interface to some
    unused name and rename the new interface to the name you want.
    Unfortunately at that point, you will have to clear the old static
    statements that reference the old interface, and then have the new
    static statements: you probably won't be able to avoid that disruption
    in service because (especially if you have static or nat with
    access-list qualifiers) you would otherwise run into complaints about
    trying to static the same IP address to multiple places.

    The advantage of using new ACL names is that while you are building
    the new ACL you can have the old one still in effect; if you reuse
    the ACL name then you have to clear the ACL before you can establish
    the new version of it (otherwise the changes would go at the end of
    the ACL instead of in the proper place.)
    Walter Roberson, Apr 2, 2008
  4. pfisterfarm

    Bod43 Guest

    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.

    So if you have a batch to put in in order
    after line 3 you do

    access-list fred line 4 your.acl.spec
    access-list fred line 5 your.acl.spec
    access-list fred line 6 your.acl.spec

    Clearly in the OPs case doing new acls is likely
    to be the best option but it might be handy one day.

    I have not checked the exact syntax so you will
    have to before you use these commands:)
    Bod43, Apr 2, 2008
  5. 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.
    Walter Roberson, Apr 2, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.