×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

ASA 8.2 to 8.4 upgrade NAT question

Answered Question
Jan 6th, 2012
User Badges:

Hello,


We're planning the upgrade from 8.2 to 8.4, which I understand has NAT and ACL changes.  I've read the migration guide at http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.pdf


My understanding is that the upgrade procedure will convert the NATs, and place real IPs in the ACLs instead of the translated IPs.


But in looking through my 8.2 configs it appears the real IPs are already being used in my access lists.  For example x.x.x.x is my public IP, and y.y.y.y is my internal IP.  This is my current config:


static (inside,outside) x.x.x.x y.y.y.y netmask 255.255.255.255
access-list acl_out extended permit tcp any host x.x.x.x eq ssh


So it seems that the 8.4 upgrade won't need to change anything.  Is that correct?

Thanks
Bill

Correct Answer by varrao about 5 years 7 months ago

@Marvin

Yes you are absolutely right the nats would also change but I was only referring to access-lists, since Bill only wanted to know about ACL's, the nats are the major changes in post 8.3



@Bill


Yes you ca go ahead with teh convertion, just a couple of things to keep in ming:


Disable nat-control (no nat-control)

Disable names (no names)



You can follow this doc as well:

https://supportforums.cisco.com/docs/DOC-12690


Let me know if you face any issues.


Thanks,

Varun

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
varrao Fri, 01/06/2012 - 07:39
User Badges:
  • Red, 2250 points or more

Hi Bill,


No it will not be doing the way you understand, let me explain you with an example, lets say you have the following pre 8.3:


static (inside,outside) x.x.x.x y.y.y.y netmask 255.255.255.255

access-list acl_out extended permit tcp any host x.x.x.x eq ssh


The above ACL would get converted to :


access-list acl_out extended permit tcp any host y.y.y.y eq ssh


where y.y.y.y is the private or real ip of your server.


This is the main differnce in ACL in 8.3


Let me know if you have any more questions.


Thanks,

Varun

Marvin Rhoads Fri, 01/06/2012 - 08:01
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

Varun,


The "static" command would also be changed along with the necessary creation of network objects, yes?

billmatthews Fri, 01/06/2012 - 08:04
User Badges:

Thanks guys. 


In general what's the experience with all the auto-conversions?  Should I have confidence that after the upgrade my config will be working? 


I'm new to the ASAs (came from CheckPoint), and didn't do the original setup.  But my general thoughts is that our config is rather simple.  Here's a snapshot (all IPs have been changed, so I apologize if some may not make sense)...




global (outside) 2 12.12.12.211 netmask 255.255.254.0
global (outside) 3 12.12.13.211 netmask 255.255.254.0
global (outside) 1 12.12.13.112 netmask 255.255.254.0
global (inside) 1 interface
global (dmz1) 1 204.168.85.111-204.168.85.199 netmask 255.255.255.0
global (dmz1) 2 13.13.13.13 netmask 255.255.255.0
global (dmz1) 3 13.13.13.210 netmask 255.255.255.0
global (dmz2) 1 13.13.13.111 netmask 255.255.255.255
global (dmz2) 2 13.13.13.211 netmask 255.255.255.0
global (dmz2) 3 13.13.13.210 netmask 255.255.255.0
global (dmz3) 1 10.10.224.129-10.10.224.148 netmask 255.255.255.192
global (dmz3) 1 10.10.224.128 netmask 255.255.255.192
global (dmz3) 2 10.10.224.151 netmask 255.25.255.192
global (dmz3) 3 10.10.224.150 netmask 255.255.255.192
nat (outside) 1 NAC_Bypass_VPN_Pool 255.255.255.0
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 3 access-list inside_nat_outbound_1
nat (inside) 2 access-list inside_nat_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
nat (DMZ-VPN) 0 access-list DMZ-VPN_nat0_outbound
nat (dmz1) 1 0.0.0.0 0.0.0.0
nat (dmz2) 0 access-list DMZ2-nat
nat (dmz2) 1 0.0.0.0 0.0.0.0
nat (dmz3) 1 0.0.0.0 0.0.0.0
static (dmz1,outside) 140.1.1.1 12.12.12.10 netmask 255.255.255.255
static (inside,dmz3) 10.19.10.190 10.4.5.10 netmask 255.255.255.255
static (inside,dmz3) 10.44.13.189 10.4.5.12 netmask 255.255.255.255
static (inside,outside) 12.12.12.4 10.2.55.74 netmask 255.255.255.255

...about 50 more static NATs...


Any areas of concern regarding the upgrade?


Thanks

Marvin Rhoads Fri, 01/06/2012 - 08:24
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

I've not done an 8.4 upgrade yet though I'm planning one myself this month.Cisco assures me the syntax conversion will work fine; though I plan to open a TAC case straight away is it goes at all south.


There is an upgrade log file created and stored in flash. You should check it and resolve any noted issues before going home for the day.


Personally I also plan to look at before and after configs side by side (I like ExamDiff) and assure myself that I account for everything that's changed.


One thing to make sure is that your pre-upgrade backup is complete including any pre-shared keys and certificates. Use the ASDM backup utility and/or something like "more system:running-config" since those obscure bits won't be saved in a simple "show run" type of backup.

