05-03-2013 02:20 PM - edited 03-11-2019 06:38 PM
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?
Solved! Go to Solution.
05-03-2013 02:26 PM
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
network-object
network-object
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
05-03-2013 06:47 PM
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
05-03-2013 02:26 PM
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
network-object
network-object
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
05-03-2013 02:40 PM
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?
05-03-2013 02:47 PM
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
05-03-2013 02:29 PM
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
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
05-03-2013 02:34 PM
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
05-03-2013 02:36 PM
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
05-03-2013 02:49 PM
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.
05-03-2013 02:57 PM
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
05-03-2013 06:41 PM
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
First I set my NAT:
> static (inside,outside)
Then I open the port on
> access-list inbound permit tcp any host
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.
05-03-2013 06:47 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide