ASA version 8.3 NAT - A new configuration style with new possibilities

Blog

Sep 21, 2010 6:41 AM
Sep 21st, 2010

As many ASA administrators are discovering, the Network Address Translation (NAT) configuration style starting with ASA version 8.3 is different from the pre-8.3 style. Admins that have configured NAT on the ASA and PIX platforms for many years will need to become familiar with the new NAT configuration style that the ASA will be using going forward. We've created some guides within the Cisco Support Community to help people get acquainted with the new configurations, and I hope people find them useful, comment on them, and suggest more documents they want to see created.

The motivation for changing the NAT configuration style is in-line with a more fundamental shift of the ASA configuration scheme; a shift to a more object-oriented configuration. And note, I'm not talking about "object-groups" here, but the new "object network" type that can be used to define a host or subnet in the network, and then can act as a container for the NAT configuration to be applied to that host or object. For example, with ASA 8.3, one can define a network object for a new server being brought up in the network behind the ASA's DMZ interface, and in one nat configuration line define how that server will be translated to every interface of the ASA, like this:


ASA(config)# object network smtp_server

ASA(config-network-object)# host 192.168.33.2

ASA(config-network-object)# nat (dmz,any) static 209.165.201.2

Accomplishing the above task in version 8.2 would have meant creating a new static translation for each interface of the ASA, instead of just one line like above. Another new capability that has been added in ASA version 8.3 is one-to-many NAT translations are now possible. So, a server on the DMZ interface could be translated to two different mapped IPs on the same mapped interface (the outside interface). Note that in this example we're using manual nat and not object nat, like above:

!

object network web_server
  host 192.168.99.23
object network mappedIP-1
  host 209.165.201.32
object network mappedIP-2
  host 209.165.201.42
!
nat (dmz,outside) source static web_server mappedIP-1
nat (dmz,outside) source static web_server mappedIP-2

!

With this configuration, users on the outside could send packets destined to 209.165.201.32 -or- 209.165.201.42, and those packets would be forwarded to the dmz interface, with the destination changed to 192.168.99.23. This capability is one that our customers have been wanting for some time, and now the ASA can accomplish it.

For more information on version 8.3, and specifically the new NAT configuration style, please see the links below:

Average Rating: 0 (0 ratings)

Comments

manisharora111 Thu, 10/14/2010 - 13:04

Thank you Jay for the post , I have done something similar using policy nat on asa Pre-8.3 version and this is nice to the functionality on 8.3 version onwards.

I do have question about it though :-

1> taking the above example, will the server send reply back to the client using the same external IP address on which the request was recieved  ? or it will use the dynamic PAT ip or first IP in the list of static  NAT  Public IPs ?

Jay Johnston Fri, 10/15/2010 - 06:25 (reply to manisharora111)

The ASA will use the same IP that the inbound packet was destined to.

When the client on the outside sends the initial SYN packet through the ASA, the ASA builds a connection entry for that specific TCP connection; that TCP connection is tied to the translation the ASA performs on the traffic. This means that when the inside server sends the SYN/ACK packet back towards the client, the ASA will recognize that this packet matches the connection that already exists on the firewall, associate that connection with the translation, and change the source IP appropriately so that it makes sense to the remote client which initiated the connection.

manisharora111 Fri, 03/25/2011 - 17:57 (reply to Jay Johnston)

Hi Jay,

Can you please answer one more question about this setup ?

If I am using SLA tracking with two different ISP's terminating on the same Firewall  and I map twp public ip's to a same internal server with each IP from different ISP , Now when the server is initiating a UDP/TCP connection from inside to outside , what ip is it going to use ? I have to use it somewhere and donot have a spare ASA with 8.3 to test this senario.

Thank you

Manish

Jay Johnston Sat, 03/26/2011 - 10:31 (reply to manisharora111)