varrao Fri, 01/06/2012 - 08:30
User Badges:
  • Red, 2250 points or more

Yes Marvin, what you planning is a safe way, you can open a pro active TAC with us and have the engineer keep an eye on the converted configuration and ensure all works fine after the upgrade.


Backups of everything is very very important be it upgarding to any version. There always have to be a Plan B while doing it.


Thanks,

Varun

Correct Answer
varrao Fri, 01/06/2012 - 08:28
User Badges:
  • Red, 2250 points or more

@Marvin

Yes you are absolutely right the nats would also change but I was only referring to access-lists, since Bill only wanted to know about ACL's, the nats are the major changes in post 8.3



@Bill


Yes you ca go ahead with teh convertion, just a couple of things to keep in ming:


Disable nat-control (no nat-control)

Disable names (no names)



You can follow this doc as well:

https://supportforums.cisco.com/docs/DOC-12690


Let me know if you face any issues.


Thanks,

Varun

Marvin Rhoads Fri, 01/06/2012 - 08:34
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

Varun,


The doc you linked had two different thread recommendations re "names" vs."no names". Are you confirming that one should first enter "no names" prior to upgrade?


Thanks.

varrao Fri, 01/06/2012 - 08:38
User Badges:
  • Red, 2250 points or more

Yes Marvin, thats what I meant, you can do "no names" before the upgrade and then once the upgrade is done you can put the names back "names"


Thanks,

Varun

billmatthews Fri, 01/06/2012 - 08:41
User Badges:

Great advice guys, thanks!  I'll be sure to get a good backup.


Varun, regarding the pro active TAC case idea, when would you suggest we do that?  The morning of the upgrade, or even more in advance?  I'm just not sure how long it would take to get an engineer assigned if it's not a sev1.

varrao Fri, 01/06/2012 - 08:48
User Badges:
  • Red, 2250 points or more

Well TAC can definitely help you a great deal in it, earlier the better, if the engineer has some time at his hands, we can try it on a lab ASA and check the configuration after conversion and clear out any glitches if present. So it becomes a bit easier when you perform it on a production environment.


Hope that helps,


Thanks,

Varun

thomascollins Fri, 01/06/2012 - 12:00
User Badges:
  • Silver, 250 points or more

FYI, I'm planning a similar upgrade (8.2 to 8.4) and have a TAC case open to prepare.  TAC is recommending you don't do a direct upgrade.  They recommend: 8.2 --8.3.1---8.3.2----8.4.  And for 8.4 they published an engineering release with some bug fixes. 

varrao Fri, 01/06/2012 - 12:05
User Badges:
  • Red, 2250 points or more

Are you talking about the image 8.4.2.8, step by step is what you call the best practice, in some procedure's that I have carried out, I haven't faced any issues yet. But yes, if you're code is a pretty old one like 7.x or 8.0, step by step becomes necessary.


Thanks,

Varun

thomascollins Fri, 01/06/2012 - 12:08
User Badges:
  • Silver, 250 points or more

Hi Varun, TAC published asa842-18-k8 to me.  I'm upgrading from 8.2.  Would you recommend the step by step upgrade or do you think we would be safe going straight to 8.4? 

varrao Fri, 01/06/2012 - 12:37
User Badges:
  • Red, 2250 points or more

Hi Thomas,


Go step by step since you are upgarding to an engineerng release, it shoudl be the right one for you.


Thanks,

Varun

thomascollins Fri, 01/06/2012 - 12:43
User Badges:
  • Silver, 250 points or more

Thanks.  What would be the upgrade plan for an HA active/standby pair?


  1. Take unitA offline, upgrade unitB using step by step
  2. Run no failover on unitB, bring unitA back online
  3. Upgrade unitA (just straight to 8.4, no step by step needed this time)
  4. Enable failover, let config sync


Does that sound right?

varrao Fri, 01/06/2012 - 12:52
User Badges:
  • Red, 2250 points or more

Nope, the best would be to make the primary active and upgrdae the secondary (standby) first to the image that you would like to finally go to, failover and make secondary active and and then upgrade the primary box to the right image, this way you would not lose any traffic and would be up all the time.


Thanks,

Varun

thomascollins Fri, 01/06/2012 - 12:54
User Badges:
  • Silver, 250 points or more

That makes a lot more sense, I like that.  But for some reason that's not what another engineer recommended (SR

620272873)


Tom

varrao Fri, 01/06/2012 - 13:05
User Badges:
  • Red, 2250 points or more

Hey Thomas, I just went through it and there are two things in here:


Number one - going by the book (which is wat the engineer recommends you)

Number two - my own personal experience, because there have been situations where in some TAC's I did a lab repro for the upgrdae as other customers were apprehensive about doing it on their production device, I did the way I told you, no issues.


So what he must have told, would definitely have a good reason for it or some experience that he can share, I would say, you can definitely talk to the engineer and he would definitely explain you his reason behind it. Just make sure you have your memory requirements spot on.


I hope I was able to clear it out.


Thanks,

Varun

Actions

This Discussion

Related Content