nat-control and multiple DMZ's

[joshdloan]

I have a PIX with multiple interfaces. Obviously there is an Inside, which is 10.x.x.x and the Outside faces the Internet.  PAT is being done with a "nat (inside) 1 10.0.0.0" command and a "global 1 interface" on Outside.  There are also DMZ's on two other seperate physical interfaces that exist at DMZ1 (192.x.x.x) and DMZ2 (172.x.x.x).

The problem.

When communicating from Inside to DMZ1 I do not want any NAT'ing to take place, I want the "real" source IP to show up when accessing the hosts in the DMZ.  **However, there is still a need for the occasional static from Inside to DMZ1 with a "translated" address that is maybe something like "static (inside,dmz1) 192.168.1.101 10.1.1.101"

So I have nat-control off but from what I understand of the functionality is that if I specify a network with a NAT statement, in this case the "nat (inside) 10.0.0.0", I now cannot reach the DMZ without doing any NAT as this network is specified for it.  The other option would be to maybe stick a "no_nat" access-list in for any traffic going from 10.0.0.0 TO 192.168.1.0.  This would be fine, other than what I mentioned above about the occasional "translated static".

Assuming I am clear as to what I need above, is there any possible way for me to accomplish this?  (short of configuing a static and/or access-list for every host depending on which way I configure...)

Thanks in advance.  This one is hurting my brain for days now.

[Kureli Sankar]

Hurting your brian?

Well when you added nat/global for inside and outside you pretty much enabled nat-control for inside network. So, if the inside has to go to dmz or dmz1 then, you have to provide translation.

You can add nat 0 with acl like this below:

nat (inside) 0 access-list nat0

access-list nat0 deny ip 10.1.1.101 255.255.255.255 any

access-list nat0 permit ip 10.0.0.0 255.255.255.0 192.168.1.x

static (inside,dmz1) 192.168.1.101 10.1.1.101

The above will deny 10.1.1.101 host from the nat 0 and will fall to the static 1-1 confiured.

-KS

[joshdloan]

Ok yeah this is what I was expecting.  I was just hoping there was some special trick for "no nat-control" to exist on one interface(DMZ) while a NAT/Global was tied to a different one(Outside).

So if I do not NAT to the DMZ and all the Inside hosts keep their source while talking to hosts on the DMZ, I assume I will still need to put a Static(and appropriate ACL) in for any that need to talk from DMZ -> Inside, correct?

In a related situation; I have hundreds of hosts in the DMZ that almost all need access to the Internet.  This seems to require an access-list allowing the host(or subnet) with a permit to ANY since there is no possible way to define all the places on the Internet they need to hit, and their IP's.  By allowing lets say a host at 192.168.1.101 with an access-list to ANY(thus giving Internet access), how does this not become problematic when something on the Inside(a DB server) has a static NAT into the DMZ so that a specific web server can talk to it (i.e. host 192.168.1.200)?  Wont 192.168.1.101 now have full access to the translated DB server?  I miss conduits I think.

Example:

DMZ server - 192.168.1.101.  Needs access to the Internet and maybe one server(192.168.1.50) on the Inside.

static (inside, dmz) 192.168.1.50 10.1.1.50

access-list dmz_acl permit tcp host 192.168.1.101 host 192.168.1.50 eq 49  (for access to lets say a TACACS server Inside, via its NAT'd address)

access-list dmz_acl permit tcp host 192.168.1.101 any (access to any one of the millions of IP's that could be the Internet)

**** anything after this seems to be obsolete, including the first access-list **

It also seems like a problem for the Inside DB host at 10.1.1.200 that has a translation into the DMZ as 192.168.1.200 that ONLY needs host 192.168.1.77 to talk to it, via port 1433.  DMZ host 192.168.1.101 would have access to this server and any port that listening due to the any-ACL.

What am I missing here?

[Kureli Sankar]

If you need to deny some from going to DMZ or to be translated to some other address and not use their own source your best bet is

nat 0 acl

This is the the only acl that can take a deny line.

policy static - cannot take a deny line.

Now coming to your other question. You need to restrict further.

access-list  dmz_acl permit tcp host 192.168.1.101 host 192.168.1.50 eq 49  (for  access to lets say a TACACS server Inside, via its NAT'd address)

.

.

allow any other acl and restrict to certain ports then deny

access-list dmz_acl deny ip ho 192.168.1.101 host 192.168.1.50

access-list dmz_acl permit tcp host 192.168.1.101 any (access to any one of the millions of IP's that could be the Internet)

-KS

[joshdloan]

allow any other acl and restrict to certain ports then deny

access-list dmz_acl deny ip ho 192.168.1.101 host 192.168.1.50

access-list dmz_acl permit tcp host 192.168.1.101 any (access to any one of the millions of IP's that could be the Internet)

-KS

I'm sorry but this method seems as if I need to specify a "deny" to every host I don't want it to access in the DMZ(which is hundreds)?

Is the setup I have configured poorly-unique in some way?

Or how is the "typical" setup look when you have hosts in a DMZ that need to access lets say 15-20 other different DMZ hosts/"translated(Inside) hosts" but not the entire DMZ(s) yet they also need access to the Internet?

[Kureli Sankar]

Unfortunately that is what you need to do. If you can permit what you need to allow then in the deny line you can just add one line and include the network address of the source in the dmz and not individual hosts in the dmz.

-KS

[joshdloan]

Yeah good call.

Just to be sure, even with the NAT-control off I will still need to put statics in for anything needing to be access from the DMZ, correct?

As in a "static(inside,dmz) 10.1.1.101 10.1.1.101"

[cadet alain]

Hi,

Just to be sure, even with the NAT-control off I will still need to  put statics in for anything needing to be access from the DMZ, correct?

No ,static NAT is for outside to Inside or to  DMZ because private addresses are not routeable.

Regards.

Alain.

[Kureli Sankar]

Correct. On the ASA the min. you apply nat for a host on the inside  to outside, you are pretty much disabling no nat-control. Meaning you  have to provide translation for this host from the inside to any other  interface.  It could be static identity or nat 0 with acl (which is  bi-directional also). This is not the case with the FWSM, where the no  nat-control will still work between inside and dmz. Not to confuse you  further but, I thought I should let you know.

-KS