Cisco ASA double NAT avec traduction DNS

J'essaye d'installer le double NAT automatique avec la traduction DNS sur Cisco ASA 9.0 (3), et j'ai quelques problèmes avec la partie DNS. J'ai obtenu le double NAT fonctionnant correctement, de sorte que j'ai un serveur en production et en laboratoire avec la même adresse IP. Voir b2masd1, nameif INSIDE (production) et masd1, nameif DMZ (lab).

Lorsque vous envoyez une requête ping de DMZ 10.195.18.182 à 1.195.18.182, je vois que les traductions se déroulent correctement dans les deux sens ...

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

C'est ce que je vois sur 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$

Le problème est que les requêtes DNS de la DMZ vers INSIDE ne sont pas traduites. Quand je demande b2masd1 à partir de la DMZ, je m'attends à ce que le serveur de noms sur INSIDE réponde avec 10.195.18.182, puis l'ASA devrait traduire cela en 1.195.18.182. Cependant, cela ne se produit pas; comme vous pouvez le voir, l'entrée DNS n'est pas traduite.

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$

Quelqu'un peut-il expliquer ce que je dois faire pour traduire correctement les requêtes DNS? J'ai besoin d'une requête pour b2masd1 dans la DMZ vers un serveur de noms sur l'interface INSIDE pour renvoyer 1.195.18.182 (car l'ASA traduit l'INSIDE A-Record 10.195.18.182 en DMZ addr 1.195.18.182).

J'ai mis en place une salle de chat pour aider au diagnostic

Ceci est ma config ...

!
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

Montrez xlate, au cas où cela aiderait ...

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#

Afficher la stratégie de service inspecter le 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#

Captures montrant les requêtes de b2masd1 au serveur de noms (10.195.18.201). NOTEz les doubles requêtes DNS envoyées sur l'interface INSIDE, mais nous ne semblons pas les obtenir sur l'interface DMZ.

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

Répondre à ma propre question pour aider les futurs googleurs. J'ai passé environ 3 heures au téléphone avec TAC; nous sommes enfin arrivés à la cause première du problème.

La solution consiste à ajouter une entrée NAT spéciale, qui correspond à l'adresse IP dans le DNS A-Record lorsqu'il arrive sur l'interface INSIDE.

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

Lorsque j'ai demandé un pointeur vers une documentation décrivant pourquoi la traduction DNS fonctionne de cette façon, le responsable du TAC a déclaré qu'il n'en connaissait aucun décrivant ce comportement. Le responsable du TAC a également mentionné qu'avec plus de code, l'ASA saurait traduire automatiquement le DNS A-Record sans en ajouter explicitement object network DNS_NAT_masd1; cependant, ce n'est pas ainsi que dnsfonctionne aujourd'hui le mot - clé pour NAT ASA. Pour des raisons qui ne sont pas encore complètement claires, l'ASA requiert l'adresse IP DNS A-Record pour correspondre à <proxy_addr>dans l'instruction NAT, en utilisant une syntaxe similaire à celle-ci ...

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

La difficulté est que cette configuration est exactement à l'envers pour ce que vous devez faire si vous allez faire du trafic IP régulier "plan de données" via le pare-feu.

C'est toute la configuration qui fonctionne ...

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

Mike! Merci de partager ça! J'ai utilisé cette solution de contournement avec deux fois NAT, et cela fonctionne aussi!

J'ai deux fois NAT (ASA OS v 9.5):

nat (extérieur, intérieur) source dynamique ANY X destination GroupM GroupN

Donc, j'ai un groupe de serveurs "GroupN" à l'intérieur et je les NAT vers l'extérieur aux adresses IP "GroupM". Les clients de l'extérieur (n'importe lequel) peuvent accéder à mes serveurs et lorsque les clients externes passent par l'ASA, leurs sources sont remplacées par l'adresse IP X.

Ici, il n'est pas possible d'utiliser le mot clé dns. Mais avec votre solution de contournement, j'ai créé un ensemble de NAT d'objet auxiliaire:

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

ET j'ai un traitement DNS qui fonctionne correctement.

BTW, Cisco dans sa documentation dit que cette tâche est impossible :) http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/ 115753-dns-doctoring-asa-config.html

Cordialement, Sergey