Networks Training

  • About
  • My Books
  • SUGGESTED TRAINING
  • HOME
  • Cisco Networking
    • Cisco General
    • Cisco IOS
    • Cisco VPN
    • Cisco Wireless
  • Cisco ASA
    • Cisco ASA General
    • Cisco ASA Firewall Configuration
  • Certifications Training
    • CCNA Training
    • Cisco Certifications
    • I.T Training
  • General
    • General Networking
    • IP Telephony
    • Network Security
    • Product Reviews
    • Software
  • Cisco Routers
  • Cisco Switches
You are here: Home / Cisco ASA General / DNS Doctoring – Access Internal WebSite using its public URL

DNS Doctoring – Access Internal WebSite using its public URL

Written By Harris Andrea

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

cisco asa 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.

MORE READING:  Password Recovery for the Cisco ASA 5500 Firewall (5505,5510,5520 etc)

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.

cisco asa dns doctoring configuration

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.

MORE READING:  Cisco ASA 5505 Network Port Interfaces

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.

Related Posts

  • What is Cisco ASA Firewall – All you need to Know
  • Traffic Rate and Bandwidth Limiting on Cisco ASA Firewall
  • Cisco ASA Firewall (5500 and 5500-X) Security Levels Explained
  • Cisco ASA 5505-5510-5520-5540-5550-5580 Performance Throughput and Specs
  • Password Recovery for the Cisco ASA 5500 Firewall (5505,5510,5520 etc)

Filed Under: Cisco ASA General

Download Free Cisco Commands Cheat Sheets

Enter your Email below to Download our Free Cisco Commands Cheat Sheets for Routers, Switches and ASA Firewalls.

We use Elastic Email as our marketing automation service. By submitting this form, you agree that the information you provide will be transferred to Elastic Email for processing in accordance with their Terms of Use and Privacy Policy. Also, you allow me to send you informational and marketing emails from time-to-time.

About Harris Andrea

Harris Andrea is an Engineer with more than two decades of professional experience in the fields of TCP/IP Networks, Information Security and I.T. Over the years he has acquired several professional certifications such as CCNA, CCNP, CEH, ECSA etc.

He is a self-published author of two books ("Cisco ASA Firewall Fundamentals" and "Cisco VPN Configuration Guide") which are available at Amazon and on this website as well.

Comments

  1. Livaniel Gonzalez #6957949 says

    April 24, 2017 at 12:20 pm

    Thank you very much for this information, this can be configured in version 8.2 as would be the commands

    Thank you

  2. Harris Andrea says

    April 24, 2017 at 1:16 pm

    Yes DNS Doctoring is supported on 8.2 as well. However the NAT commands are different. You should still use the “dns” keyword on the “static” command which is used in 8.2 for creating static NAT entry.

    Harris

  3. Fabian Joseph says

    April 24, 2017 at 2:28 pm

    You said: “A possible solution to this would be to configure an internal DNS server and create a zone entry which will resolve the website URL…This is not an efficient solution though…”

    Why is this not an efficient solution? What if, as would normally obtain, an internal DNS already exist?

  4. Harris Andrea says

    April 24, 2017 at 3:25 pm

    Fabian,

    With the internal DNS, you will have to create a DNS Zone pointing to the private DMZ IP address. Also, you will have to manage the public DNS Zone on the public DNS. This means extra admin overhead anytime you have to change/add/delete anything on the DNS zones. I don’t say that this is so bad, but for people who don’t have an internal DNS then DNS Doctoring might be an easier solution.

    Harris

  5. Vasil Javeed says

    April 25, 2017 at 6:43 am

    Many thanks Haris, day to day tasks, Internal users always asks such requests.
    valuable info.

  6. Harris Andrea says

    April 25, 2017 at 10:32 am

    I’m glad you’ve found it helpful.

  7. Michael Palmiero says

    April 26, 2017 at 7:54 pm

    Great feature to share. Thank you. Another use for this feature would be to force users’ search engine queries to the “safe search” server addresses now being provided by Google, Bing and Youtube.

  8. Harris Andrea says

    April 27, 2017 at 4:40 am

    Michael, thanks for your feedback and tip.

    Harris

  9. Ray says

    July 17, 2017 at 12:20 pm

    Thanks for great info. I have a question, what would your ACL look like if you wanted to publish or allow both www(80) and https(443) traffic or access to your internal server?

  10. Harris Andrea says

    July 17, 2017 at 2:01 pm

    The ACL for both ports 80 and 443 would be as shown below:

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

  11. Carlos says

    February 13, 2018 at 3:48 pm

    Hi, what is the difference between DNS Doctoring and NAT Reflection because you can do that using NAT LOOPBACK or Nat reflection,

    Thanks

  12. Harris Andrea says

    February 13, 2018 at 5:55 pm

    DNS doctoring is much less complicated (no need to configure nat rules etc)

  13. FREAK says

    April 28, 2018 at 7:00 pm

    THANKS MAN 100 OUT OF 10

  14. Gomummy Hosting says

    February 19, 2020 at 7:22 am

    Good article which I came across since long time back. Nice explanation with images.

  15. Mit Patel says

    October 6, 2020 at 2:14 pm

    Thank you for such a great article. I have a query though.

    Why is the access to the public IP of Web Server (50.1.1.10) from the internal user (the INSIDE zone) not actually working? If it’s about the fact that there is not specific ACE configured that allows this acces and hence it’s getting denied implicitly, is not this something that we can explicitly allow? “Allow access to 50.1.1.10 from inside zone”. Am I missing out on something?? It would be great if you can shed some light. Thanks in advance!!

  16. Harris Andrea says

    October 6, 2020 at 4:06 pm

    The public IP of the webserver (50.1.1.10) is known only to the outside world because of the static NAT (between DMZ and OUTSIDE).

    The internal users know this webserver with its real private IP address.

    Hope this helps.

    Harris

  17. Mit Patel says

    October 8, 2020 at 4:04 am

    Absolutely, Harris. Thank you!!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search this site

About Networks Training

We Provide Technical Tutorials and Configuration Examples about TCP/IP Networks with focus on Cisco Products and Technologies. This blog entails my own thoughts and ideas, which may not represent the thoughts of Cisco Systems Inc. This blog is NOT affiliated or endorsed by Cisco Systems Inc. All product names, logos and artwork are copyrights/trademarks of their respective owners.

Amazon Disclosure

As an Amazon Associate I earn from qualifying purchases.
Amazon and the Amazon logo are trademarks of Amazon.com, Inc. or its affiliates.

Search

BLOGROLL

Tech21Century
Firewall.cx

Copyright © 2023 | Privacy Policy | Terms and Conditions | Hire Me | Contact | Amazon Disclaimer | Delivery Policy

0 shares