Inside/dmz accessing public dns of dmz

[Hagfish]

Hello all, I have a question. I have two mail servers (separate servers) on the dmz network of my pix (30.30.30.x). When one tries to send mail to other, it's getting rejected because the mail server is trying to access the other by it's translated public address 70.x.x.x. I did a little research on this and tried adding "dns" to my static translation lines but unfortunately this did not appear to do anything. The domain for the mailservers is still pointing to the public address. Here are the lines I added/changed. Did I miss something? TIA

static (dmz,outside) 70.x.x.100 mail1 dns netmask 255.255.255.255 0 0
static (dmz,outside) 70.x.x.101 mail2 dns netmask 255.255.255.255 0 0

 

[themut]

For DNS doctoring to work, the DNS querry must traverse the PIX. Where is the DNS server is it on the same DMZ as your mail servers? If so, there's nothing the PIX can do to rectify this problem. You would need to either use a DNS server for local requests or add an entry on the host file for the real IP addresses so the servers never contact the DNS server to resolve the IP addresses.

 

[Hagfish]

There is no internal dns server. The servers are configured to use the dns server at the co-location site.

 

[themut]

Can you verify the mail servers are querrying the DNS server? I would put a sniffer on the DMZ to determine if the servers are actually sending DNS querries. The "dns" keyword on the static translation should do the trick.

 

[Hagfish]

I think they must be, because from the dmz servers I can get to websites by going to

http://www.yahoo.com,

etc.. and the only dns servers I have configured in the network properties are the ones from the co-lo site.

 

[themut]

Yea but you don't know if it is querying the DNS server to resolve the mail's servers IP address. Like I said the dns keyword should do the job, if it isn't I would determine the cause of the failure. One possible cause is the PIX doesn't see the DNS querries, one way to verify it is to place a sniffer, like Ethereal. This way I would verify three main things:

1) If the servers are querrying a DNS server
2) If the querries will travers the PIX
3) The DNS server being querried

 

[Hagfish]

Ok, I'll look into doing that when I can, but in the meantime, I can tell you that the mail server administration has a config screen where I was required to put in a dns server. I put in the co-lo's dns server there.

 

[themut]

Make sure the hostfiles on the mail servers don't have an entry for each other. How does the traffic get from the DMZ to the co-location? Does it traverses the PIX? Are you sending the traffic there through a VPN tunnel?

 

[Hagfish]

Well, I'm not sure if this is what you're talking about but I do have a line that is:
static (inside,dmz) 10.0.2.0 10.0.2.0 netmask 255.255.255.0 0 0

and then I have access rules for dmz machines to access

http://www and

domain tcp ports for web access.

 

[themut]

All I asked for was the path followed for the packets from the mail server to the DNS server

 

[Hagfish]

Is ethereal freeware? sounds like I better run that before you can continue helping me out (which I really appreciate).

 

[LloydSev]

He also said to check your hosts file on the email machine... are there any lines there corresponding to the other email machine?

Computer/Network Technician
CCNA

 

[Hagfish]

I didn't even see a hosts file in the winnt\system32\.. I did however install ethereal on the machine but there's so many things going on during the capture, I'm wondering what exactly you want me to look for. DNS packets originating from that particular dmz ip (30.30.30.100)? Right now, the only dns packets I'm seeing are coming from 30.30.30.101 (which is the main IP configured on the network card, 30.30.30.56 is an additional IP configured on the same nic (the ip that the mail server is translated to. I do see smtp packets going out through 56 but nothing dns. What should I look for? Thanks!

 

[themut]

You should look for DNS traffic, specifically the querries from the mail server (asking to resolve the name for the other mail server) and the replies from the DNS server. You need to recreate your problem and analyze the sniffer traces captured.

 

[Hagfish]

Ok, I sent a test message and set a dns filter. It looks like it's definitely hitting the co-lo's dns server. As soon as I hit send on the test message I saw a message pop up in ethereal that showed the source IP address as 30.30.30.101 and the destination as 234.x.x.x which is the dns server at the co-lo site. The description says "standard query mx mydomain.com"

 

[themut]

Ok good, now based on the destination MAC address, can you determine what is the packet's next hop along the way? It should be the default gateway. You need to determine the path followed by the DNS querry, this will tell you if the DNS querry is passing through the PIX. If it isn't then that's the reason why DNS doctoring is not working. You never mentioned if this traffic is sent through a VPN tunnel.

 

[Hagfish]

Hmm. I see what you're saying, and I'm trying. What what to I need to do to follow that packet.. Is it on the same screen I'm looking at where I've filtered the dns.. should I send you a screen shot?

 

[Hagfish]

Ok, it took a few mins, but now I'm seeing a source 30.30.30.101 and destination 30.30.30.1 (gateway of dmz) -- protocol is dmz and info says "standard query A mydomain.com" The same line occurs about 3 times, and then the exact same line again except the co-lo dns IP address is in the destination.

 

[themut]

Ok Ethereal has done its job, which was to determine if the DNS queries were sent by the mail server to the correct DNS server. Now, if you do "tracert VVV.XXX.YYY.ZZZ" from the DOS prompt, where VVV.XXX.YYY.ZZZ is the IP address of the DNS server at the co-lo, you will get the path followed from the mail server to the DNS server. Is this path taken passing through the firewall?

 

[Hagfish]

I think I'll have to get icmp going before I can do the tracert. If I try tracert right now it times out immediately, and I can only ping internal from dmz to inside and vice versa.. I can't ping externally on the inside of dmz interfaces.. isn't it recommended to keep it that way?