DNS Doctoring – Access Internal WebSite using its public URL

In this post we will discuss DNS Doctoring on Cisco ASA firewalls. This is a useful feature and although it’s very simple to configure, not many people know about it.

DNS Doctoring is helpful in the following situation: Assume you have a Web Server connected to a DMZ zone on a Cisco ASA firewall and hosts the Website of your company. Suppose that the public URL of this Website is www.mywebsite.com which is used by external Internet users to access the website. However, when internal company users (located on the “inside” network of the ASA firewall) try to access this website using its public URL domain, the ASA blocks the connection.

Let’s discuss the scenario above in more detail and explain how DNS Doctoring can help internal users to access the DMZ website using its public URL domain.

Scenario without DNS Doctoring

The network diagram above shows a simple network protected by a Cisco ASA firewall, with 3 security zones (Inside Zone, DMZ Zone and Outside Zone).

The website www.mywebsite.com is hosted on a webserver connected to DMZ zone and has private IP address 10.1.1.10.

In order to expose this webserver to the public Internet, we must configure a static NAT entry on Cisco ASA which will map the private IP of the webserver (10.1.1.10) to a public IP address (50.1.1.10).

So we have: Static NAT on ASA maps 10.1.1.10 to 50.1.1.10

Therefore, the webserver (and hence the Website) is visible on the Internet as 50.1.1.10.

This means that the public DNS server (usually the DNS of your ISP) will have an entry for domain www.mywebsite.com pointing to its public IP 50.1.1.10

Accessing the website from Internal LAN

Now, what happens when a user connected to the Internal LAN tries to access the company’s website using its official domain name URL?

As shown on the diagram above, at Step 1 the client will perform a DNS Request to the public DNS server in order to resolve the IP address of domain www.mycompany.com.

At Step 2, the DNS Server will respond with the public IP of the website (50.1.1.10).

At Step 3, the client will send an HTTP GET request to IP 50.1.1.10 trying to access the website. However, the ASA will block this network connection because the client is connected to the Internal LAN and can only access the private IP of the webserver (10.1.1.10) and not the public (the ASA does not allow packet redirection on the same interface).

A possible solution to this would be to configure an internal DNS server and create a zone entry which will resolve the website URL to its private IP instead of its public IP. This is not an efficient solution though and requires to install and configure an internal DNS server.

A better solution is offered by DNS Doctoring on the ASA firewall.

Scenario with DNS Doctoring on ASA

With DNS Doctoring, the ASA firewall intercepts the DNS Response from the public DNS server and changes the IP address of the DNS response to be the “Real” (private) IP of the webserver instead of the public IP, and then forwards this to the client. Therefore, the client now trying to access www.mycompany.com will receive a DNS response of IP 10.1.1.10 and not 50.1.1.10 for the URL (which was the case without DNS Doctoring). The ASA performs the DNS Doctoring interception only if it has a static NAT translation entry in its NAT table.

The diagram below shows the behavior of DNS Doctoring on ASA.

At Step 1 the client will perform a DNS Request to the public DNS server for the website www.mycompany.com.

At Step 2, the DNS Server will respond with the public IP of the website (50.1.1.10). However, the ASA will inspect the DNS Response and check it’s NAT table to see if it has an entry for this specific IP address.  If it does, it will re-write the response with the “real” (private) IP address (10.1.1.10) before sending to the client.

At Step 3, the client will receive a DNS Response of 10.1.1.10 and therefore will send an HTTP GET request to IP 10.1.1.10 trying to access the website. This communication will work fine and the client will be able to access the DMZ webserver.

Configuration of DNS Doctoring on ASA

Let’s now see how to configure DNS Doctoring on Cisco ASA Firewall. Only the relevant configuration of static NAT, ACL, and DNS Doctoring specific to our scenario above is shown:

! ACL to allow access to webserver from Internet

access-list OUTSIDE extended permit tcp any host 10.1.1.10 eq www 
access-group OUTSIDE in interface outside

! Dynamic NAT (PAT) to allow access of Internal LAN to Internet

object network obj-192.168.1.0
network 192.168.1.0 255.255.255.0
nat (inside,outside) dynamic interface

! Static NAT to map webserver’s private IP to public IP

object network webserver
host 10.1.1.10  <–Private IP of webserver
nat (dmz,outside) static 50.1.1.10 dns  <–the “dns” keyword enables DNS Doctoring on this NAT entry

! The following DNS inspection configuration is usually enabled by default

policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512

policy-map global_policy
class inspection_default
inspect dns preset_dns_map

Basically, the whole DNS Doctoring functionality is enabled with just a single keyword. The keyword “dns” on the Static NAT entry (which maps the private IP of the webserver to its public IP) enables DNS Doctoring on the specific NAT entry.