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:
The NAT CLI commands are completely different from all previous version of ASA
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)
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.
PlatformLicensePre-8.3 Memory Required8.3 Memory RequiredMemory Upgrade Part Number
Unlimited (inside hosts=Unlimited)
Security Plus (failover=enabled)
All other licenses
No Memory Upgrade Needed
2048 MB *
2048 MB *
No Memory Upgrade Needed
No Memory Upgrade 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.
How to Determine How Much Memory Your ASA Has
From the CLI, you can issue the show version | include RAMcommand to see how 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.
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-controlis 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-controlcommand 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-controlprior 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.
If you forget to issue no nat-control prior to upgrading, then it is safe to remove the all 0's objects with associated nat rules after the fact.
To view your current nat-control configuration, issue the command show run all nat-control.
How to Upgrade Your ASA to 8.3
Upgrading your ASA to 8.3 is the same process as all previous upgrades. Just copy the image over to the flash, specify the file to boot, and then reboot your ASA. Upon first boot, the ASA will auto convert your 8.2 configuration into the new syntax for NAT and ACLs required of 8.3. While your CLI commands will change, your devices security policy will remain the same.
Please note that we only support upgrading to 8.3 from 8.2. Therefore, you need to be running 8.2 on your ASA prior to upgrading to 8.3.
Note: During the upgrade process, the ASA will save two files on disk.
The current (pre-upgraded) configuration in a file named <version>_startup_cfg.sav Example: disk0:/8_2_2_0_startup_cfg.sav This file will be critical if you need to downgrade your ASA from 8.3 to 8.2 in a future date
Warning messages and Errors encountered during the upgrade process of converting your configuration to 8.3 will be saved in a file named upgrade_startup_errors_<timestamp>.log
Cisco officially supports upgrading to ASA version 8.3 only from ASA version 8.2. Therefore, if you are currently running a version of ASA code prior to 8.2, you will need to perform a stepwise upgrade. Please see the table below:
Current TrainIntermediate UpgradesFinal Train
8.0 --> 8.2
7.2 --> 8.0 --> 8.2
7.2 --> 8.0 --> 8.2
Examples of Configuration Changes in 8.3
The NAT CLI configuration for 8.3 is radically different than anything than you may be used to. Therefore, for CLI users, it is recommended you ease into 8.3 with the expectation that you will have to re-learn NAT. For those who view this as an obstacle, we would recommend that you use ASDM or CSM or some other GUI tool to configure the ASA - as the GUI configuration for 8.3 is largely the same.
That said, for CLI users, please do not upgrade to 8.3 on a Friday night just as you are getting ready to go out of town for the weekend. Instead, it is recommend that you play with it in a lab (if you have one), or read up on the changes (see Additional Information below) before you upgrade. Ok, with that said, let's look at some examples.
Although the syntax of the ACLs haven't changed much (just added capabilities for new objects), the significant change is that all IP addresses listed in ACLs which are applied to an interface will be converted (on upgrade) from using global (ie: translated or post-NAT) IP addresses, to using the real IP address. Let's look at an example.
In the above Topology, an internal web server (with IP 10.1.1.6) is being protected by an ASA. Clients on the Internet access this web server by its public IP address: 188.8.131.52 Prior to version 8.3, the interface ACL would permit traffic to the public IP 184.108.40.206. But, starting with 8.3 the real IP 10.1.1.6 is used in the configuration. Please see the configuration examples below.
Is it possible to pull a list of objects that are actively being used in an ACL (with hit counts)? The only mechanism I've found is the "find usage" icon beside the object. This obviously is a tedious process through the GUI with a large number of objects...
Does someone know the difference and benefits between Senderbase and Service Logs. From Async 13.5 Service Logs will replace senderbase. According to the shared data per solution different data is offered to talos: Senderbase: machine oriented:https:...
Dear Team ; The current configuration of wireless network is with 802.1x using external group AD Now we want to change the configuration using both of mac authentication and 802.1xIn WLC , Wlans –> Wlans > Security -> layer 2 ->...
I have number of servers with Redis Pipeline (redis.io/topics/pipelining) enabled. A FTD is managing routing access between servers like this:Redis client --->FTD--->Redis Servers192.168.2.10/24-->192.168.70.33/24192.168.2.10/24-->192.168...
Hello, I upgraded CSM 4.19 to 4.22 SP1 to be covered from the CVE-2020-27131 vulnerability.The thing is that the scan finds again this vulnerability. The customer informed me that this path cwhp/CSMSDesktop/about.jsptrigger...