Highly Available Office 365 to On-Premises Mail Routing

Posted on Posted in 2010, 2013, cloud, DNS, EOP, exchange, exchange online, Exchange Online Protection, hybrid, IAmMEC, MX, Office 365, smarthost, smtp

This article looks at how to configure mail flow from Office 365 (via Exchange Online Protection – EOP) to your On Premises organization to ensure that it is highly available and work in disaster recovery scenarios with no impact. It is based on exactly the same principle to that which I blogged about in 2012: http://c7solutions.com/2012/05/highly-available-geo-redundancy-with-html on creating redundant outbound connections from Exchange on premises.

The best way to explain this feature is to describe it in the way of an example:

For example MCMEmail Ltd have Hybrid set up, and delivery to the cloud first. So the DNS zone for mcmemail.co.uk has MX pointing to EOP.

They then create a new DNS zone at either a subzone (as in this example) or a different domain if they have one available. In the example this could be hybrid.mcmemail.co.uk. Into this zone they add the following records:

10 MX oxford-a.hybrid.mcmemail.co.uk

10 MX oxford-b.hybrid.mcmemail.co.uk

20 MX nuneaton.hybrid.mcmemail.co.uk

The below picture shows an example of this configured in AWS Route 53 DNS (though there are other DNS providers available)

image

