RE: [OT] - ASA 8.3+ Twice NAT w/DNS doctoring vs ASA 8.2 Policy

From: Joseph L. Brunner <joe_at_affirmedsystems.com>
Date: Thu, 10 May 2012 15:38:01 +0000

Can anyone think of way to get around this limitation?

A local dns server at the original site? With different dns records?

I have never used the dns stuff on the asa - too risky..

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Ryan West
Sent: Thursday, May 10, 2012 10:21 AM
To: CCIE Lab (ccielab_at_groupstudy.com)
Subject: [OT] - ASA 8.3+ Twice NAT w/DNS doctoring vs ASA 8.2 Policy

I have a working scenario in 8.2 that I'm trying to verify into the 8.3+ realm. Why did they change NAT again... if it was to beautify ASDM, why not
change the way ASDM displays the NAT. Anyhow, back to the original issue.

Customer A has been acquired and is now being split into different BU's.
Their previous RFC1918 space is not permitted in the new environment and they will need to renumber. However, their production environment would require a huge overhaul, so we're stuck trying to support access to those devices through name resolution using their new permitted internal space and managing multiple DNS shifted copies of the domain is not a scalable option. So my initial thought was a DNS rewrite and attaching that to a policy NAT, while configuring a conditional forwarder. This works and is deterministic.

Original range: 192.168.10.0/24
New Allocated range: 10.130.10.0/24

User1.domain1.com -> 192.168.10.50 needs to translate to 10.130.10.50 for both site to site traffic and name resolution

Access-list policy-nat-domain1 permit ip 192.168.10.0 255.255.255.0
10.130.130.0 255.255.255.0
static (inside,outside) 10.130.10.0 access-list policy-nat-domain1 dns

I query remotely, pick up the new range, and traverse the tunnel. Now onto 8.4. From the 8.4 configuration guide:

DNS-(Optional; for a source-only rule) The dns keyword translates DNS replies.
Be sure DNS inspection is enabled (it is enabled by default). You cannot configure the dns keyword if you configure a destination address. See the "DNS and NAT" section for more information. [1]

nat (inside,outside) source static obj-192.168.10.0 obj-10.130.10.0 ?

configure mode commands/options:
  description Specify NAT rule description
  destination Destination NAT parameters
  dns Use the created xlate to rewrite DNS record
  inactive Disable a NAT rule
  no-proxy-arp Disable proxy ARP on egress interface
  route-lookup Perform route lookup for this rule
  service NAT service parameters
  unidirectional Enable per-session NAT

nat (inside,outside) source static obj-192.168.10.0 obj-10.130.10.0 destination static obj-10.130.130.0 obj-10.130.130.0 ?

configure mode commands/options:
  description Specify NAT rule description
  inactive Disable a NAT rule
  no-proxy-arp Disable proxy ARP on egress interface
  route-lookup Perform route lookup for this rule
  service NAT service parameters
  unidirectional Enable per-session NAT

So, it's been removed to help me with this note:

If you configure a twice NAT rule, you cannot configure DNS modification if you specify the source address as well as the destination address. These kinds of rules can potentially have a different translation for a single address when going to A vs. B. Therefore, the ASA cannot accurately match the IP address inside the DNS reply to the correct twice NAT rule; the DNS reply does not contain information about which source/destination address combination was in the packet that prompted the DNS request. [2]

Can anyone think of way to get around this limitation?

This Polish guy thinks it's no good either, but no one responded to him :)

http://ccie.pl/viewtopic.php?t=14690

Thanks!

-ryan

[1]
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_ru
les.html#wp1416253
[2]
http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_ov
erview.html#wp1090556

Blogs and organic groups at http://www.ccie.net
Received on Thu May 10 2012 - 15:38:01 ART

This archive was generated by hypermail 2.2.0 : Sun Jun 17 2012 - 09:04:19 ART