Emails from Messagelabs(Symantec) blocked after running HCW (Hybrid Configuration Wizard)

A couple of my customers have been running in to this issue lately, so I thought it was a good idea to share the issue with you guys.

Note: the issue only applies to those that are using Messagelabs/Symantec as their current spam-provider. (MX-record pointing to messagelabs)

Issue
After running Hybrid Configuration Wizard in Exchange 2010/2013 you experience intermittent issues with incoming emails from the internet (Messagelabs). If you dig further down to the issue you come to the conclusion that it only happens when you receive emails from certain ip subnets that Messagelabs are using.

Cause
As part of the Hybrid Configuration Wizard process, a receive connector named “Inbound from Office 365” is created. The purpose of that receive connector is to enable a secure mail flow directly from Office 365.
For that reason, the connector is configured with the setting RequireTLS set to True .
It also configures a set of remote ip ranges that the connector accepts (public Office 365 IP-ranges).

And it was here I came across the actual cause to this issue.
HCW are adding a remote ip range that overlaps with the public IP-ranges Messagelabs are using. This in combination with the fact that Messagelabs obviously doesn’t fully support TLS, makes this issue happen.
I confirmed this both with the transport logs and in Messagelabs documentation (http://images.messagelabs.com/EmailResources/ImplementationGuides/Subnet_IP.pdf).
The overlapping subnet is 67.219.240.0/20.

See screenshot from the Exchange Server and Symantecs documentation below:
2013-12-25 22-34-08

2013-12-25 22-34-55

Looking further into the documentation Microsoft have on this at http://help.outlook.com/en-us/140/gg263350.aspx, you find out that the subnet 67.219.240.0/20 isn’t there.
That is also confirmed by doing a whois on the subnet (http://www.whois.net/ip-address-lookup/67.219.240.0) – this subnet does not belong to Microsoft.

That means it should be perfectly safe to remove that subnet from the receive connector, and I can confirm that it hasn’t created any problems in the cases I bumped in to.

Solution(or workarounds…)
The quick and dirtly solution to this issue is to to turn off the TLS requirements on the receive connector “Inbound from Office 365” with the PowerShell command as below

Get-ReceiveConnector "Inbound from Office 365" | Set-ReceiveConnector -RequireTLS $false

The better solution is to just remove the subnets from the receive connector, and it should be perfectly safe to do this since no emails from Office 365 will arrive that way.

Hope this helps you out if you are running in to this issue!

/Johan

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s