• Pix To Asa 8.4 Migration Tool

Does anyone know of a tool that can convert a pre-8.3 ASA configuration (access-lists and NATs in particular) to a post-8.3 format? The ACLs in the newer code reference the private IPs. This would save me a ton of time so I may end up writing a script myself to do this.

Hi all, So in a month or so we will be getting our second ASA 5510 for firewall purposes (the other one we use for VPN. Security requires us to have these services separate and on different devices). My question is when I convert all my pix (515E) firewall rules, etc to ASA will the certificates on the pix (if we use them) also be converted over too?

I am trying to plan this out ahead so I have no downtime or very minimal amount of downtime when I take the pix offline. Any help would be greatly appreciated! Its going to depend largely on your code base. 8.3 code for the ASA changes a lot of things that wont translate directly from the PIX. If the code is pre 8.3, most of your config should be easily entered into the ASA. Id copy of the config off the PIX as step 1 and when you get the ASA in, spend some time doing the base config. Get as much of the PIX config loaded on the ASA as you can and spend some time testing it before you put it online.

If you have an available switch (or even some empty ports you can assign to a temp vlan) you should be able to do a fairly realistic function test. Just hook up the ASA outside interface to the switch and hook up a computer to the same switch. Create a static route on the computer pointing to the address you want to test and give it a go.

Hope that helps! Its going to depend largely on your code base.

Pix To Asa 8.4 Migration Tool

8.3 code for the ASA changes a lot of things that wont translate directly from the PIX. If the code is pre 8.3, most of your config should be easily entered into the ASA. Id copy of the config off the PIX as step 1 and when you get the ASA in, spend some time doing the base config.

Get as much of the PIX config loaded on the ASA as you can and spend some time testing it before you put it online. If you have an available switch (or even some empty ports you can assign to a temp vlan) you should be able to do a fairly realistic function test. Just hook up the ASA outside interface to the switch and hook up a computer to the same switch.

Create a static route on the computer pointing to the address you want to test and give it a go. Hope that helps!Thanks! Our Pix version is 8.0(4).

Sadly I do not have any spare switches but by the time the device comes I should have a few ports available. I was planning on creating a backup of the PIX config and do the whole conversion tool option and then upload it to the ASA and see what all is configured / their. Will be much easier in ASDM for sure! I will use my PC for the function test and have them both in the same VLAN. I appreciate your help! The upcoming months will be fun. PIX to ASA conversion tool is really for 6.x to 7.x upgrades where the command set was drastically changed.

You don't need it for what you are doing. Downgrade the code on the new ASA to one that reasonably matches what's on your PIX (8.0.4 is available on the ASA so that will work).

Take the existing configuration from the current PIX, change the interface identifiers on it to match the new hardware and load it in. This will not work for any private key pairs you generated, and any signed certificates that you have based on those key pairs. If the key pair was marked as exportable when you generated it then you can export it (sftp or something like that) and then import back into the new ASA. If not marked as exportable you will need to make a new pair then get a new cert issues based on the new private key.

Once it's up and working then you can upgrade to 8.2(something) and then on to 8.4 if you like, I would avoid 8.3 if you can help it. PIX to ASA conversion tool is really for 6.x to 7.x upgrades where the command set was drastically changed. You don't need it for what you are doing.

Downgrade the code on the new ASA to one that reasonably matches what's on your PIX (8.0.4 is available on the ASA so that will work). Take the existing configuration from the current PIX,O that makes sense. I will try that first (I just have to get the 8.0.4 for the ASA first, come to think of it we should have it considering we have another ASA 5510 acting as our VPN appliance). Change the interface identifiers on it to match the new hardware and load it in. This will not work for any private key pairs you generated, and any signed certificates that you have based on those key pairs. If the key pair was marked as exportable when you generated it then you can export it (sftp or something like that) and then import back into the new ASA. If not marked as exportable you will need to make a new pair then get a new cert issues based on the new private key.

I checked the pix and I did not see any certs through ASDM at all. On the VPN appliance though I see certs. I guess I will just do a show config on the PIX again just to make sure. TechExams.Net is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco®, Cisco Systems®, CCDA™, CCNA™, CCDP™, CCNP™, CCIE™, CCSI™; the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. In the United States and certain other countries. All other trademarks, including those of Microsoft, CompTIA, Juniper ISC(2), and CWNP are trademarks of their respective owners.

Powered by vBulletin® Version 4 Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Search Engine Optimization by 3.6.0.