In Exchange Online Protection administration pages (Office 365 Portal > Exchange Admin > Mail Flow > Connectors and modify your on-premises connector to point to the new zone. Example shown in the below picture:

image

Then all email is always delivered to the Oxford datacentre and nothing to the Nuneaton one (where the DR servers reside) unless the two Oxford datacentres (A and B) are both offline and so the 10 preference does not answer at all. At that time and that time only does the 20 preference get connected to.

22 thoughts on “Highly Available Office 365 to On-Premises Mail Routing

  1. Does this also require that the ssl cert used for SMTP must contain all mx fqdn? So I need 3 external ip, 3 mx record & san cert with 4 fqdn?

    1. No. The certificate name is does not need to match the FQDN for SMTP. For the connectors you can specify the certificate CN value that must be presented by the server when Office 365 connects (Outbound Connector) or when you connect to Office 365 (Inbound Connector). If the certificate name is correct then the connection will work. This is the TlsCertificateName property of the connector. Note that TechNet says “The TlsCertificateName parameter specifies the X.509 certificate to use with TLS sessions and secure mail. Valid input for this parameter is [I]Issuer[S]Subject. The Issuer value is found in the certificate’s Issuer field, and the Subject value is found in the certificate’s Subject field”, but you can just use the subject name as well.

      If you do not specify TlsCertificateName then SMTP will use Opportunistic TLS, which means any certificate (valid or not) will work.

      1. Thanks Brian, all clear about the cert.
        Unfortunately external ips are scarce so not always applyable, but love your solution.
        On another note can we use a NLB or would a LB adjust the TLS SMTP as a smarthost would do ? And if we use LB we need to add its ip to the receive connector and we miss the source ip and see LB ip instead. How do you fix this?

          1. Hi Brian,
            Sorry to bother one more…
            I found this TechNet article also, they mention EOP drops if the FQDN is not on the cert/san.

            https://technet.microsoft.com/en-us/library/jj659055(v=exchg.150).aspx

            When using forced TLS transport, the sending and receiving servers examine the certificate configured on the other server. The subject name, or one of the subject alternative names (SANs), configured on the certificates must match the FQDN that an administrator has explicitly specified on the other server. For example, if EOP is configured to accept and secure messages sent from the mail.contoso.com FQDN, the sending on-premises Client Access or Edge Transport server must have an SSL certificate with mail.contoso.com in either the subject name or SAN. If this requirement isn’t met, the connection is refused by EOP.

            NoteNote:

            The FQDN used doesn’t need to match the email domain name of the recipients. The only requirement is that the FQDN in the certificate subject name or SAN must match the FQDN that the receiving or sending servers are configured to accept.

          2. You are not doing “Forced TLS Transport” for hybrid. The wizard sets the inbound connector with the string that it expects to find in the certificate and is nothing to do with the FQDN of the domain. Then when on-premises connects to EOP, EOP validates the certificate matches the string and if so lets you in

          3. Could not find that in any Microsoft documentation (about the fqdn not needed on cert), is it documented anywhere or a glitch in the Microsoft documentation πŸ™‚
            Is it advisable to put the HCW FQDN on the cert or do you consult/implement a certificate with only autodiscover and webmail.companyname.com on the certificate?

            So hybrid mail flow is Opportunistic TLS and not Forced TLS?

            Does this mean o365/connector checks the certificate string and if it’s on the on-prem connection it’s accepted and uses secure smtp? and does this secure smtp use port 25 or port 587 ?
            Do we need to publish/nat 25 and 587 on the firewall to the on-prem exchange servers?

          4. Hybrid mail flow is TCP 25 only. And you only need to publish the Exchange Servers you list in the hybrid wizard.

            Hybrid mail flow sets the TLSCertificateName property on the connector and will only deliver if the Send Connector on-premises TLSCertificateName value matches the certificate offered by the receive connector in EOP. The reverse is also true, the Outbound Connector in EOP needs to have the TLSCertificateName value set to the subject name of your on-premises certificate (as selected in the hybrid wizard).

            This is not Opportunistic TLS (which will downgrade to plain text if no certificate is offered [no STARTTLS]) or Forced TLS where the certificate must match the FQDN of the server. The FQDN of the server is irrelevant for hybrid mail flow.

          5. Cristal clear Brian!
            So you can even use a trusted 3rd party cert with a complete other fqdn then exchange uses cause the CN is used, interesting.

            Thanks for all your time, explanation & patience.
            Will you be attending/present on Ignite?
            If yes I’ll buy you a beer/pint πŸ™‚

          6. Hi Brian, you mentioned below – The reverse is also true, the Outbound Connector in EOP needs to have the TLSCertificateName value set to the subject name of your on-premises certificate (as selected in the hybrid wizard).

            I have set TlsCertificateName and have found that the receive connector (on Edge server) is still accepting mail from clients with no certificate. Any advice? was looking to restrict access to the valid certificate (along with IP restriction)

            Thanks
            Dave

          7. If you use just the IP restriction, which the hybrid wizard does in later versions of Exchange, then you dont need the certificate restriction as well

  2. Yes, you can use a load balancer. But unless you do “direct server return” feature of the load balancer you will see the IP of the load balancer. The DSR feature will be called different things in different makes of load balancer.
    A load balancer would not adjust the certificate (layer 4 load balancing), but would if layer 7 load balancing. Typically for SMTP you do layer 4 (TCP).

    1. Brian, interesting and also thanks for pointing that layer 7 LB breaks β€œX-MS-Exchange-Organization-AuthAs”.
      For sinlge external ip it’s best to go for layer 4 DSR
      It’s never easy in the Exchange world πŸ™‚

  3. SSL offload – no. MRS does not support offloading.
    Regarding X-MS-Exchange-Organization-AuthAs I did not say Layer 7 load balancers changed anything. The load balancer should pass the data through untouched after inspection.

  4. In Your previous post i read

    A load balancer would not adjust the certificate (layer 4 load balancing), but would if layer 7 load balancing.

    I understood ‘layer 4 not but layer 7 would’
    So neither layer 4 &7 will touch x header?
    Can we enable SSL offloading for ews but somehow leave SSL enabled for mrsproxy specific?

    1. X-Header and certificate are not the same thing. Layer 7 and the certificate is in the load balancer, layer 4 and it is not. Headers nit modified at all.

      SSL offloading – not unless your LB allows it with complex rules.

  5. Kuddo’s to you Brian. Again my big thanks. I need some load balancer schooling. Life as Exchange admin is though πŸ™‚
    Enjoy your weekend!

Leave a Reply

Your email address will not be published. Required fields are marked *