Unable to Receive E-Mails from the Internet using E-Mail Protection feature on Forefront TMG 2010

  • Article

Introduction

E-Mail Protection feature on TMG is one of the features that allows TMG to leverage other resources available in the environment. In this case, TMG uses Exchange Edge technology as well as Forefront Protection for Exchange. Before start reading this post, make sure to get familiarized with E-Mail Protection feature on TMG by reading the following articles (in this order):

This post is about an issue where after following those steps to configure E-Mail Protection on TMG, e-mails coming from the Internet were getting stuck on Exchange Edge Queue with the error code 4.7.0.

Troubleshooting

The SMTP error 4.7.0 translates to “temporary authentication failure”, which means that Exchange Edge is having problems to authenticate to the internal email server (in this case an Exchange Hub). Notice that this is pure an Exchange issue, however since TMG is the one responsible for configuring the parameters for Exchange Edge, the initial troubleshooting starts by reviewing the configuration on TMG side.

As of now (TMG 2010 RTM or with SP1) requires that all configuration must be done via TMG UI, if changes are made directly to Exchange Edge or Forefront Protection for Exchange, you will notice that the following alert will appear on TMG and the configuration that was changed on those products will be replaced by the one present on Forefront TMG.

Ig0 
Figure 1

Since we are dealing with authentication issue (remember SMTP code 4.7.0) the first thing to review is the authentication method that was configured to allow Exchange Edge to talk to the internal mail server. To do that on TMG, follow the steps below:

1. Open TMG Console, go to E-Mail Policy, right click on the Internal SMTP Route and choose Properties.

Fig2 
Figure 2

2. On the Internal_Mail_Server Properties click Routing tab and click Advanced button.

3. The Advanced window appears as shown below. Make sure to take note of the authentication method used in this option, you will need to match it up with the authentication used by the internal mail server.

Fig3 
Figure 3

4. Click OK twice.

Now that you know which authentication method is used on Exchange Edge (configured by TMG), you need to verify which authentication method is in use by the internal mail server, which in this case is an Exchange Hub. To verify that follow the steps below on Exchange Hub:

1. Open Exchange Management Console.

2. Click Server Configuration and click Hub Transport.

3. Right click on the Receive Connector, choose Properties and the general information for this connector will appear as shown below:

Fig5 
Figure 4

4. Click Authentication tab and make sure that the authentication matches with the one specified on Exchange Edge, which in this case is matching as you can see below:

Fig6 
Figure 5

For this particular scenario the authentication was matching, so what could be going wrong to receive the 4.7.0? When troubleshooting issues of this nature one simple test that you can do is to try to telnet the IP of the internal mail server from TMG command prompt on port 25 and the name that appears on the SMTP header as shown below:

Fig4 
Figure 6

Notice that the name in there is relay.contoso.com, which doesn’t match with the receive connector that we previously verified on Exchange Hub (Figure 4), which is excsrv.contoso.com.

Conclusion

The reason why this issue was happening was because when Exchange Edge was trying to communicate with the internal Exchange Hub, the receive connector that was processing the message was not the default one; it was another one that had a different authentication method. The reason why the other connector was processing the message instead of the default connector was because this custom connector had an IP range more specific than the default connector as shown below:

Fig7 
Figure 7

When you have multiple connectors on Exchange, the one that will process the message is the one that has the IP range definition closer to the source IP (in this case TMG was 10.20.20.1) that is trying to connect to the connector. To fix this issue we changed the authentication method of this connector to match with what we have on Exchange Edge. Once this was done all the message that were accumulated on Exchange Edge Queue started to correctly flow.

Author
Yuri Diogenes
Sr Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Ed Bringas
Sr Support Escalation Engineer
Microsoft Exchange CSI Team