Asa 8.3 upgrade what you need to know. 1. ASA 8.3 Upgrade -What You Need to Know First Things First First, let's make sure we get one thing clear; upgrading your ASA from 8.2 to 8.3 is NOT a Minor upgrade! There are significant internal architectural changes around NAT and ACLs in 8.3. And, more importantly to you (the customer) are the following: 1.

The NAT CLI commands are completely different from all previous version of ASA 2. The IP addresses used in the ACLs are different (pre-8.3 versions used the global/translated IPs, whereas 8.3 always uses the real IPs (untranslated) 3.

A new concept of host-based objects was introduced, to allow singular hosts to be referenced by their names (previously, we had the name command, but that was more of a macro-substitution in the show running-config output). Pre-Requsites to Upgrading Many models of the ASA require a memory upgrade prior to upgrading the ASA to version 8.3. Brand new ASAs from the factory (manufactured after Feb 2010) come with the upgraded memory. However, if your ASA was manufactured before February 2010, and is one of the models below requiring a memory upgrade, then you will need to purchase the memory upgrade part prior to installing 8.3 on your ASA. Pre-8.3 Memory 8.3 Memory Memory Upgrade Part Platform License Required Required Number Unlimited (inside 5505 256 MB 512 MB ASA5505-MEM-512= hosts=Unlimited) Security Plus 5505 256 MB 512 MB ASA5505-MEM-512= (failover=enabled) No Memory Upgrade 5505 All other licenses 256 MB 256 MB Needed 5510 All licenses 256 MB 1024 MB ASA5510-MEM-1GB= 2048 MB. 5520 All licenses 512 MB ASA5520-MEM-2GB= 5540 All licenses 1024 MB 2048 MB. ASA5540-MEM-2GB= No Memory Needed No Memory 5580 All licenses 8-16 Gb 8-16 Gb Needed.Note: The maximum memory supported for the ASA-5520 and ASA-5540 is 2 Gb.

If you install 4 Gb of memory in these units, they will go into a boot loop. 5550 All licenses 4096 MB 4096 MB How to Determine How Much Memory Your ASA Has From the CLI, you can issue the show version include RAM command to see how Upgrade Upgrade. much memory your ASA has.

In the following example, it is an ASA-5520, with 512 MB of RAM, and therefore would require a memory upgrade prior to installing 8.3 on it. ASA# show version include RAM Hardware: ASA5520, 512 MB RAM, CPU Pentium 4 Celeron 2000 MHz For ASDM users, you can see the amount of RAM in the ASA from the ASDM Home (Device Dashboard) page. Why Does the ASA Need a Memory Upgrade? This seems to be a fairly common question with customers. Why exactly are we requiring a memory upgrade in order to run 8.3? The reason is simple.

The memory on the ASAs have not been increased since they were originally introduced, yet as the years have gone by new features have been added which require additional memory at boot. The more memory the base image requires, the less memory there is for things like ACLs, connections, IPSec tunnels, SSL tunnels, etc. Additionally, as we introduce new features and customers adopt those, they consume additional memory. Remove nat-control from your ASA Configuration nat-control is a legacy feature which was created to help users migrate from PIX 6.x to PIX/ASA version 7.0 and higher. In PIX 6.x, if you wanted to pass traffic between two interfaces, it was required that you have a NAT configuration which would allow it. PIX/ASA version 7.0 removed this restriction, and made the behavior like routers. Which is, ACLs control if traffic is permitted or not.

NAT then becomes optional. However, in order to preserve the behavior for the PIX customers, if a PIX user upgraded from 6.x to 7.0, then the nat-control command was automatically added to the configuration. The same is true of customers using the PIX to ASA migration tool. Thus, there may still be a number of customers with nat-control in their configuration, and who do not need it. What happens if I remove the nat-control command? Answer: Not much.

Removing the command just means that traffic can flow between interfaces without requiring a nat policy. Therefore, the security policy of what traffic is permitted or denied is defined by your interface ACLs. What happens if I leave the nat-control command in my configuration? Answer: Since 8.3 no longer supports the nat-control command, it will add equivalent nat commands to enforce a policy which requires explicit nat rules to allow traffic to pass between interfaces. An example is shown below. Note that the number of these rules increases exponentially with the number of interfaces on your ASA.

Thus, it is highly recommended that if your security policy (ie: ACLs) is used to. control what traffic is allowed where, then you should issue no nat-control prior to upgrading to ASA version 8.3. This will prevent the following nat rules from being created - which will block traffic between interfaces, until a more specific nat policy is defined for that traffic.