Cisco ASA Double NAT mit DNS-Übersetzung


11

Ich versuche, Double Auto NAT mit DNS-Übersetzung unter Cisco ASA 9.0 (3) einzurichten, und habe einige Probleme mit dem DNS-Teil. Ich habe Double NAT richtig funktionieren lassen, so dass ich einen Server in der Produktion und im Labor mit der gleichen IP-Adresse habe. Siehe b2masd1, nameif INSIDE (Produktion) und masd1, nameif DMZ (Labor).

Wenn Sie von DMZ 10.195.18.182 bis 1.195.18.182 pingen, werden die Übersetzungen in beide Richtungen korrekt ausgeführt ...

D:10.195.18.182      S:192.168.11.101       D:1.195.18.182   S:10.195.18.182
             <-----------                         <-----------
                                           1) echo-request to 1.195.18.182
                                           nat (INSIDE,DMZ) static 1.195.18.182 dns



  S:10.195.18.182    D:192.168.11.101       S:1.195.18.182   D:10.195.18.182
              ------------>                        ------------>
      2) echo-reply to 192.168.11.101
      nat (DMZ,INSIDE) static 192.168.11.101 dns


 b2masd1                   +-----------+              masd1
 10.195.18.182      INSIDE |           | DMZ          10.195.18.182
 Mfg Server   -------------| Cisco ASA |------------  Devel Server
                           |           |
                           +-----------+

 Manufacturing                                        Development
 Network                                              Network
 Security: 100                                        Security: 50

Das sehe ich auf masd1 ...

masd1$ /usr/sbin/ping 1.195.18.182
PING 1.195.18.182: 64 byte packets
64 bytes from 1.195.18.182: icmp_seq=0. time=0. ms
64 bytes from 1.195.18.182: icmp_seq=1. time=0. ms

----1.195.18.182 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 0/0/0
masd1$

Das Problem ist, dass DNS-Abfragen von der DMZ an INSIDE nicht übersetzt werden. Wenn ich in der DMZ nach b2masd1 frage, erwarte ich, dass der Nameserver auf der INSIDE mit 10.195.18.182 antwortet, und dann sollte der ASA dies in 1.195.18.182 übersetzen. Dies geschieht jedoch nicht. Wie Sie sehen, wird der DNS-Eintrag nicht übersetzt.

masd1$ nslookup
Using /etc/hosts on:  masd1

> a2mosd1
Using /etc/hosts on:  masd1

looking up FILES
Trying DNS
Name:    b2masd1.domain.local
Address:  10.195.18.182

> exit
masd1$

Kann jemand erklären, was ich tun muss, um DNS-Abfragen korrekt zu übersetzen? Ich benötige eine Abfrage für b2masd1 in der DMZ an einen Nameserver auf der INSIDE-Schnittstelle, um 1.195.18.182 zurückzugeben (da der ASA den INSIDE A-Record 10.195.18.182 in die DMZ-Adresse 1.195.18.182 übersetzt).

Ich habe einen Chatraum eingerichtet , um bei der Diagnose zu helfen


Verschiedene Debugging-Informationen

Das ist meine Konfiguration ...

!
interface GigabitEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 10.195.2.197 255.255.255.248 standby 10.195.2.198
!
interface GigabitEthernet0/1
 nameif DMZ
 security-level 50
 ip address 10.195.2.201 255.255.255.248 standby 10.195.2.202
!
object network DMZ_NAT_masd1
 host 10.195.18.182
 description xlate masd1 NAT DMZ src 10.195.18.182 to INSIDE src 192.168.11.101
object network INSIDE_NAT_masd1
 host 10.195.18.182
 description xlate masd1 NAT INSIDE src 10.195.18.182 to DMZ src 1.195.18.182
!
object network DMZ_NAT_masd1
 nat (DMZ,INSIDE) static 192.168.11.101 dns
object network INSIDE_NAT_masd1
 nat (INSIDE,DMZ) static 1.195.18.182 dns
!
policy-map type inspect dns DNS_INSPECT_MAP
 parameters
  message-length maximum 512
!
policy-map global_policy
 class inspection_default
  inspect dns DNS_INSPECT_MAP
!
service-policy global_policy global

Zeigen Sie xlate, falls dies hilft ...

B2-DEV-FW1/DEVELOPMENT# sh xlate local 10.195.18.182
121 in use, 126 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
NAT from DMZ:10.195.18.182 to INSIDE:192.168.11.101
    flags sD idle 0:00:01 timeout 0:00:00
NAT from INSIDE:10.195.18.182 to DMZ:1.195.18.182
    flags sD idle 0:03:55 timeout 0:00:00
B2-DEV-FW1/DEVELOPMENT#

Show service-policy inspect dns ...

B2-DEV-FW1/DEVELOPMENT# sh service-policy inspect dns

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns DNS_INSPECT_MAP, packet 15302, drop 0, reset-drop 0, v6-fail-close 0
        message-length maximum 512, drop 0
        dns-guard, count 7649
        protocol-enforcement, drop 0
        nat-rewrite, count 139
B2-DEV-FW1/DEVELOPMENT#

Erfasst Abfragen von b2masd1 an den Nameserver (10.195.18.201). HINWEIS: Die doppelten DNS-Abfragen, die an die INSIDE-Schnittstelle gesendet werden, scheinen jedoch nicht an die DMZ-Schnittstelle gesendet zu werden.

B2-DEV-FW1/DEVELOPMENT# capture FOO interface DMZ real-time match udp host 10.195.18.182 host 10.195.18.201

