In a typical DNS exchange a client sends a URL or hostname to a DNS server in order to determine the IP address of that host. The DNS server receives the request, looks up the name-to-IP-address mapping for that host, and then provides the A-record with the IP address to the client. While this procedure works well in many situations, problems can occur. These problems can occur when the client and the host that the client tries to reach are both on the same of different private network behind NAT, but the DNS server used by the client is on another public network.
Without DNS doctoring or another solution enabled in this situation, if the client sends a DNS request for the IP address of the Web Server it is unable to access the WWW server. This is because the client receives an A-record that contains the mapped public address of WWW server. When the client tries to access this IP address, the security appliance drops the packets because it does not allow packet redirection on the same interface.
There are many permutations of this issue and different options to solve it. Mainly, we can summarize the solution in following three methods
1) Using Alias command for DNS Doctoring or Destination NAT
2) Using Static with DNS Keyword for DNS Doctoring.
3) Using Hairpinning and DNAT instead of DNS Doctoring.
Based on the location of clients and web-server we can have the following situations.
- Clients and Web Server are both on DMZ while DNS Server is a public server on the Outside. (DMZ can be changed with inside as the emphasis is client and Web Server being behind the same interface)
- Web Server is on DMZ and Clients are on inside.
The tutorial will show all possible ways in which the problem can be solved based on the clients.
We’ll use the Test Server as client in both DMZ and use a router for DNS requests on the inside. We will be using the topology of InternetworkExpert[i] and though the Lab Workbook 1 has two excellent labs on the topic, we’ll go further and include all possible scenarios.
Topology:
We’ll use the test server as inside as well as on DMZ zone to simulate clients.
Scenario 1:
Using the Alias Command for DNS Doctoring and DNAT:
First, let’s describe the difference between the two.
DNS Doctoring performs two functions:
- Translates a public address (the routable or mapped address) in a DNS reply to a private address (the real address) when the DNS client is on a private interface.
- Translates a private address to a public address when the DNS client is on the public interface.
While DNAT or Destination NAT has the following functions
- In dnat, the ASA changes the destination IP of an application call from one IP address to another IP address.
- This process is used when you want the actual application call from the internal client to the server in a perimeter (dmz) network by its external IP address. This does not “doctor” the DNS replies.
So for Clients on the DMZ, we would use DNS Doctoring and for Clients on inside, we will use DNAT. Technically the configuration will be same, but its important to understand whats actually happening here.
Configuration and Explanation:
As First step, we will not configure the DNS Doctoring and simulate the issue. This will be our basic configuration on ASA.
ASA1:
Nat-control
nat (inside) 1 0 0
nat (dmz) 1 0 0
global (outside) 1 interface
static (dmz,outside) 136.1.122.100 10.0.0.100
static (inside,dmz) 136.1.121.0 136.1.121.0 netmask 255.255.255.0
access-list OUT_IN permit ip any any
access-group OUT_IN in interface outside
R2:
ip dns server
ip host WWW 136.1.122.100
Now we’ll make the Test Server in inside VLAN first and Then in DMZ and Try to reach the WWW server after DNS resolution from R2:
int fa 0/20
swit acc vlan 120
In IE topology, the Test server is connected with SW2F0/20
As you can see the DNS server is resolving the IP to 136.1.122.100 which the published IP.
The problem with this resolution is that ASA will drop the traffic.
R1:
ip domain lookup
ip name-server 136.1.122.2
Rack1R1#ping WWW
Translating “WWW”…domain server (136.1.122.2) [OK]
Translating “WWW”…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.100, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
Now we’ll use the DNS Doctoring and DNAT and test again. We’ll change the test server to inside zone and repeat the testing process.
alias (dmz) 10.0.0.100 136.1.122.100 255.255.255.255
alias (inside) 10.0.0.100 136.1.122.100 255.255.255.255
sysopt noproxyarp inside
sysopt noproxyarp dmz
Now on R1:
Rack1R1#ping WWW
Translating “WWW”…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
As we can see, now the server name is resolved to DMZ address 10.0.0.100, for clients on DMZ and inside Zone and there is no need for redirection on outside interface anymore. The ping is not allowed because on DMZ interface ICMP is dropped. But DNS resolution is what we want
Also on our client
Some Notes:
Other Configuration Notes
- The interface in the alias command needs to be the “interface” that the clients call from.
- You can have multiple alias commands tied to different interfaces on the same ASA
Scenario 2:
Using Static with DNS Keyword for DNS Doctoring:
Remove the previous Alias commands.
Now we’ll use the Static command with DNS keyword to solve the issue.
For clients on the DMZ we’ll need this command as we need DNS Doctoring. But remember we used alias for Destination NAT previously for clients on inside. In this case, with static command we will not need to do an anything for clients on the inside as dns keyword will take care of that. Because the DNS reply will be changed at the outside interface to 10.0.0.100, so both clients on inside and DMZ will be able to access the host using the private IP address.
Here is the configuration
clear configure alias
no static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255
static (dmz,outside) 136.1.122.100 10.0.0.100 dns netmask 255.255.255.255
Here is the verification.
Rack1R1#ping WWW
Translating “WWW”…domain server (136.1.122.2) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
Rack1R1#
And on the client
Scenario 3:
Using Hairpinning and DNAT instead of DNS Doctoring.
Remember the main raison deter of the alias command is that ASA doesn’t allow the packet redirection on same interface. What if we can change this behavior?
This wasn’t possible in earlier versions (and if you ask me, it shouldn’t be as it’s a serious security breach). But Cisco bowing to the demands of customers and in order to match checkpoint allows this feature now. This is called Hairpinning.
In our scenario, we’ll do hairpinning for the clients on DMZ and DNAT for the clients on the inside. Here is what Cisco’s website says about Hairpinning
“Hairpinning is the process by which traffic is sent back out the same interface on which it arrived. This feature was introduced in security appliance software version 7.0. For versions earlier than 7.2(1), it is required that at least one arm of the hairpinned traffic (inbound or outbound) be encrypted. From 7.2(1) and later, this requirement is no longer in place. Both the traffic inbound and the traffic outbound might be unencrypted when you use 7.2(1).
Hairpinning, in conjunction with a static NAT statement, can be used to achieve the same effect as DNS doctoring. This method does not change the contents of the DNS A-record that is returned from the DNS server to the client.”
For clients on inside, we’ll simply publish the public address of our WWW server by using static command.
Here is the configuration.
static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255
static (inside,dmz) 136.1.121.0 136.1.121.0 netmask 255.255.255.0
same-security-traffic permit intra-interface (Enables Hairpinning and redirection on interface)
global (dmz) 1 interface (nat-control is enabled. Traffic going to DMZ must be Natted)
static (dmz,dmz) 136.1.122.100 10.0.0.100
static (dmz,inside) 136.1.122.100 10.0.0.100
For Testing:
access-list DMZ_IN permit ip any any
access-group DMZ_IN in interface dmz
Here is the verification.
Rack1R1#telnet WWW 80
Translating “WWW”…domain server (136.1.122.2) [OK]
Trying WWW (136.1.122.100, 80)… Open
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Fri, 04 Sep 2009 18:43:11 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>The parameter is incorrect. </body></html>
[Connection to WWW closed by foreign host]
As you can see, even though the DNS resolves to 136.1.122.100, R1 is able to reach .
Similarly for hosts in DMZ
I hope this tutorial is useful of the non-existent reader base of this blog J
[i] Copyrighted topology-The writer of this blog has obtained permission from Mr.Brian and Mr.Peter to use the topology or diagram as reference.
IP Neworking, Security and a bit of fun 