cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13872
Views
10
Helpful
18
Replies

ASA 8.2 to 8.4 upgrade NAT question

billmatthews
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

@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

Thanks,
Varun Rao

View solution in original post

18 Replies 18

varrao
Level 10
Level 10

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

Thanks,
Varun Rao

Varun,

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

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

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.

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

Thanks,
Varun Rao

@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

Thanks,
Varun Rao

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.

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

Thanks,
Varun Rao

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.

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

Thanks,
Varun Rao

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. 

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

Thanks,
Varun Rao

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? 

Hi Thomas,

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

Thanks,

Varun

Thanks,
Varun Rao
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: