DNS Doctoring for PIX 6.3(4)

[doliver]

Can some one please tell me the best way to do 'DNS Doctoring' for internal cleints to reach an Internal DNS server without using the 'alias' command. Thanks for your assistance.

Dean

[scoclayton]

DNS Doctoring will not help in this case. The alias command accomplished 2 things - DNS Doctoring and Destination NAT. Destination NAT is just as it sounds...nat'ing the destination address as opposed to the source address as we generally use it. Based on your description, you are using the alias command on your PIX to NAT the destination address from the global address on the webserver to the actual DMZ address that is assigned to the NIC.

Destination NAT is now accomplished by "reversing" the static command. For instance, let's say that your webserver on your DMZ had an actual IP address of 10.100.1.100 but the users on the inside were trying to access this server via the global address of 1.2.3.4. To NAT the destination address on the packets from the inside users to the webserver on the DMZ, you would enter the following command:

static (dmz,inside) 10.100.1.100 1.2.3.4

Notice this is backwards of how you normally see the static commands. This tells the PIX to NAT the destination when going from a higher security interface to a lower security interface as in the inside to the DMZ.

Does this make sense?

Scott

[dgaunt]

Yes, but I've also been given to understand that you can't have 2 static NAT's to the same IP Address. I've tried to have 2 "outside" addresses both going to the same DMZ IP address via static, and the second Xlate never showed up in the table, and was unreachable. I did try the Destination NAT on a test web server, and was unable to get to the web server from the inside via the "outside" IP address.

[scoclayton]

Q. Yes, but I've also been given to understand that you can't have 2 static NAT's to the same IP Address. I've tried to have 2 "outside" addresses both going to the same DMZ IP address via static, and the second Xlate never showed up in the table, and was unreachable.

A. This restriction has nothing to do with what I was trying to explain. Translations are built per interface on the PIX. You can have multiple statics pointing to the same local address (on the DMZ as an example) provided the global addresses are on different interfaces (as in my example).

As for the destination NAT test, you gotta give me some more information if you want some help.

Scott

[dgaunt]

Here is the outside static Configuration:

static (DMZ,outside) 65.118.60.241 192.168.25.241 netmask 255.255.255.255 0 0

No problems getting to the server from the outside. Now, the following is the alias command I use on the inside, to the server. All users on the inside can now access the DMZ server by it's "outside" address:

alias (inside) 65.118.60.241 192.168.25.241 255.255.255.255

Here is the destination NAT I built, to replace the alias. After clearing the Xlate tables, to remove t he alias information, the server cannot be accessed by the 65 IP address from the inside. Additionally, it can no longer be accessed by the 192 address either.

static (DMZ,inside) 192.168.25.241 65.118.25.241 netmask 255.255.255.255 0 0

When I do a show xlate, it shows up, but the show xlate shows all current translations, and the outside and inside translations are the same, so I'm not sure which it is refering to. (also, thanks for your help so far, I really appreciate you taking the time to help me out)

[scoclayton]

OK, I see the issue now. The destination NAT static you added should actually be this:

static (DMZ,inside) 65.118.25.241 192.168.25.241 netmask 255.255.255.255 0 0

You want the PIX to NAT the destination IP of 65.118.25.241 on the inside interface to 192.168.25.241 and put it on the DMZ interface. Remember, the interfaces in the brackets correspond to the opposite order of addresses like this:

static (intf1,intf2) address2 address1

Make sense?

Scott

[scoclayton]

In looking back at my original example, it looks like I screwed this order up as well. Sorry for the confusion.

Scott

[david.xu]

Hi,Scott

I have the same problem for the internal user to access the internal web server with public ip address which get from external DNS server. I configure the static nat this way:

static (inside,outside) 137.82.x.x Domino dns netmask 255.255.255.255 0 0

but looks it doesn't work, when I do nslookup internally, I still get the public ip address of this Domino server.

Is there anything wrong in my configuration , or is there any other command line I should put into the pix firewall to cooperate with this command?

Thanks,

David

[scoclayton]

Did you clear the existing translation after adding the above command into the config? If not, issue a 'clear xlate' and try the nslookup for whatever 137.82.x.x is.

Scott

[bfflusek]

Scott,

On a similar topic, is there a way to do something similar with outbound dns responses? The scenario is a Cisco content switch doing DNS and responding with a 10.x.x.x address to an Internet query. Can the Pix be configured to take that address and change it to a valid Internet IP that matches the NAT for the 10.x.x.x address?

Just curious, since that would save significant reconfiguration on the network if one could do that.

Thanks,

Bill

[scoclayton]

I must admit that I have never tested this but I *think* the 'dns' option is supposed to work bi-directionally so the scenerio you describe *should* work. Give it a shot and let us know.

Scott

[hoangbp]

Dean:

I am just as confused as Scott. If I understand what your trying to do correctly, you simply want to do DNS query for your internal clients with the DNS server(s) sitting behind the PIX (on the same interface -i.e inside).

In that case, I don't see why you would need to implement DNS Doctoring.

Can you provide us with a high level diagram of network with regards to where the clients and DNS servers are located.

Thanks,

Binh