Start Free Trial

asked on

two different Exchange servers behind the same firewall can't send email to each other

Ok, I might need some serious Expert help here......Here's the scenario. I run a company of about 100 people with Exchange 2003 behind a Sonicwall firewall. Been running just fine for 6 years plus. This past week we sub leased some space out to another company. I set them up on a completely separate network and subnet using different switches and plugging them into a separate interface on the firewall.....So basically two segregated networks that only share the same firewall and Internet connection. They installed an Exchange 2008 SBS server on their side. It's up and running fine. They currently have two MX records for their domain. The first one, with a priority of 10 points to a public IP address that I gave them to use for their Exchang/mail. The second one points to their "old" Network Solutions mail server and has a priority of 90. When we send mail to them, it ONLY goes to the Network Solutions host, not their Exchange server. I've setup a rule on the SonicWall to NAT that public IP address to their internal server, and they get mail from all other domains just fine, but not ours. If they check their network solutions email, the mail we send DOES show up there........And then they can reply to us just fine. If they try to send to us from Exchange/Outlook, it does not come through either......I'm totally stumped. I'm *thinking* it's some issue with the firewall thinking that it's a loop or something, however we never get NDRs or anything. Spam and/or Junkmail has been checked and is not the issue.......Suggestions?

Hmmm you're saying they can reply to you from Network Solutions using a web interface but not directly from their Exchange server?What happens when they try to send to you that way?

Sounds as if your server might just have the old MX setup cached. How long since you put their new MX record up with priority 10?

ASKER

About 3 days. But they also can't send to us, it just never comes.....

ASKER

...From Exchange that is. It comes through fine from their "old" web interface.

Yah but if it never comes, there must be a queue where that mail is. And if you turn up SMTP logging you'll possibly see what's failing?

You're probably just caching the old MX info on your server for their domain, it'll probably start working sometime soon. ;)

From their server you can open a cmd prompt and type NSLOOKUP and then
TYPE=MX
their-email-domain-name
You should see the address to which mail should be delivered.
Then from a cmd box
telnet <that address> 25
and see if you get a reply from your mail server back to to theirs.

ASKER

Ok, fair enough.....I understand that, BUT......Why wouldn't THEY be able to send email to US? Ours hasn't changed in YEARS?

ASKER

One more thing....When I go to MXtools.com and get their MX record and run the Diagnostics on it from MXtools, IT does fail at Reverse DNS lookup....Could that be the problem?

Yes it could but please try the steps above. If it's a reverse DNS problem your server will probably drop an error to the other.

actually no, a reverse dns problem (altho important to address) should result in a bounce not a black hole :)

ASKER

Ok. I'm home now, can I do an NSlookup on their MX record from home and try to telnet to it from here, or.....?

ASKER

I know what the IP is "supposed" to be if that helps......

No what I'm trying to find out is what happens to mail from their exchange server going to yours. So the idea is to find out where their server thinks mail should go, if that's correct then try to telnet to that address from their server. Make sense?

ASKER

Yes, but I do not Administer their network, so that will have to wait until I talk with their guy tomorrow. Couldn't I try to figure out where MY Exchange server thinks mail to THEM should go and then try to telnet into their server since it's doing the same thing either way (getting lost)?

Oh hmmm see if either server can ping the other. I bet it's the Sonicwall isn't set up to route one external IP to the other?

ASKER

I'm almost POSITIVE that's what is going on, but I don't know how to fix it. It's setup right now so that the networks are COMPLETELY segregated (as it should be), so we shouldn't be able to ping each other. Plus, I think my ISP, who owns the public IPs, may have turned off ping, since I can't even ping the public IP of my own mail server. Thanks for all your help by the way......

No, you should be able to ping the EXTERNAL address of one from the other. Or at least telnet to it on port 25. :)

To elaborate: what needs to be segregated is the private IPs, not the public ones but I'm guessing it's either your ISP or the Sonicwall's setup is incorrect because two Internet IPs should be able to talk to each other. :)

ASKER

Ok, I just VPN'd in to my office PC. I can telnet to both external addresses from my admin PC, although when it connects, the terminal window just goes blank......not sure what to type there?

You should be getting some kind of response.
http://support.microsoft.com/kb/153119

(try it directly from the home computer for comparison, if you have "use default gateway" on with the VPN you'll have to disco first)

ASKER

Understood. I can telnet to my Exchange server from inside my network using my internal server name, but not the public IP. I cannot telnet to their server at all.

ASKER

I can successfully telnet to the FQDN name of my Exchange server from home. No problem, but not to the external IP. I cannot telnet to either THEIR public IP OR FQDN on port 25.

ASKER

From home.....Not VPN'd in.

ASKER

Scratch that...I still had VPN connected. Can't telnet to either ours or theirs from home, to the IP or FQDN.

ASKER

It just never connects. If I type in:

telnet <mail.mydomain.com> 25 from home it resolves to the proper IP but doesn't allow a telnet session. To either of our domains. Our mail hasn't had problems in years.

No brackets right? :)

If you can't telnet to your primary MX on 25, is there a backup MX that might be forwarding to you?

ASKER

No brackets. From behind my companies firewall I can telnet to my own mail server no problem.

ASKER

But that might be just telneting to the internal IP. The way our Exchange server is setup is like this:
Internal server name: mail.mydomain.com
Internal IP: 172.17.x.x
On the sonicwall I used the Public Server Wizard/NAT to point one of my external IP addresses to the internal IP of the server.

No issues for years, and still no issues except that these two domains behind the SonicWall can't send email to each other.

