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 22.214.171.124 on the Outside interface of the ASA.
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 126.96.36.199)
Inside Client starts a connection to the IP address of 188.8.131.52, 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
%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)
•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 184.108.40.206 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
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):
•2- The DNS server will reply with the A-record(220.127.116.11)
•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
Object network Inside_HTTP_Public
Object network Inside_Subnet
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.)
If you receive a packet that comes from any inside user that needs to go to 18.104.22.168 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 22.214.171.124
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"
•- 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,
Based on Cisco My Device, my Cisco ASA Firewall 5525-X show that it end of support is 2020-08-31. Reference link below. Nevertheless, the link shows content related to ASA-CX. https://www.cisco.com/c/en/us/products/collateral/securit...
Does Cisco Stealthwatch Flowsensor support forwarding IPFIX flows to Third-Party flow analytics tool?If it is possible, then where can I get Stealthwatch IPFIX "Private Enterprise Element Definition" to decode flows on the recipient end.I was successful i...
Is it possible to match upon initial Authentication against an AD Group to then have a different Identity Source used? Generally I'm only aware of it being possible to match against an AD Group AFTER a User has authenticated via an Authorizatio...