Warning: using this option with a slow console connection may
         result in an excessive amount of non-displayed packets
         due to performance limitations.

Use ctrl-c to terminate real-time capture


   1: 09:54:35.994730       10.195.18.182.52639 > 10.195.18.201.53:  udp 45
   2: 09:54:35.995218       10.195.18.201.53 > 10.195.18.182.52639:  udp 83
   3: 09:54:47.875076       10.195.18.182.52644 > 10.195.18.201.53:  udp 53
   4: 09:54:47.875549       10.195.18.201.53 > 10.195.18.182.52644:  udp 136
   5: 09:54:47.875854       10.195.18.182.52645 > 10.195.18.201.53:  udp 51
   6: 09:54:47.876297       10.195.18.201.53 > 10.195.18.182.52645:  udp 138
   7: 09:54:47.876648       10.195.18.182.52646 > 10.195.18.201.53:  udp 35
   8: 09:54:47.877075       10.195.18.201.53 > 10.195.18.182.52646:  udp 35

B2-DEV-FW1/DEVELOPMENT# capture FOO interface INSIDE real-time match udp host 192.168.11.101 host 10.195.18.201

Warning: using this option with a slow console connection may
         result in an excessive amount of non-displayed packets
         due to performance limitations.

Use ctrl-c to terminate real-time capture


   1: 09:56:27.282608       10.195.18.182.52742 > 10.195.18.201.53:  udp 43
   2: 09:56:27.282684       192.168.11.101.52742 > 10.195.18.201.53:  udp 43
   3: 09:56:27.283081       10.195.18.201.53 > 192.168.11.101.52742:  udp 59
   4: 09:56:27.283096       10.195.18.201.53 > 10.195.18.182.52742:  udp 59

Antworten:


8

Beantwortung meiner eigenen Frage, um zukünftigen Googlern zu helfen. Ich habe ungefähr 3 Stunden mit TAC telefoniert. Wir haben endlich die Grundursache des Problems gefunden.

Die Lösung besteht darin, einen speziellen NAT-Eintrag hinzuzufügen, der mit der IP-Adresse im DNS-A-Eintrag übereinstimmt, wenn dieser auf der INSIDE-Schnittstelle eingeht.

object network DNS_NAT_masd1
 description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
 host 1.195.18.182
 nat (DMZ,INSIDE) static 10.195.18.182

Als ich nach einem Zeiger auf eine Dokumentation fragte, die beschreibt, warum die DNS-Übersetzung so funktioniert, sagte der TAC-Leiter, dass er keine kenne, die dieses Verhalten beschreiben. Der TAC-Leiter erwähnte auch, dass der ASA mit mehr Code den DNS-A-Eintrag automatisch übersetzen würde, ohne ihn explizit hinzuzufügen object network DNS_NAT_masd1. So funktioniert das dnsSchlüsselwort für ASA NAT heute jedoch nicht. Aus Gründen, die noch nicht vollständig geklärt sind, verlangt der ASA, dass die DNS-A-Record-IP mit der <proxy_addr>in der NAT-Anweisung übereinstimmt , wobei eine ähnliche Syntax verwendet wird ...

object network obj-EXAMPLE
 description NAT object explicitly for translating DNS A-Records
 host <proxy_addr>
 nat (<REAL_INTF>,<PROXY_INTF>) static <real_addr> dns

Die Schwierigkeit besteht darin, dass diese Konfiguration genau das ist, was Sie tun müssen, wenn Sie keinen regulären IP-Verkehr auf "Datenebene" durch die Firewall führen möchten.

Dies ist die gesamte Konfiguration, die funktioniert ...

object network DMZ_NAT_masd1
 host 10.195.18.182
 description xlate masd1 NAT DMZ src 10.195.18.182 to INSIDE src 192.168.11.101
object network INSIDE_NAT_masd1
 host 10.195.18.182
 description xlate masd1 NAT INSIDE src 10.195.18.182 to DMZ src 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
 host 1.195.18.182
 description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
!
object network DMZ_NAT_masd1
 nat (DMZ,INSIDE) static 192.168.11.101
object network INSIDE_NAT_masd1
 nat (INSIDE,DMZ) static 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
 nat (DMZ,INSIDE) static 10.195.18.182 dns

1

Mike! Vielen Dank für das Teilen! Ich habe diese Problemumgehung mit zweimaligem NAT verwendet und sie funktioniert auch!

Ich habe zweimal NAT (ASA OS v 9.5):

nat (außen, innen) Quellendynamik ANY X Ziel GroupM GroupN

Ich habe also eine Gruppe von Servern "GroupN" in meinem Inneren und ich NAT sie nach außen zu IP-Adressen "GroupM". Clients von außerhalb (beliebig) können auf meine Server zugreifen, und wenn externe Clients ASA durchlaufen, werden ihre Quellen durch die IP-Adresse X ersetzt.

Hier ist es nicht möglich, das DNS-Schlüsselwort zu verwenden. Aber mit Ihrer Problemumgehung habe ich eine Reihe von Hilfsobjekt-NATs erstellt:

object network My_Server1_on_Inside
 host <NATed IP of Server1>
 nat (outside,inside) static <Real IP of server1> dns

UND ich habe DNS Doctoring richtig funktionieren.

Übrigens sagt Cisco in seiner Dokumentation, dass diese Aufgabe unmöglich ist :) http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/ 115753-dns-doctoring-asa-config.html

Beste Grüße, Sergey

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.