OK well, your ISP (Comcast?) could be blocking outgoing on 25 to servers other than their own to screw spammers among their clientele. :)
Let me make a temp e-mail address...ok if you want, e-mail me the two domain names at 1time@synergycorp.com and i will check them.

ASKER

Email sent.

Okay your domain has two mx records:
30 inbound.yourdomain.com
10 home.yourdomain.com

inbound doesn't work, home does.

The other domain has a 90 and a 10, both of which work w/telnet on 25.

SO...if your server sends mail out directly to the internet without relaying to your ISP's server, then it HAS to be able to telnet to port 25 on mail.theirdomain.com (the 10 MX.) However--once you get it working your server may still send to the higher-number MX for their domain because it's proven to itself that the other one doesn't work. (Restarting the server should fix this.)

Does your ISP configure the Sonicwall? If so, tell them to fix this. Assuming you can't hit port 25 on either server's MX address from the other server.

oh yeah the issue is complicated by the fact that ICMP (ping) is blocked to both addresses. Sux to troubleshoot stuff like that.

ASKER

Thanks. First of all, MY domain is the one with a 10 (my main MX) and the 90 (an emergency backup at my ISP). The new company that has moved in is the one with the "inbound" (old Network Solutions host that will be taken out in a few months) and the "home" which is their Exchange server. I manage my Sonicwall.

So that being said, you think THEY need to restart their server (Windows 2008 SBS) or I do? Since I manage my Sonicwall, you think all I need to do is to enable telnet for their public IP that points to "home"?

ASKER

Sounds like it's coming down to an issue on the Sonicwall between the two NAT policies........correct?

ASKER

Oh, and why can YOU telnet to my external server (mail.mydomain.com) 25, but I can't from home?

not telnet (port 23), but port 25 access to the public "home" address should do it.

ASKER

Please elaborate.......We've been telenting to portr 25...Maybe one of us made a typo?

Because your ISP is blocking it, or you have a firewall product in place on your machine?

I thought you said the one with the 90 was theirs? Do NSLOOKUP and SET TYPE=MX and type both domain names you'll see what I mean. I'm pretty sure your backup mail server at your ISP's doesn't work. :) Or theirs, whatever the one that is "inbound" doesn't seem to work.

The NAT has nothing to do with it. Your external IPs on the two networks don't seem to be talking to each other.

Enabling telnet has nothing to do with it, that's just the diagnostic. Since we can't PING, we're going straight to checking that the server is responding on port 25. The both do from here. If they each don't from the other server the ISP needs to fix routing so they do.

The reason I said you might need to restart your server (or flush DNS and/or restart Exchange services) is that your server has been sending to their backup MX and it will probably continue to do so for a while even after the problem is fixed unless you restart.

ASKER

Gotcha. I will restart my server tomorrow morning and report back. Thanks a TON for all your help.

ASKER

No firewall on the Exchange server, only the Sonicwall in front of it.

BTW wild guess: your two external IPs are only 3 different, one is .11 and the other is .14. Either they're subnetted incorrectly (most likely) on the sonicwall or someone made up a kind of dumb FW rule. Or they like that FW rule and have to make a higher-priority one to allow port 25. :)

NO, don't restart the Exchange server *until the problem is fixed and the servers can reach each other on port 25.* :)

ASKER

Arrrgghhhh!!! You're killing me now.
I (my company) has a block of 5 public IPs. We use the first three, and I gave this other company the next one to use.

Ah ok then the subnetting should be ok. Must be a dumb firewall rule. :)

ASKER

Well...I'm all ears, since any rules on the firewall were made by me, however it's a pretty dang Vanilla setup.

Well, two IPs on the same subnet should be able to talk to one another. :)

basically if you have any rules that say .11 can't talk to .14, that's the problem. So you can either nuke that/those rule(s) or make one that allows port 25 both ways that has a higher priority.

ASKER

Thanks. I'll report back tomorrow.

ASKER

Just a thought....If the two servers couldn't talk to each other, wouldn't either side get a quick NDR when trying to send mail to one another?

just commenting on your post at 10:30AM - you mentioned telnet, wanted to be sure you were doing so to port 25, not 23. looks like you are on the right track though.

That's what you'd think. :) Which is why I wanted to know WHERE the mail that their domain sent to yours IS...but actually no now that i think of it, if they COULD connect but could not negotiate you'd get a quick NDR. If the servers cannot connect they send to the backup MX. Which is where theirs went *but your backup MX is broken* :) If you look in their Exchange server's queues you'll see that it's still retrying to your domain, assuming that a temporary outage is in effect.

I don't know what has been going on with this question, I haven't read all of the posts.

However, there is a simple way to resolve this.
1. Ensure the servers can see each other on port 25. If they can...
2. Setup a new SMTP connector on each server. In the smart host section enter the internal IP address of the other server enclosed in [123.123.123.123]. Set the address space as their domain name (so on server 1 set the domain name of server 2 and vice versa). Set the cost to 1. Change the main SBS SMTP connector cost to 2.

The MX records will be ignored.

Almost certainly the reason why the higher cost MX record is being used is because the firewall doesn't allow the connection. Most firewalls will not allow traffic to come and come back in again on the same interface as a security measure - which is why you need to use the internal IP address so the traffic stays on the firewall.

Simon.

I knew you'd wake up sooner or later, Mestha. ;)

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

I haven't used the SonicWall, but unless it works in a very odd way, the routing should already be inside the device because it is a router.

Simon.

ASKER

Thanks, I'll try that today.

You get this straightened out?