Exchange Server 2016 and Microsoft Cloud (Part 5)

by [Published on 12 July 2016 / Last Updated on 12 July 2016]

Configuring the firewall and basic DNS to support the new environment.

If you would like to read the other parts in this article series please go to:

Introduction

So far in this series we built the domain controllers to support Exchange Server, after that we deployed the Exchange Servers, created high availability (DAG) at mailbox level, and also covered the components for high availability for the client access.

In this series, we are covering the deployment from scratch and because of that we will take a couple of additional steps related to the mail flow in Exchange Server. We will configure it to be as simple as possible and then we will be gradually increasing the complexity and integrating with Office 365.

In this article, we will be configuring the Firewall and prepare the Public DNS. In the second step we will configure all mail flow going straight to Exchange Server, and in the sequence we will move that flow to Office365/EOP (Exchange Online Protection). All those steps will provide enough guidance to the administrator to understand where his current environment is situated and how to move forward to the next level.

Configuring the Firewall…

Before working on the Public DNS, the administrator has to configure the Firewall to allow the traffic from the Internet to reach the Exchange Servers.

We will be starting with the scenario shown in Figure 01, and the first step is to discuss with the Firewall Administrator and assign a Public IP to be used by the Exchange Servers. Basically, we want all outbound traffic or at least SMTP traffic from Exchange Servers to be bound to the same Public IP when leaving the organization. A good security practice is to make sure that Exchange Servers are the only servers in the company to be able to connect on the port 25 on the Internet.

Now that we have a static Public IP reserved for Exchange outbound traffic (or at least SMTP), we must configure a reverse DNS for that IP. If you don’t have delegation of your reverse DNS, you can always contact your ISP and ask them to create one for you. In our scenario, we will be using smtp.infralab.org for that static Public IP that we defined in the previous step.

Image
Figure 01

The next step is to allow incoming traffic from the Internet to the Exchange Server(s). In our scenario depicted in the figure above, we have a load balancer which makes it easier on the Firewall side, all services being published on the external side must communicate with the VIP (Virtual IP Address) of the Load Balancer which will balance the request among the healthy Exchange Servers. If a load balancer is not an option, then the administrator can try to load balance the internal request at the Firewall level, or a more manual approach is to use one Exchange Server, and if that fails, change the rule to publish the remaining server (this last option should never be used in production).

In the Firewall, we should use the same Public IP for the incoming traffic, this way we have consistency at the IP level for all Exchange Server(s) in any given site. These are the basic rules that should be enabled on the Firewall to support our current environment:

  • Enable port 443 HTTPS (TCP) (you may want to enable 80 as well) to the Exchange Server(s)
    This rule will allow OWA, Outlook Anywhere and ActiveSync external end-points to communicate with Exchange Server
  • Enable port 25 SMTP (TCP). This rule allows external SMTP servers to communicate with Exchange Server and deliver messages

At this point, we need to create the SPF record to guarantee to the Internet that we are properly informing which servers are able to send messages for our domain. The author favorite choice to create an SPF record is the Microsoft SPF Record Wizard, however it was not available during the time this article was written, so another good option is using the http://www.spfwizard.net site.

After having the SPF created based on your requirements, you are required to create a TXT record on your Public DNS. We will be creating that on Microsoft Azure DNS (we will go over the DNS configuration in the next section) and add the information as shown in Figure 02. After creating the records, a good way to test it is using MXToolbox.com, the site even allows to test the SPF record information.

Image
Figure 02

We covered a lot of Firewall settings, and we also touched some of the DNS settings that will be added. Please, don’t worry about the DNS management, we will be covering those steps on the following article of this series.

In order to keep track of the changes required on either Firewall and Public DNS, the following table will summarize the basic steps and where it should be configured.

Task

DNS Entry Type

DNS Entry Name

Firewall Port

Define a static IP for Exchange Server

-

-

-

Allow SMTP on the Firewall

-

-

25 SMTP (TCP)

Allow HTTPS on the Firewall

-

-

443 HTTPS (TCP)

80 HTTP (TCP)*

Create SMTP host entry in the Public DNS

A Record

smtp.infralab.org

-

Configure Internet mail flow

MX Record

MX 10 smtp.infralab.org

25 SMTP

Configure autodiscover

A Record

webmail.infralab.org

443

Enable OWA, ActiveSync and Outlook Anywhere to external users

A Record

webmail.infralab.org

443

Configure reverse DNS for the Public IP used by Exchange Server(s)

PTR

smtp.infralab.org

-

Configure SPF Record

TXT record

http://www.spfwizard.net

-

Mail flow having only on-premises environment…

The portion to receive messages will be configured on the Public DNS where the MX record will point out to the Public IP on the Firewall that is already expecting 25 SMTP traffic.

The only missing component is to configure outbound mail flow on the Exchange Server(s), and these steps can be used to accomplish such task.

  1. Logged on the EAC as Exchange Administrator
  2. Click on Mail flow and then Send Connectors
  3. Click on Add (+)
  4. In the Create a send connector page. Label the new send connector, and select Internet, click Next (Figure 03).

Image
Figure 03

  1. In the following page of the wizard, leave default settings (MX record associated with recipient domain) and click Next
  2. In this page, click on + and on the new page, type * on the FullQualified Domain Name (FQDN) field, and click save. Back to the main page, the result should be similar to Figure 04.

Image
Figure 04

  1. In this page, add all Exchange Servers that will be able to send messages to the Internet, and then click on Finish.
    Note: It is really important that your firewall is configured to allow all servers that are listed on this page to send outbound messages using the pre-defined Public IP address.

Conclusion

In this article we went over the planning of external DNS servers (including SPF entry) and firewall configuration. In our next article of this series, we will be working on the fine tuning of the names that we planned at the beginning of this series on Exchange Server and Public DNS settings.

If you would like to read the other parts in this article series please go to:

See Also


The Author — Anderson Patricio

Anderson Patricio avatar

Anderson Patricio is a consultant for Microsoft technologies. He works with Exchange Server, ISA Sever and Active Directory deployments at a Microsoft Gold Partner in Toronto, Canada. In the Technet Brasil community, he contributes news, articles and webcasts.

Advertisement

Featured Links