Firewall Configuration in EPiServer CMS
EPiServer CMS 4.62
Document creation date:
Document last saved:
This technical note describes how to configure and set up firewalls that will carry traffic between different servers used by EPiServer CMS.
Table of Contents
Using DNS for Name ResolutionAuthentication against LDAP Authentication against Windows Domain Using Microsoft SQL Server
This is a worst-case scenario, where a firewall separates the EPiServer CMS Web server from all other servers that we want to communicate with. It might not be a realistic example, but it illustrates all the firewall configurations that may be required. Note that the arrows are drawn so as to illustrate the source (arrow tail) and destinations (arrow head) as described in the text.
Using DNS for Name Resolution
If any of the servers that you are communicating with is referenced with the DNS name rather than the server's IP address, you need to allow for DNS communication from the EPiServer CMS Web server to the DNS server. Open for DNS according to the DNS service description below.
Authentication against LDAP
If you are authenticating with forms-based logon, you only need to open for the LDAP service (see below) from EPiServer CMS Web server to the LDAP server.
Note If you enter the LDAP server name as an IP address, you do not need to open up for DNS name resolution. In an Active Directory configuration, you may receive several server references when asking for an LDAP server. Be sure to allow for LDAP communication to all those servers.
If you are using Windows Integrated logon (which may be combined with LDAP authorization in an Active Directory scenario), you will also need to open the firewall as described in Authentication against Windows Domain.
Authentication against Windows Domain
When using Windows Integrated logon for authentication, the EPiServer CMS Web server needs to communicate with a Windows Domain Controller, unless you are logging on with a Windows account that is local to the Web server. Open the firewall for Windows Authentication as described below.
Using Microsoft SQL Server
When using Microsoft SQL Server installed on a separate server, you need to allow for TDS communication. Open the firewall for SQL Server communication as described in Service Definitions below.
Using Oracle Database Server
When using Oracle Database Server, you need to open the firewall according to the Oracle server definition below.
The following definitions of the different services have been used during our testing.
- TCP, source port 1024-65535, destination port 389
- TCP, source port 1024-65535, destination port 53
- UDP, source port 53-65535, destination port 53
- TCP, source port 1024-65535, destination port 1433
Note that the destination port may vary depending on the installation, but the default is 1433.
- TCP, source port 1024-65535, destination port 1793
Note that the destination port may vary depending on the installation, but the default is 1793.
Note that the Windows Domain Authentication scheme relies heavily on SMB traffic and also does dynamic end-point mapping. This makes it necessary to open up a lot of ports/traffic in a firewall to allow Windows Authentication to work properly.
- TCP, source port 1024-65535, destination port 135
UDP, source port 1024-65535, destination port 135
This is the DCE end-point mapper, which strictly speaking should not be needed for authentication, but you will experience intermittent problems if it is not allowed.
- TCP, source port 1024-65535, destination port 137
UDP, source port 1024-65535, destination port 137
This is the NetBIOS Name Service.
- UDP, source port 1024-65535, destination port 138
This is the NetBIOS Datagram Service.
- TCP, source port 1024-65535, destination port 139
This is the NetBIOS Session Setup Service.
- TCP, source port 1024-65535, destination port 1024-65535
This is needed for the dynamic end-point mapping as mentioned above