Web Development

Cisco ASA and DNS pain: Is there a doctor in the house?

Cisco expert Lori Hyde reveals how DNS doctoring allows you to provide user access to internal resources when the default ASA configuration results in dropped packets.
Scenario: You have a small office or a remote site that does not have an internal domain name server to provide Domain Name System (DNS) resolution. Rather, they are using an external DNS server provided by an Internet Service Provider. The corporate Web site is statically translated via NAT from a private IP address to a publicly reachable IP address on a Cisco ASA firewall. Requirement: The internal users need to access the corporate Web site, which is located on an internal server.

Default ASA configuration result: The internal users cannot reach their corporate site and the packets are dropped by the ASA.

The root of the issue lies in how the ASA handles DNS resolution.

In this scenario, the internal user attempts to access the corporate Web site. In the process, a DNS query is made for the IP address of the corporate site. This request packet travels through the Cisco ASA, which then rewrites the source address of the packet to its own IP address and forwards the request to the external ISP DNS server.

The DNS server responds to the ASA query with the public IP address for the corporate Web site. The ASA receives the response, then rewrites the destination address with the user's system IP, and forwards the packet to the user system.

The user's system then attempts to open a HTTP session with the corporate Web site.

Since the IP address of the site has resolved to the public IP, the user's request packet travels from the inside interface of the ASA, where the ASA builds a connection outbound, to the outside interface. The packet is then dropped by the ASA as it does not allow the packet to return to the inside interface. See Figure A.

Figure A

Click to enlarge.

This interface transversal is known as hair-pinning. By default, the ASA does not permit hair-pinning. While there is more than one way to resolve this problem, in this case, the easiest solution involves the use of DNS doctoring.

By changing one option of the static NAT translation statement, we can tell the ASA to resolve the internal DNS lookup query to the internal WWW server IP address instead of the public IP address.

The original ASA static NAT translation statement was:

static (inside,outside) 172.16.20.200 10.10.10.10 netmask 255.255.255.255

The revised static NAT translation statement with the DNS doctoring option enabled:

static (inside,outside) 172.16.20.200 10.10.10.10 netmask 255.255.255.255 dns

Revised DNS process

A DNS query is made for the IP address of the corporate Web site. This request packet travels through the Cisco ASA, which then rewrites the source address of the packet to its own IP address and forwards the request to the external ISP DNS server.

The DNS server responds to the ASA query with the public IP address for the corporate Web site. The ASA receives the response, and then rewrites both the destination address with the user's system IP, and the DNS query result to the internal WWW server IP address, before forwarding the packet to the user system. See Figure B.

Figure B

Click to enlarge.

Making this change is easy to do via the Cisco ASA ASDM interface.

Go to Configuration | Firewall | NAT Rules. Then highlight the static NAT statement and select Edit. Under the Connection Settings heading, select the option for Translate The DNS Replies That Match The Translation Rule. See Figure C.

Figure C

Click to enlarge.

Be sure to save your changes!

This should resolve the issue in a quick, clean, solution. As in most cases though, there is more than one possible solution. We can explore the configuration to allow full hair-pinning in another segment.

What issues have you encountered with your ASA?

Want to learn more about router and switch management? Automatically sign up for our free Cisco Technology newsletter, delivered each Friday!

8 comments
ehabheikal
ehabheikal

This is important when you use ASA primarily as a firewall for your servers. If you are into hosting and you are hosting multiple mail servers behind an ASA with nat, the mail servers will not be able to send email to each other. I had this problem and thanks to this page I was able to solve it. If there is another way to get the internal network to be able to recognize each other via external ips please tell me.

nigel
nigel

Neat solution, but in real world much better to put the web server in DMZ - then both inside and outside can reach it on public IP, so public DNS OK and much improves security. static (inside,outside) is considered a security no no as if the web server gets compromised your LAN is wide open All ASA include at least one DMZ interface as standard

amanr
amanr

Why not just use the netbios name to reach the internal web server like http://servername/ - this solution seems like overkill.

ctech1
ctech1

This is a great article, I really learned a lot form it. I myself would of used a hosts file for the name resolution, I am assuming a hosts file is being used for communication between the computers. Shouldn't the webserver be on its own subnet?

Photogenic Memory
Photogenic Memory

I'm not well versed in Cisco products but I liked the article and I'm sure to to be working with this newer styled Cisco device in the future. From the article I wasn't able to grasp if this was for a single DNS query from the host that was allowed to be accepted by the router or was it a total global change in the configuration?

delphi9_1971
delphi9_1971

I'm not following how this is overkill? What if your DNS server is BIND on Linux? You can't use NetBIOS. Or the other comment about the hosts file? Really? You'd rather create a host file and distribute it to your 10/100/1000/10,000 workstations rather than make one single check mark on a Static NAT Translation? I find that odd. I think what you're missing here is that this is for when you have workstations that use External ISP provided DNS. Like in a SOHO environment or have managed computers that have DNS settings that differ from your internal server. (E.G. Vendors, Clients, Students in an educational environment, employees that bring their own gear to the office.) In these situations it is just easier to enable DNS doctoring rather than implement any of those other changes you suggest.

gjohnson
gjohnson

Corp already has a www server, why not just add dns to it for the internal clients? All OS support DNS hosting now. It eliminates internet traffic by caching frequent dns lookups, prevents DNS poisining from efecting users and almost no maintenance or cost. Who's going to remember to keep the ASA up to date when the www server is replaced and gets a new IP or someone decides corp needs a second web server? This might be a good idea but to me it looks like taking a simple problem and solving it with a complex solution. Just my opinion.

amanr
amanr

I think you miss the point completely here. These 2 machines are on the SAME LAN. There is no need to 'leave' the network and use an external DNS request to resolve a local machine name. A simple broadcast request will help the machines find one another. The ASA could even run DNS for the local lan.

Editor's Picks