how to access outside IP of static map from inside

I have a typical setup with an ASA5520 inside, outside and dmz.

I have a server in the dmz 192.168.90.4 255.255.255.0 which has dns enabled

My inside network is 192.168.200.0/24

I have a static map for an outside ip i'll call it 1.2.3.4 to 192.168.90.4

I have all my nat and access lists setup for basic access as per the cisco guides so I can.

1. do a dns request from the inside network to the dmz 192.168.90.4 address and get a response
2. do a dns request from the internet to the 1.2.3.4 address and get a response

What I can't do is do a dns request from the inside to the 1.2.3.4 address.  I see a lot of people talking about using dns rewrite to fix this, but that wouldn't work if you use the ip address like if you issue the command 'host www.google.com 1.2.3.4' from an inside linux computer.  we actually run both internal and external dns servers so I can function like this but I was just wondering if there was a way to make this work.  I thought I came across a document once that told how to do this with another nat command but I can't seem to find it again.
rkk-cwrightAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Nothing_ChangedCommented:
The ASA DNS rewrite function looks for DNS responses that return one of the static address translations that it is enabled for, and it replaces the outside NAT address that DNS returns with the inside (or DMZ) address as appropriate. In other words, if you nslookup or dig (from inside) myhost.com, and myhost.com in outside DNS shows as 1.2.3.4, the firewall would see the respomnse to a DNS query containing 1.2.3.4 as an answer and replace it with 192.168.90.4.

I'm assuming your 192.168.90.4 host and it's "1.2.3.4" NAT are a DNS resolver?

In general, the ASA won't send traffic in and out the same interface unless you make it do it. (with the PIX before this it just couldnt, period.) What you are trying to do esentially looks like making a request from inside, that would have to go through NAT translation to the outside, then loop back in the same interface to hit the NAT of the DMZ box. Which is the same as making a request  to the DMZ box native address, really. But, it may work if you try adding this command to your config:

same-security-traffic permit inter-interface

Let me know if that works?

rkk-cwrightAuthor Commented:
i already had that same-security-traffic statment

the server in question is a dns resolver but yeah this would affect any servers.  Yeah the path of hte packet would seem to be inside -> outside -> outside -> dmz.  

For some reason I thought there was a way to apply a nat statement to translate 1.2.3.4 to 192.168.90.4 on the inside interface, so that the packet would then go inside -> dmz just like it does when i address the server with it's local address.  I could've sworn I saw an example of this somewhere but I could just be dreaming it.
Nothing_ChangedCommented:
It would be possible to NAT it that way from the CLI... but it's not a best-practice way of setting up the NAT, and it will confuse the heck out of your ASDM if you use it, that web GUI HATES stuff that looks like it should be outside coming from the inside...

If you already have that same-security command exactly as I showed it above (that permit inter-interface is the critical part), then first check the firewall log, see what errors show up when you try to do your lookup that way. Maybe some spoofing thing? or a no translation group? I haven't tried this exact thing myself, but I suspect that due to the way the ASA does NAT, and how the process works with IP packets going from ingress traffic, to NAT, to ruleset, to egress traffic, then back in through the same process but on the outside interface, the firewall will see one of it's own IPs as a source attempting to connect to one of its other IPs, and classify it as a spoof attack and drop the traffic. Meaning there would effectively be no way around it ...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.