Charles- I could be wrong, but my interpretation of the doc's covering the Alias command says that you can't have your cake and eat it too. :)
What I mean is, I don't believe you can DNS-Doctor and Destination-NAT at the same time. Like I said, I could be wrong. >From what I understand, you need to do your translation with a static command: "Static (inside,dmz) 10.3.3.1 10.1.1.x netmask 255.255.255.255 0 0" ..and then set up your DNS-Doctor Alias. "Alias (inside) 10.1.1.x 10.3.3.1 255.255.255.255" Note: Verify that the DNS server resolves your host/domain name to the global IP address of the web server by issuing an nslookup command. The result of the nslookup on the client PC should be the internal IP address of the server (10.1.1.x), because the DNS reply gets doctored as it passes through the PIX. Also note that, for DNS fixup to work properly, proxy-arp has to be disabled. If you are using the alias command for DNS fixup, disable proxy-arp with the following command after the alias command has been executed. "sysopt noproxyarp internal_interface" If you are also trying to maintain DNS integrity from the outside point of view, I believe the 'DNS' keyword is all that is needed in the following command (to allow the outside world to also reach the DMZ host). "Static (dmz,outside) 10.3.3.1 10.2.2.1 dns netmask 255.255.255.255" Or, taking the concepts from the Alias Doc's, you could do this. "Alias (outside) 10.2.2.1 10.3.3.1 255.255.255.255" ...but I think this might be the older way of doing it. Don't forget your ACL's so that DNS and whatever other services need to be accessed on the DMZ host (one ACL for the Inside, one for the Outside). HTH's -Mark -----Original Message----- From: Charles EEEE Riley [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 7:22 AM To: [EMAIL PROTECTED] Subject: PIX Firewall 6.2.2 Inside network can not reach DMZ hosts [7:69756] Hi, all, I have a problem that is making me scream and shout, gonna knock myself out. It has to do with my PIX firewall configuration. The long and short of my problem is that the inside network can only reach inside hosts and outside networks: it can not reach any host on on the DMZ, depsite the fact that there are numerous statics and alias configured to permit it to do so. I have a 515 6.2 with the following networks configured: Inside 10.1.1.0/24 Outside 10.2.2.0/24 DMZ 10.3.3.0/24 First, we have names for ServerA located on the DMZ network: name 10.3.3.1 SERVERA_DMZ name 10.2.2.1 SERVERA_OUTSIDE ServerA actually is addressed with 10.3.3.1 because it is on the DMZ; the 10.2.2.1 is its outside address (as well as being its registed DNS name). If an inside networker DNS queries for SERVERA, the following commands are supposed to swap the outside address for the DMZ address. IN other words, intercept the DNS repy and change it so that the inside network will then establish a session to 10.3.3.1 (dmz address), not to 10.2.2.1 (outside nat'ed address) alias (inside) SERVERA_DMZ SERVERA_OUTSIDE 255.255.255.255 alias (inside) SERVERA_OUTSIDE SERVERA_DMZ 255.255.255.255 Initial DNS tests shows that this is not happening: the inside network DNS requeries are getting outside addresses. Compounding the problem is translation process itself. The below states that when Inside networks go to the DMZ network, PAT their address to 10.3.3.9, excepting those sessions listed in ACL 100 (which upon checking do not affect the tranlation in this particular case). nat (inside) 0 access-list 100 nat (inside) 1 10.1.1.0 255.255.255.0 0 0 global (DMZ) 1 10.3.3.9 netmask 255.255.255.0 So, in a happy world, the inside network should DNS query for SERVERA, the PIX should intercept replies and change to a DMZ address (alias), and NAT should then translate as appropriate. In the words of Larry King, it ain't happening, gang...and I don't know why. I beseech, oh, Group of Infinite Wisdom, for you assistance. As a closer, my problems started when I upgraded to 6.3.1...what a mistake. I have since downgraded it back to 6.2, and have checked and rechecked the config...there are no commands missing. TIA, Charles Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=69779&t=69779 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