In most cases, for new connections initiated from the inside server to the internet, the ASA will use the global routing table on the firewall ('show route') to determine the egress interface. Then, once the egress interface is determined, the ASA looks at the NAT table ('show nat detail') to see what NAT translations apply to this traffic, and apply the translation accordingly.

Since SLA is being used to modify the routes in the global routing table, the egress interface might change depending on the availability of the tracked target IP. So, use 'show route' to determine what interface outbound connections might use at any given time.

Does that answer your questions?

jdsuhr Tue, 10/26/2010 - 11:46

Nice. I'd love to see more reasons to like 8.3 (to balance the many headaches it's caused).

simonosullivan Mon, 11/22/2010 - 20:12 (reply to jdsuhr)

Something I have found a bit confusing with the new system is the term "network object" eg:

Say I have several servers behind 1 public IP address and several publically accessable services running on the different servers (eg http, https, ftp, smtp, pop3). Under the pre (8.3) verisons I could just make as many "Static PATs" as I liked throught to whatever server. All good.

Now if I have one server that runs two public services I have to create two "network objects" for that server. e.g:

object network EmailServer-smtp

     nat (Inside,Outside) static X.X.X.X service tcp 25 25

object network EmailServer-pop3

     nat (Inside,Outside) static X.X.X.X service tcp 110 110

It would be nice if I could do this for example:

object network EmailServer

     nat (Inside,Outside) static X.X.X.X service tcp 25 25

     nat (Inside,Outside) static X.X.X.X service tcp 110 110

Jay Johnston Mon, 11/29/2010 - 07:05 (reply to simonosullivan)

Agreed, this functionality would be nice, and help to clean up the NAT configuration in your use case. This is something that is currently under discussion for potentially including in a future release.

We have filed an enhancement to track the request for this feature:

CSCte96293 - ENH: Objects should support multiple nat/service commands

You can track the progress of this enhancement via the online bug toolkit here:

http://www.cisco.com/go/bugs/

cciesec2011 Fri, 12/10/2010 - 07:41 (reply to Jay Johnston)

Checkpoint has been able to do this for the past ten years.  I am glad Cisco has finally recognized this and it finally happens in 2010.

Another observastion, as a CCIE Security and someone who has been using Cisco Pix and Centri Firewalls back in 1997 until now for the past ten years.  I also used the 16MB ISA Card to insert it into a Intel motherboard Seattle Edition SE-2 to turn a regular PC into a Pix 520 (code name Firebird).  It seems like Cisco has truly lacks the management capabilities to manage the Pix and later on the ASA.  I've tried Cisco CSM as back as 2005 and even with the latest development in CSM, it still lacks the capabilities to manage the ASA effectively, especially in the logging capabilities.  It is extremely painful to me, as someone who like Cisco products, have to tell customers that Checkpoint Firewall is a must superior product than Cisco ASAs.  Configuration on the ASAs is very error-prone and lack troubleshooting capabilities on the firewall itself.

I've worked with both Checkpoint and Cisco firewalls for the past ten years and while I am excited that the ASA is getting lot of improvements, it is still years behind Checkpoint in term of capabilities and especially management capabilities.

perhaps, Cisco should hire more Checkpoint engineers in order to improve the ASA product lines.

zahir_ahmed Fri, 03/11/2011 - 03:31 (reply to cciesec2011)

I completely agree, in fact if i can remember right! even checkpoint ver 4.1 allowed to create objects and then configure the NAT for that object. Surprisingly, Checkpoint also called it auto NAT and the rules appreaed in Smart Dashboard under auto rules that can only be modified within the object.

i also see that in the GUI we now see a similar packet breakdown for NAT ie, original packet & translated packet! terms that Checkpoint has been using for years.Its time to catch up Cisco!!

Actions

Login or Register to take actions

This Blog

Posted September 21, 2010 at 6:41 AM
Stats:
Comments:12 Avg. Rating:0
Views:12247   
Shares:0

Related Content

Blogs Leaderboard