[c-nsp] PIX questions

Howard Jones howie at thingy.com
Tue May 13 17:23:45 EDT 2008


Ziv Leyes wrote:
> You must understand that the NAT is being performed on a "from-->to" basis, that is why the command is "static (inside,outside)" so if the NAT is between inside and outside you can't hit it when coming from the dmz, for this to be achieved you should use a "static (inside,dmz)" command, but then, you won't have the needed translation towards the outside, I think you can't enjoy both worlds... Besides, what's the problem having the outside hosts use the public IP address and the dmz hosts use the inside IP address for accessing the severs?
>   
I have almost exactly this problem today with the following history:
*  customer installs a wireless aggregation box in a DMZ for internet 
access. No problem.
*  next they install a web application in a different DMZ on the same 
ASA for access from the internet. No problem from the rest of the world.
*  now that this application is "on the internet", wireless users (who 
don't know how they are actually connected) complain that they can't 
access it by it's URL (which resolves to the public IP).

So it's not *that* hard to get into this situation.

Since it's only one IP, and I don't think there's going to be another, 
my current (untested) plan is to add another static NAT for the 
internet-facing address in DMZ 1 to DMZ 2. Split-horizon DNS would 
probably be a better solution, but I don't think they have the necessary 
control.

Am I right in thinking that the involved interfaces form part of the 
'key' for looking up NAT rules? I mean, can I use the same addresses in 
multiple rules between different interfaces?

Howie


More information about the cisco-nsp mailing list