Static NAT refresh and best practice with inside and DMZ

[rgnelson]

I've been out of the firewall game for a while and now have been re-tasked with some configuration, both updating ASA's to 8.4 and making some new services avaiable. So I've dug into refreshing my knowledge of NAT operation and have a question based on best practice and would like a sanity check.

This is a very basic, I apologize in advance. I just need the cobwebs dusted off.

The scenario is this: If I have an SQL server on an inside network that a DMZ host needs access to, is it best to present the inside (SQL server in this example) IP via static to the DMZ or the DMZ (SQL client in this example) with static to the inside?

I think its to present the higher security resource into the lower security network. For example, when a service from the DMZ is made available to the outside/public, the real IP from the higher security interface is mapped to the lower.

So I would think the same would apply to the inside/DMZ, making 'static (inside,dmz)' the 'proper' method for the pre 8.3 and this for 8.3 and up:

object network insideSQLIP

host xx.xx.xx.xx

nat (inside,dmz) static yy.yy.yy.yy

Am I on the right track?

[a.matahen · Accepted solution]

Hello Rgnelson,

It is not related to the security level of the zone, instead, it is how should the behavior be, what I mean is, for

nat (inside,dmz) static yy.yy.yy.yy

- Any traffic hitting translated address yy.yy.yy.yy on the dmz zone should be re-directed to the host xx.xx.xx.xx on the inside interface.

- Traffic initiated from the real host xx.xx.xx.xx should be translated to yy.yy.yy.yy if the hosts accesses any resources on the DMZ Interface.

If you reverse it to (dmz,inside) the behavior will be reversed as well, so If you need to translate the address from the DMZ interface going to the inside interface you should use the (dmz,inside).

For your case I would say what is common, since the server is in the INSIDE zone, you should configure

object network insideSQLIP

host xx.xx.xx.xx

nat (inside,dmz) static yy.yy.yy.yy

At this time, users from the DMZ zone will be able to access the server using the yy.yy.yy.yy IP Address.

HTH

AMatahen

[Dan-Ciprian Cicioiu]

Nelson ,

You question is quite related to nat-control.

    1. Pre 8.3 versions :

if nat-control enabled :it requires to nat the hosts from higher security level if you want to communicate with lower security levels ( inside 100 -> dmz 50 or inside 100 -> outside 0 or dmz 50 -> outside 0 ) .

• Pre 7 version : you must do NAT , and you cannot disable this
• Post 7 version you could enable or disable nat-control, thus disabling this requirement

   2. Post 8.3 versions :

nat-control has been removed, so the traffic could be fowarded between any interface without this NAT requirement, and you cannot enable this feature. So you do not need NAT. But if the requirement is to do nat - like the case of LAN internet access - AMatahen , gave you an example.

Dan

[rgnelson]

Really not nat-control, as the question was about traffic from lower to higher security interfaces and best practice for the

direction of the required static. I realize the answer is partially about what is being accomplished, so thats why my example was using a database server and client, as a database server on the inside isn't going to initiate a connection to the DMZ. It would respond to queries only, making it a perfect DZM -> inside traffic pattern.

As I think about this now, it makes sense to translate the internal server IP to the DMZ, as then the acl to allow traffic across the NAT would be put assigned to the dmz interface and that is the closest point to the traffic origin (for this db server/client example).

[Dan-Ciprian Cicioiu]

Really not nat-control, as the question was about traffic from lower to higher security interfaces and best practice for the direction of the required static. 

As per 'best practice' I do not remember nothing related to NAT, if I think even better Cisco recommends the usage of the access-lists to permit/deny traffic flows, not the usage of the NAT.

Dan