Every Microsoft product is very complex in itself, depending on the role and functionality there are different communication channels and protocols which communicate with each other.
The same is also true for Exchange. Although Exchange has been rolled out again as a multirole system since the 2013 version, we are thinking back briefly to the time with Exchange 2010, where we were able to install the CAS, hub and mailbox role in a dedicated way.
In addition to the internal communication of Microsoft Exchange, there are also other communications on the network layer between Exchange and surrounding systems such as Microsoft Edge, Active Directory, and UM solutions.
Depending on the complexity of an infrastructure it can be very important which ports have to be open between which destinations and also which protocols are used.
Here is a brief overview of the ports and services used that are relevant for Microsoft Exchange:
|3268||Microsoft Global Catalog|
|3343||MS Cluster Net|
|5061||SIP (over TLS)|
|5075||Skype for Business Server Call Park service|
|5076||Skype for Business Server Audio Test service|
At this point it is important to note that not all ports have to be used. Depending on the configuration and third-party solutions used, the ports to be used may be different.
To make the whole logic of Microsoft Exchange ports and services a bit clearer, I have created the following diagram:
As we can see on the picture all services are separated. This does not mean that everything has to be built separately. As mentioned earlier in this article, on-premise Exchange infrastructures are no longer built as separate functional roles, they are now multirole.
The graphic should illustrate the communication between them.
Another example here is port 3343 between the two mailbox servers, this port (UDP) is needed for the Microsoft Cluster Net. However, if it is not built as shown in the picture or if it is a single server. We don’t have to pay attention to this in a standard configuration.
As last point I would like to add that this is an on-premsie instance. If you are using Exchange online, this article “Nice to know” is of only limited importance for you.
In any case, it helps you to plan and discuss it with the firewall engineer.
I am aware that there are still some points missing in this article, so I will write another article on this topic in the near future, dealing with the Exchange Hybrid and Hub Transport topics as well.