Tracert going to the wrong place

We added a new Exchange email server to our network, and for the time being it is running alongside the old server. Internall I have no problems accessing both, through Outlook or Webmail.

However from the outside I can't seem to get to the new server. I have an ASA5510 which I have set up with the proper ACL and NAT info, (translations for the public IP 71.x.x.202 to internal 192.x.x.250 for ports 110, 25 and 80) but when I try to reach the new server via webmail it does not even seem to be connecting to the ASA, as nothing shows up on the log.

So I ran a tracert for the public IP address of the new server (which has MX and A records set up for the new email server) but for some reason the tracert ends up going to the public IP of the old email server and then stops there.

Any ideas as to why it's going to the old server IP?

The MX info is set up as follows:

10 oldmail.domain.com 71.x.x.205
20 newmail.domain.com 71.x.x.202

Thanks.
LVL 1
cfgchiranAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ParanormasticCryptographic EngineerCommented:
Assuming you have your DNS set up correctly, you might try waiting a little bit for DNS replication - if it is your own then wait half an hour or so (usually 15 mins is okay), if public maybe up to a day - your DNS provider could tell you how often they actually replicate.

You can also try ipconfig /flushdns followed by ipconfig /registerdns and see if that helps.  Try the registerdns option on the server as well.

When checking your DNS, make sure to check both your forward and reverse lookup zones...  If you are able to, try accessing from the local server, from the dns server, as well as your client.
0
cfgchiranAuthor Commented:
Thank you for the response.

While we have internal DNS servers, the public information is provided by our service provider. The MS info was set up last week, so it's been more than the 72 hours they said it could take for the DNS to propogate.

Internall the server is set up to point to the local DNS servers, since it sits behind the ASA firewall. I am assuming the issue is with public DNS settings since when I try to use a browser to connect to 71.x.x.202 nothing shows up on my ASA. So it does not look like it's even making it that far.

When I a reverse DNS for my old email server's IP 71.x.x.205, it reverses to oldemail.domain.com, but when I do it for the new IP, it reverses to 71-x-x-202.domain.com

So is this simply an issue of the reverse DNS not been setup?
0
easyDKCommented:
1. I'm not sure how does work ASA, but sometimes it happens, that is problem with multiple IP addresses on public interfaces of firewall, that provides source NAT to the first IP address. I faced it on NetScreen, but would demonstrate on Linux:
eth0 = 10.0.0.25/24  is NATed to 192.168.100.25  
eth0:0 = 10.0.0.35 is NATed to 192.168.100.35.
eth1 is 192.168.100.1, which is default gw
If on public interface is performed Masquerade, then whole network is source NATed to 10.0.0.25. If whatever router on the way prohibits different flow back and forth, then I can't reach the other IP address appart from the one, that is performed SNAT or Masquerade to.
So, what actually might happen?

I send TCP packet to port 25 on 10.0.0.35, which is NATed to 192.168.100.35. If there runs SMTP, it sends packet back thru default gw. If packet leaves the firewall and masquerade is performed, then it gots source address not 10.0.0.35, but 10.0.0.25, that could be problem for certain TCP/IP implementations.
0
cfgchiranAuthor Commented:
None of the solutions presented worked. However it really did not become an issue for me once the PTR was set. All the traffic flows ok.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DNS

From novice to tech pro — start learning today.