Problem with cisco PIX 501 when using domain name to access port instead of IP

Hi Experts!

I have a Pix 501 firewall wich is currently allowing access to my mail server on ports 25 and 110 using NAT and Static Routes. The IP that "ties" the firewall with the server is the IP configured in the outside interface of the router (200.100.100.100). The internal server's ip is 10.0.1.1.

What works:

1. I can PING the 200.100.100.100 ip addres from any outside network with no problem, I get replies.
2. The IP is mapped through DNS to name mail.myserver.com. I can PING mail.myserver.com and get a reply from the IP with no problem.
2. I can telnet 200.100.100.100 on ports 25 and 100 and I can connect with no problem.

What does not work:

1. If I try to telnet de domain instead of the IP, for example telnet mail.myserver.com 25   or telnet mail.myserver.com 110 it takes a LOT of time to connect, sometimes it times out.
2. Because of this, mail clients return errors and do not download or send mail.


Question: Why would connecting through the domain name takes so long even if I can ping the domain name getting decent reply times, and I can connect to the ports with the ip address real quickly?

I tried removing the fixup for port 25, but same thing happens.

thanks a lot!!
glopezzAsked:
Who is Participating?
 
batry_boyConnect With a Mentor Commented:
You state that this works:

I can telnet 200.100.100.100 on ports 25 and 100 and I can connect with no problem.

and this doesn't:

If I try to telnet de domain instead of the IP, for example telnet mail.myserver.com 25   or telnet mail.myserver.com 110 it takes a LOT of time to connect, sometimes it times out.

The only difference between those two functions is DNS name resolution, which is being used in the one that doesn't work.  To verify that it is a DNS resolution issue, have you tried putting an entry for mail.myserver.com into an external client's local "hosts" file so that the name resolution occurs locally and then trying your telnet test to the FQDN?
0
 
mdefalcoCommented:
good idea batry boy. i was thinking it was the dns config also. run a traceroute to the domain name also and see where it goes. it will time each hop, so you can see where the delay is.

jim
0
 
glopezzAuthor Commented:
Thanks Guys, it was a name resolution problem.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.