Feeling intimidated replacing an old ASA with a new ASA

[heath]

We have a pair of pretty old ASA 5580s running 8.2 code.  We just purchased a pair of new 4100 appliances to replace it with.  I will be running ASA on it, not FTD.  But I'm feeling a bit intimidated with the replacement.

The old ASA was initially set up and configured by a previous admin and, well, it wasn't done very well.  There was no true DMZ for one thing.  The old ASAs are not in a HA configuration, but certain vlans (back when the campus was one big layer 2 network) went through one of the ASAs then back into the network through the primary ASA and treated as outside traffic.  I've gradually been pushing Layer 3 down to each building  (about 40 buildings) so this needs to be rethought.  Also the lack of a true DMZ...

I've got one of the 4100 chassis set up with the latest FXOS and a logical device running ASA 9.8.1. with a very basic config and only the management interface live.  And that's where I am at.  And I'm not sure what the best path forward is.

Do I just replicate the old config best I can and keep going with the current architecture?  Do I take this opportunity to re-design the ASA implementation?  Can this be a gradual transition, or does it have to be a hard transfer?  I'm just sort of at a loss.

[deanwebb]

My gut instinct is to preserve production... doing things right as far as what we know to be right can be very wrong for the business as it is currently. If you can actually do a big bang change and the bosses are in favor of it, plan it carefully and away you go.

Otherwise, there may be some app back in the back there that needs that firewall config to run EXACTLY as it is set up or you lose payroll or something important like that.

Therefore, a gradual change will be best and you would want the guys in charge of the production apps to work with you, step by step.

[wintermute000]

You will need to rewrite the NAT portions of your old config. The syntax changed entirely post 8.3.
Google ASA pre-8.3 NAT to post-8.3 NAT stuff or the old CCNP SEC syllabus.

Depends on how complex your setup is. If its not too bad, big bang is feasible. If its really tangled, then keep the risk to a minimum, then change it during a second phase. Generally the second approach is much safer for obvious reasons.


If you want two layers, then you'd multi-context your firewalls and run two pairs of HA contexts. Yeah that gets complicated but its pretty common as most customers don't use anywhere near the rated capacity of a box.

[heath]

Thanks for the suggestions and feedback. 

My gut instinct is to preserve production... doing things right as far as what we know to be right can be very wrong for the business as it is currently

Preserve production.  That's a very good point and I appreciate that perspective.

You will need to rewrite the NAT portions of your old config. The syntax changed entirely post 8.3.

That is one of the main reasons the old ASA is still running 8.2. 

If you want two layers, then you'd multi-context your firewalls and run two pairs of HA contexts. Yeah that gets complicated but its pretty common as most customers don't use anywhere near the rated capacity of a box.

I really don't want to keep the two layers.  It made sense to the previous admin to divide "student" networks and "everything else" to two firewalls when the entire campus was flat layer 2 AND we provided services to student housing.  I have now pushed layer 3 down to the building distribution layer, and we don't provide network service to student housing.  (Back in the late 1990s and early 2000s, the old student dorms were demolished, new "apartment" style housing units were built, and everything to do with them was outsourced.) 

Oh, and did I mention that I am the entire network team? 

[deanwebb]

Congrats on being the whole network team! We all have been the whole network team at one point or another.

I would suggest trying a phased approach that can be tested after-hours. Use route statements to divert traffic from old ASAs to new ones and test for functionality. If functional, leave the route statements in place.

Repeat for other segments of traffic until you have them all weaned off the old firewalls.

Do the easy stuff first, get some nice wins up front, and study up on the changes needed for the advanced stuff.

Be sure to have a description of what needs to be done in front of you. You control the technology - don't let people dictate how to use your technology. If there's another way to get the needed result that's easier than NAT, for example, then you can use that method. (If there are applications hard-coded to use those NAT addresses, then there will be no easier way... you'll be stuck with NAT...)

[DanC]

Have you created some schematics of the current and future setup?

I'd suggest doing that first, both from a physical and logical perspective. Think about the services you're replacing, I.e NATs, routing, DMZ, Remote Access, S2S VPN's etc. Break it down bit by bit and carefully plan what's involved in migrating each element. Take this opportunity to clear out any stale rules, 'show access-list | inc (hitcount=0)' is your friend here.

As already said, a Big Bang can be done but it all comes down to complexity and risk.

Is there a reason you're not running FTD?

[heath]

Thanks for the responses and suggestions.  I did manage to get it done.  The way things were set up, I just couldn't figure out how to make a phased approach work, so it had to be a hard cutover.  I didn't try to import and convert the config, but rebuilt from scratch mostly mirroring the old config.  I had the production teams review all of the existing ACLs and NAT configuration and was able to trim a good bit of stuff out that wasn't actually in production anymore.  I also didn't rebuild any rules that had 0 hits. 

I also have a great Cisco SE who offered to be on site and give me a hand with the cutover and work through any problems. 

[deanwebb]

Glad to hear you got through the work successfully!

[DanC]

Nice work heath