Best way to setup identity NAT on ASA 5512.x (CLI 9.1)

[PK IT]

I'm porting our configuration from a Pix 515 firewall to an ASA 5512x.  What's vexing me right now is with the deprication of the "static" command, I can't quite figure out the best way to Identity NAT my inside subnets (multiple) to the DMZ subnet

So on the pix I have my identiy NATs as an example:

static (inside,dmz) <IntSubA> <IntSubA> netmask 255.255.255.0

static (inside,dmz) <IntSubB> <IntSubB> netmask 255.255.255.0

static (inside,dmz) <IntSubC> <IntSubC> netmask 255.255.255.0

Cisco's migration guide seems to do them one object at a time, which I guess is straightforward enough to do:

object network SubA

     subnet <IntSubA> 255.255.255.0

object network IDNAT_SubA

     subnet <IntSubA> 255.255.255.0

     nat (inside,dmz) static SubA no-proxy-ARP route-enabled

I'm thinking that there must be an easier way (aka less lines) to implement this for all the subnets I want to Identity NAT to the DMZ.

1)  Can I do this creating objects using a subnet with a netmask of 255.255.0.0 - one object to cover multiple internal subnets?

2)  Can I do this using object groups and trim this down to:  (assuming I have to commands right)

Object-group network Inside_Subs

     network-object <IntSubA> 255.255.255.0

     network-object <intSubB> 255.255.255.0

     network-object <intsubC> 255.255.255.0

nat (inside,dmz) source static Inside_Subs Inside_Subs no-proxy-ARP route-enabled

What would be the best way to translate my Indentity NATs?

[varrao · Accepted solution]

Hi,

In ASA 8.3 or above, the codes have changed considerably, and yes the no. of lines of configuration have also increased. In your particular case, the second option is definitely a better one, since it saves mores lines and yes both the options do the same thing:

Object-group network Inside_Subs

     network-object 255.255.255.0

     network-object 255.255.255.0

     network-object 255.255.255.0

nat (inside,dmz) source static Inside_Subs Inside_Subs no-proxy-ARP route-enabled

You can definitely use object-groups in your nats, saving some config.

Thanks,
Varun Rao
Security Team,
Cisco TAC

[PK IT]

Thanks for the quick response Varun!  So just to confirm - I am using the right stand-alone (not tied to any object) nat command to implement my Identity NAT rule using an object group?

[Jouni Forss]

Hi,

If you want to configure Identity NAT then the described format should be ok

For example you have LAN interface with 3 networks and a DMZ with single network you could do either of these 2 Identity NAT configurations

object-group network LAN-NETWORKS

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

network-object 10.10.30.0 255.255.255.0

object-group network DMZ

network-object 10.10.40.0 255.255.255.0

nat (inside,dmz) source static LAN-NETWORKS LAN-NETWORKS

OR you could use

nat (inside,dmz) source static LAN-NETWORKS LAN-NETWORKS destination static DMZ DMZ

- Jouni

[Jouni Forss]

Hi,

Personally if you are talking about Identity NAT between your local interfaces protected by the ASA firewall, then I would recomend that you DONT configure ANY NAT at all.

The older software version used the "nat-control" global configuration command to determine if the ASA required a NAT configuration for connections going through its interfaces. This could either be configured with "nat-control" which required NAT configurations for connections going through the firewall OR you could configure "no nat-control" to enable the connections to go through wihtout NAT if no NAT was configured for the source/destination addresses.

Starting from the new software 8.3(1) and forward the ASA firewall doesnt know any concept of "nat-control" anymore. If a connection is coming through the firewall and no NAT configuration matches that connection then the ASA will simply the pass the connection as is without NAT. (This might naturally mean that the connection might still fail, but not because it didnt have any NAT configured)

So if we are talking about a situation where you have for example

• WAN interface
• LAN interface = 10.10.10.0/24
• DMZ interface = 10.10.20.0/24

If you wanted no NAT between the interfaces you simply DONT configure ANY NAT configurations between LAN and DMZ interfaces. Naturally you want to configure atleast Dynamic PAT between DMZ -> WAN and LAN -> WAN

So in the simplest of situations you would only configure Dynamic PAT for LAN and DMZ at the start and this could be done with few commands only

object-group network DEFAULT-PAT-SOURCE

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

nat (any,outside) after-auto source dynamic DEFAULT-PAT-SOURCE interface

Simple as that

Hope this helps

Please remember to mark correct replys as the answer to your question and rate all helpfull answers.

Also ask more if needed

- Jouni

[Jouni Forss]

Also,

If you want to check some basic NAT configurations in the new format and the NAT operation in general, you can check a document I made on these forums

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

To compare the old and new NAT configuration formats you can check out this document

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

- Jouni

[Jouni Forss]

And to further clarify,

The only reason to configure Identity NAT between your local interfaces even in the new NAT configuration format would be if you had some sort of Dynamic NAT/PAT between your local interfaces and wanted to override this behaviour for some hosts so that they would connect to the other networks/interfaces with their original IP address and vice versa.

- Jouni

[PK IT]

Thanks for the tips Jouni.  I may play around with them and see if they are unneccessary, we have several DMZ webservers that are managed by internal systems as well as accessed by both internal and external clients.  I am pretty sure we used Identity NAT to identify inside hosts to the DMZ systems so that their own access-privileges were fine tuned - if that makes sense.

I'll take your suggestions under consideration.

[Jouni Forss]

Hi,

I would suggest using the NAT configurations for only the translations of addresses and not controlling traffic between interfaces. If that is what you meant.

Ofcourse cant give an 100% sure answer without seeing the old format NAT configurations but as I said in the event that you dont require NAT to change the IP addresses between your local networks at all, then I would leave out the NAT between these interface completely to keep the configurations simple.

Please remember to rate answers and if a correct answer was given remember to mark all correct answers

Naturally ask more if needed.

Let us know what you end up doing or if you run into some problem.

- Jouni

[PK IT]

OK, I had a major problem but now I think I might have just answered it myself, but confirmation would be helpful.

So on the PIX 515e 6.3(3) firewall, allowing an outside connection into the network looked something like this:

Let's say I have a mail server with internal IP and need to allow HTTPS inbound from a NAT'ed public IP of for webmail.

First I set my NAT:

> static (inside,outside) netmask 255.255.255.0

Then I open the port on with ACL "inbound" applied to the outside interface

> access-list inbound permit tcp any host eq 443

I tried to mimic this on the ASA 5512 v9.1 to the best that the instructions above could provide me:

First, create my objects and set NAT

>  Object MAILEXT

>     host

> Object MAILINT

>     host

>     nat (inside,outside) static MAILEXT

Then my ACL:

> access-list inbound extended permit tcp any object MAILEXT eq https

So I was flabbergasted by the fact that not a single hit was racking up on the ACL.  Then I read this:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080bf150c.shtml

And realized - I used the wrong object on the ACL!  I was supposed to use MAILIN!

Is that right?  It's a different logical flow from the PIX ACL and NATs.

[Jouni Forss · Accepted solution]

Hi,

In software levels of 8.2 and older the order of operations is ACL first, then NAT

In software levels of 8.3 and newer the order of operations is NAT first, then ACL

This causes a change in the way ACLs need to be configured. In the newer softwares you always use the actual IP address of the host in ACLs that permit traffic through an interface.

Actually the above Static NAT that you use doesnt need the other "object" at all

You could just configure it with

object network MAILSERVER

host

nat (inside,outside) static

access-list OUTSIDE-IN permit tcp any object MAILSERVER eq https

access-group OUTSIDE-IN in interface outside

- Jouni