I intended to publish this sooner but got wrapped up in life; new job, exams to study for and so on. Even though this is quite a few months late now that ASA 8.4 is out the door now it still a pretty solid summary on now the new NAT system works.
Much to the dismay of many the release of the ASA 8.3+ code base brought
radical changes in the way NAT was done on the ASA. I was initially
apprehensive about the change and cursed Cisco for such implementing such
drastic and confusing changes. However, not all change is bad; after spending a
few weeks of working with it and figuring it out I grew to love the new system.
Withstanding a few minor annoyances, I found it to be a much more flexible and
concise compared to the old way.
The first big change is that NAT has been redesigned around
using objects. The second is that NAT was split into two forms: Object NAT and
Twice NAT. In the first form, Object NAT, the translation becomes a property of
an object. The second form, Twice NAT, has the ability to modify both the
source and destination addresses of a packet with a single rule. Since we can
do conditional translations with Twice NAT the old method of policy NAT with
access-lists has been replaced with this new method.
One of the most important concepts to understand with the
new system is how all the translation rules are ordered and processed by the firewall.
Any NAT commands entered are categorized
and placed into one of three sections. The rules in each section as well as the
sections themselves are then processed sequentially from top to bottom.
The first section is “Before Object NAT”. In this section
rules are added with Twice NAT statements and can be manually ordered. It’s
also important to note that remote access VPN clients will append entries to
the end of this section so its important to be mindful of adding any rules that
could overlap with your VPN client address ranges.
The second section is “Object NAT”. This section is where
any rules that are properties of an object will appear. All the entries in this
section are automatically ordered based on a few simple guidelines. First, static
NATs will be placed before dynamic NATs. The next thing checked is the quantity
of IPs being translated. A NAT with a large range of IPs will be processed
before a NAT using a single IP. Finally, if multiple entries with the same
number of IPs exist they will be sorted from lowest IP to highest IP. One of
the big annoyances I have found with Object NAT is that only a single translation
can be applied to any one object. In the case of multiple PATs on a single address
the use of multiple objects with the same address is required; one object for
each PAT rule.
The third section is “After Object NAT”. Functionally this
section is identical to the first with the exception of being processed after
the “Object NAT” rules. Rules are placed in this section through the use of a special
flag in a Twice NAT statement.
The next big departure from the old method is how we write
access-lists for our translated resources. In older versions of the code, when you
wanted to allow incoming traffic to a public facing server you had to write an
access-list that permitted traffic destined to your public facing IP address. In
the post 8.3 world you now have to specify the IP or object of the internal host in your access-list instead of the public facing IP. Cisco calls this function
Real IP.