• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1352
  • Last Modified:

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.
0
rkk-cwright
Asked:
rkk-cwright
  • 2
2 Solutions
 
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?

0
 
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.
0
 
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 ...

0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now