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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
