[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