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

>why does matter if you NAT your private space to a different address space? I guess I don't see the logic

nat has a measurable application performance in many industries... if this is a standard network its not a big deal - other than to keep a table of what is routed where if dual paths exist, etc.

I have some 5505's and time Friday I'll let you know if I devise something while I'm digging

-----Original Message-----
From: Ryan West [mailto:rwest_at_zyedge.com]
Sent: Thursday, May 10, 2012 1:35 PM
To: Joseph L. Brunner; CCIE Lab (ccielab_at_groupstudy.com)
Subject: RE: [OT] - ASA 8.3+ Twice NAT w/DNS doctoring vs ASA 8.2 Policy

I'm not a fan of the design either, but it's a technical discussion about whether the feature exists or how you would implement it in an 8.3+ NAT world. 8.2 won't be supported forever. However it's working, and very reliably, in 8.2 with policy NAT. As I was stating before, running several hundred records with multiple sandbox environments leads to an administrative workload issue.

A lot of companies, particularly smaller SMB/SME's are still using RFC1918 for partner L2L communication. Some are migrating to public NAT's to handle the tunnels, but taking a hardline "renumber your scheme cause it overlaps with mine" doesn't really fly. If you trust devices to do NAT for just about everything else (load balancing/public facing equipment, overload, hairpin), why does matter if you NAT your private space to a different address space? I guess I don't see the logic.

As far as how the DNS rewrite works, since DNS is inspected already by most default policy-map's, it's just examining the response from a server (inside or outside) in which a static translation with the dns keyword at the end. If it sees the translated address coming across, it will rewrite it with the internal address. Other NAT's are not affected.

-ryan

-----Original Message-----
From: Joseph L. Brunner [mailto:joe_at_affirmedsystems.com]
Sent: Thursday, May 10, 2012 12:44 PM
To: Ryan West; CCIE Lab (ccielab_at_groupstudy.com)
Subject: RE: [OT] - ASA 8.3+ Twice NAT w/DNS doctoring vs ASA 8.2 Policy

The way I understand this technology, the dns answer is changed to the address the real answer is natted to (it's been a few years sorry if I'm wrong). This way no dns query can pass the ASA if it would cause the client to want to reach an ip that it would be natting...

Its really a bad design to nat between private networks for the sake of address overlap - how hard would it be to re-number???

-----Original Message-----
From: Ryan West [mailto:rwest_at_zyedge.com]
Sent: Thursday, May 10, 2012 12:39 PM
To: Joseph L. Brunner; CCIE Lab (ccielab_at_groupstudy.com)
Subject: RE: [OT] - ASA 8.3+ Twice NAT w/DNS doctoring vs ASA 8.2 Policy

What's risky about doing a DNS rewrite?

-----Original Message-----
From: Joseph L. Brunner [mailto:joe_at_affirmedsystems.com]
Sent: Thursday, May 10, 2012 11:38 AM
To: Ryan West; CCIE Lab (ccielab_at_groupstudy.com)
Subject: RE: [OT] - ASA 8.3+ Twice NAT w/DNS doctoring vs ASA 8.2 Policy

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 - 17:37:11 ART