Section 1 DNS-Doctoring
Let’s start by defining what DNS Doctoring is:
This is the capability that an ASA offer us in order to translate the DNS A-record for a particular DNS query.
So for example if User A wants to go to www.jcarvaja.com he will send a DNS query in order to get the A-Record for that site (The record that will point the user PC to initiate an HTTP request to the IP address of that site).
The ASA will work with that DNS conversation as with any other packet flowing across the firewall (make sure the policy allows the traffic, if there is an inspection that the traffic does not violate any specific standard, etc.)
But what happens if we have the following Scenario:
Let’s say that the HTTP server gets translated to the IP address of 80.80.80.80 on the Outside interface of the ASA.
Object network Inside_HTTP_Server
Host 192.18.12.2
Object network Inside_HTTP_Public
Host 80.80.80.80
Nat (inside,outside) source static Inside_HTTP_Server Inside_HTTP_Public
What happens if the inside users want to reach the HTTP server on the Inside via the Public IP address?
Traffic flow will be like this (Outside DNS server being used)
- Inside PC sends a DNS query for www.jcarvaja.com
- ASA forwards the packet to the DNS server on the outside Interface, which replies with the A-record for the site.
- ASA forwards the Reply to the Inside client (A-record is 80.80.80.80)
- Inside Client starts a connection to the IP address of 80.80.80.80, The ASA receives it and knows that it has a NAT statement for that IP address that most go out the same interface where it receives the request so the packet will get denied (a packet cannot flow from inside to outside to inside.
We will see the following logs on the ASA when the issue happens:
%ASA-6-302013: Built outbound TCP connection 54175 for
outside:172.20.1.10/80 (172.20.1.10/80) to inside:192.168.100.2/11001
(172.20.1.2/1024)
%ASA-6-302014: Teardown TCP connection 54175 for outside:172.20.1.10/80 to
inside:192.168.100.2/11001 duration 0:00:30 bytes 0 SYN Timeout
This is where DNS comes to play,
Just by adding the DNS keyword at the end of the NAT statement the ASA will eavesdrop into the DNS packets looking for a NAT matching statement with the DNS keyword and translate the A-record to the respective IP address on the NAT statement.
Nat (inside,outside) source static Inside_HTTP_Server Inside_HTTP_Public dns
Traffic flow will be like this (Outside DNS server being used)
•1) Inside PC sends a DNS query for www.jcarvaja.com
•2) ASA forwards the packet to the DNS server on the outside Interface, which replies with the A-record for the site.
•3) The ASA receives the A-record, immediately checks the NAT rules and see a match with the DNS keyword so it will change the A-record from 80.80.80.80 to the Private IP address of the server 192.168.12.2.
•4) The Inside PC will then initiate a connection to the internal HTTP server address and the connection will successfully will be built.
Cool stuff right but what are the requirements to run this feature:
- The DNS Queries and Replies must go through the ASA (In order for it to translate them as required).
- DNS inspection must be turned on.
Section 2 U-turning
What is U-turn or Hair-pinning?
It’s the capability that will allow an ASA to route traffic back the same interface where receive it.
Note: We do not necesarilly need to use a DNS server for this feature to work , if we have our application configured to use the Public IP address to connect to the server, the DNS server will be out of the picture, so the only case were we will need it is if we are trying to connect via the Domain-Name
Example:
We are using an internal DNS server so DNS inspection is out of the picture,
Traffic flow (A-record pointing to the private IP address):
•1- The Client sends a DNS query for www.jcarvaja.com
•2- The DNS server will reply with the A-record (192.168.12.3)
•3- The Client will then connect to the Private IP address of the Server; the ASA will not receive any of this traffic as it’s being delivered on the LAN.
Traffic flow (A-record pointing to the public IP address of the server)
•1- The Client sends a DNS query for www.jcarvaja.com
•2- The DNS server will reply with the A-record(80.80.80.80)
•3- The Client will send the traffic to its default gateway, the ASA in this case as the destination it’s not on the same subnet than him.
•4- The ASA receives the traffic and checks that it has a NAT translation for that traffic that points to an internal user.
“Traffic flow from inside to outside back to inside will be denied by the ASA”
But our customer wants to connect to the server using the NAT or public IP address how can we accomplish that?
That’s the whole idea of the U-turn.
Now the configuration:
Object network Inside_HTTP_Server
Host 192.168.12.2
Object network Inside_HTTP_Public
Host 80.80.80.80
Object network Inside_Subnet
Subnet 192.168.12.0
Same-security-traffic permit intra-interface
This command will allow the traffic to go to the ASA interface and then do a U-turn (So basically it says allow traffic that reaches X interface and needs to go out that same interface, some sort of disabling the Split-Horizon rule.)
By default this traffic gets denied.
Nat (inside,inside) source dynamic Inside_Subnet interface destination static Inside_HTTP_Public Inside_HTTP-Server
This NAT command basically tells the ASA:
If you receive a packet that comes from any inside user that needs to go to 80.80.80.80 translate the source (Inside user) to the ASA inside interface IP address and the destination (HTTP server) to 192.168.12.2
As simple as that we will be now allowing traffic to go out the same interface and we are performing the right NAT translation to let the user connect to the public IP address of that Server.
So we are basically playing with both Source and Destination.
The traffic flow with the above configuration would be like this:
1- The client will send a DNS query for the site www.jcarvaja.com, It will get the A-record from the DNS server pointing to 80.80.80.80
2- It will then generate a connection to that IP via the ASA, as the ASA is the default-gateway of the LAN.
3- The ASA will receive the packet and the connection will match a Nat rule (The Twice NAT rule that involves both Source and Destination).
4- The Source and Destination IP address on the header will be modified and the connection will be allowed to go out the same interface where it came.
5-Traffic will flow back and forward via the ASA.
"Using this method the connection will get established"
Conditions:
•- Traffic must reach the ASA so we can perform the translations there.
•- If there is an ACL already applied to that interface make sure we allow traffic to that Public IP address.
That basically covers both features (DNS-Doctoring and U-turn) on the ASA,
I hope this helps you,
Regards,
Julio Carvajal
