Tag Archives: NAT changes

Cisco ASA 8.2 Upgrade to 8.3

Posted on by
Reply

KB ID 0001366

Problem

I can’t believe I’m writing this, it’s been so long since 8.3 was released (7 Years!) And still there’s firewalls out there running old code?

Why is the 8.3 upgrade important? This update made some very major changes to the way we did NAT, and also the way we wrote ACL’s. It was a big change. I remember keeping my client firewalls on 8.2 for a while until I fully understood the changes. And even then if there was anything ‘complicated’ I’d build them with 8.2 and then upgrade them!

So why am I writing this now? Well I’ve done a LOT of these, and every time I’ve got another one to do I check my notes. I was upgrading a clients 5510 today, so I thought I’d polish my notes and publish them for anyone else that has a ‘teal coloured dinosaur’ that needs an upgrade.

 

Solution

Make sure your firewall has enough RAM! To upgrade to/install 8.3 (or above) needs a larger amount of RAM than was installed in the 5500 firewall range before Feb 2010. Cisco RAM is expensive! I suggest a trip to eBay e.g. memory for my 5510 cost me £15.00 and memory for my 5505 cost me $6.00. Ive already written about the memory requirements, see the article below;

ASA – Memory Error (Post upgrade to version 8.3)

Performing the Upgrade 

Step 1: A Few Days Before

Before you do anything, take a full backup of the Firewall. The amount of time I’ve asked ‘You did back it up first didn’t you?’ and the answer is an awkward silence, is far to high!

1. Disable NAT Control (This is a throwback to version 6, when we had to have NAT to pass traffic between interfaces)

You may have it enabled

[box]

Petes-ASA# show run all nat-control
nat-control

[/box]

To disable it;

[box]

Petes-ASA# conf t
 Petes-ASA#(config)# no nat-control

[/box]

Will it break anything? I’ve not seen it break anything.

2. Disable ‘names’: I was never a fan of these anyway, they seemed like a good idea, then made everything difficult to troubleshoot, I routinely disable ‘names’ when I’m troubleshooting things.

[box]

Petes-ASA# conf t
 Petes-ASA#(config)# no names

[/box]

Will it break anything? Absolutely not!

3. Look at all your NAT statements: Their syntax is about to change A LOT, make sure you know what each one is doing, and why it’s there. Study the differences to the NEW NAT commands, and if you have enough time, convert them offline in notepad, then you have the commands ready to post in if there’s a drama. See the following article;

Cisco PIX/ASA 8.3 Command Changes{NAT / Global / Access-List}

Step 2: Performing the upgrade

Note: During the upgrade the Pre 8.3 config is saved as disk0:/{version-number}_startup_cfg.sav, (i.e. disk0/:8_2_5_59_startup_cfg.sav). This will be critical if there’s a problem and you need to ‘roll-back’. Another handy file is upgrade_startup_errors_{time-stamp}.log (i.e. disk0:/upgrade_startup_errors_201711151046.log). But only look in there if you actually have a problem, because there will always be things in this file, and you will only panic needlessly!

The actual upgrade is the same process for any ASA upgrade. My recommendation is to go from 8.2 to 8.4(6), then you can perform further upgrades from there (as required).

Basic upgrade commands;
copy tftp://192.168.50.2/asa846-k8.bin flash
no boot system disk0:/asa825-59-k8.bin
boot system disk0:/asa846-k8.bin
write men
reload

Cisco ASA5500 Update System and ASDM (From CLI)

Post Install Problems?

VPNs Don’t Work? Make sure the upgrade has NOT added the keyword ‘unidirectional‘ to the NAT statements for the VPN tunnel, (bug if you upgrade straight to 8.3(2))

ACL’s Don’t Work? I’ve seen the upgrade process fail to change the IP address from the Public IP to the Private IP in the ACL.(Post 8.3 ACL Statements are written to allow traffic to the internal (pre-tranlslated) IP rather than the external/public (post-transtaled IP,) like you had to do BEFORE version 8.3. This is most common on ACLs applied to the outside interface.

I need to downgrade the ASA back to 8.2!!

To downgrade;

[box]

downgrade {image} {config}
e.g.
downgrade disk0:/asa825-59-k8.bin disk0/:8_2_5_59_startup_cfg.sav

[/box]

Related Articles, References, Credits, or External Links

NA

Cisco ASA – Policy NAT

Posted on by

KB ID 0001042

Problem

I’ve been working on a large firewall deployment for a client, each of their DMZ’s have both a production and a management network. nothing particularly strange about that, but each of their DMZ’s has its own firewalled management network and it’s routable from the LAN.

So If I’m an admin and I want to talk to a Linux appliance in their DMZ via its management interface, my traffic leaves the LAN through the management firewall, but the appliance sees my source IP as being on the LAN, and routes the traffic back to me via the clients production firewall.

Now the simplest way to fix it would be to put a static route on the appliance to route my traffic back via the management firewall, which is fine, BUT what if that appliance is the proxy server? Now I can administer it, but I cant get on the Internet!

Note: I’m NOT performing NAT anywhere in this scenario!

Solution

Well I could simply PAT the network my laptop is on, lets say its 172.16.1.0/16 to the DMZ interface of the management firewall.

[box]

object network Admin_PCs
 subnet 172.16.1.10 255.255.0.0
 nat (inside,dmz) dynamic interface[/box]

The problem with that is it will translate all traffic from my laptop’s subnet going into this DMZ and I might not want to do that.

Solution Pre ASA 8.3

We used to have a really simple way of solving this problem, ‘policy based nat’, you specify a set of conditions with an ACL then anything that meets that ACL is tied to a specific NAT rule.

[box]

access-list POLICY-NAT permit ip host 172.16.1.10 11.11.11.11 255.255.255.0
 !
 static (inside,outside) interface access-list POLICY-NAT[/box]

Solution Post 8.3

To do the same now the syntax is a little different. To demonstrate I have built a small lab in GNS3 to demonstrate. If I want the internal host to talk to the DMZ host, I want the traffic when it gets there to ‘appear’ to have come from 192.168.131.1

To demonstrate, if I ‘ping’ the DMZ router from the Host router, and Wireshark the traffic when it gets there, I see its coming from its actual IP address.

To NAT this traffic use the following commands;

[box]

 For a Single IP

object network obj-Host
 host 11.11.11.10 
 !
 object network obj-DMZ
 host 192.168.131.10
 nat (inside,DMZ) source static obj-Host interface destination static obj-DMZ obj-DMZ

For the Entire Subnet

object network obj-Host-LAN
 subnet 11.11.11.0 255.255.255.0
 !
 object network obj-DMZ-LAN
 host 192.168.131.10
 nat (inside,DMZ) source dynamic obj-Host-LAN interface destination static obj-DMZ obj-DMZ

[/box]

Now if we repeat the process, and ping the DMZ host.

Now when I capture the traffic, the source IP has changed accordingly.

Related Articles, References, Credits, or External Links

NA