2nd node of Exchange cluster cannot send external mail

[negaduck]

If a failover takes place, the second node of our Exchange cluster cannot send mail to any external recipients. The error message is: "There was a SMTP communication problem with the recipient's email server. Please contact your system administrator. <[virtual_server_fq_name] #5.5.0 smtp;553-you are trying to use me>

I would really appreciate some ideas.

 

[xmsre]

In exchange 2000 and 2003, when sending mail, it goes out over the real IP of the node, not the virtual IP of the SMTP virtual server. You'll need to do translation at the firewall for the IP of each node as well as that of the virtual server. For each, you'll need an A record and a PTR record in external DNS.


In very small designs with just a single cluster this can become an issue. In larger designs, you would want one or two unclustered SMTP bridgeheads in the routing goup. This will avoid the problem altogether.

 

[negaduck]

There is an external mail server (ISP). I was able to "telnet [servername] 25" without a problem. Does this mean anything?

 

[xmsre]

Let's say node 1 is 10.0.1.1 and node 2 is 10.0.1.2. The smtp virtual server is 10.0.1.3. On the firewall, the external interface is 172.16.1.1, and you've set up a virtual IP of 172.16.1.2 that NATs to your virtual server 10.0.1.3 on the inside. You have an mx record that points to "mail.domain.com" and "mail" has both an A record and a PTR record in DNS.


Inbound mail works fine. You can telnet to 172.16.1.2 which is translated to 10.0.1.3 and you get a connection. Outbound mail is where you will have a problem. You would expect the mail to originate on 10.0.1.3 and be translated to 172.16.1.2. This is not what happens on a cluster. The mail originates on 10.0.1.1 or 10.0.1.2 depending on which node is active. If you have not set up some static translation, either there is no rule on the firewall and it doesn't go out at all, or it goes out as the default external interface 172.16.1.1 for which there is no A and PTR record. Either way, it will fail.

 

[negaduck]

Many thanks for your help. Eventually we were able to pinpoint a configuration error regarding the IP address of the second node in a firewall which is managed externally.

Thanks again.