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 Gig1
- changing the security levels
Can I do it this way and not lose any of the config?
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.)
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.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.