Lync Edge and TMG server firewall requirements

​Installing a Lync server for a customer, and along with it a new TMG server as Reverse Proxy, I got a little reload on firewall requirements.

The customer did not have their perimeter set up as MSFT describes to be best practice, so that was also something to take care of in the process.

As the customer also was short on public IP addresses, the Edge was set up using only a single IP – discriminating services only through different ports on the external NIC. Documentation on this matter is a little scarce (see this article for some input), and since the TMG server is better off domain joined the official documentation​ on Lync falls short as to specify what firewall exceptions are needed for that.

Along with some other services one would like/need to implement, this is the summary I got for my implementation:

Outer perimeter/firewall:

Source Port Destination Port Proto Description
Any Any Edge public IP 443 TCP STUN – AV Edge Svc
Any Any Edge public IP 444 TCP PSOM – Edge Web Svc
Any Any Edge public IP 5061 TCP SIP – Access Edge Svc
Any Any Edge public IP 50.000-59.999 TCP RTP traffic
Any Any Edge public IP 3478 UDP STUN – AV Edge Svc
Any Any Edge public IP 50.000-59.999 UDP RTP traffic
Edge public IP Any Any 80 TCP CRL lookup
Edge public IP Any Any * 443 TCP CRL lookup / Windows Update
Edge public IP Any Any 5061 TCP SIP federation – Access Edge Svc
Edge public IP 50.000-59.999 Any Any TCP RTP traffic
Edge public IP Any Any 53 UDP DNS lookup
Edge public IP 3478 Any 3478 UDP STUN/TURN – AV Edge Svc
Edge public IP 50.000-59.999 Any Any UDP RTP traffic
Any Any TMG public IP 80 TCP Reverse Proxy Svc
Any Any TMG public IP 443 TCP Reverse Proxy Svc
TMG public IP Any Any 80 TCP CRL lookup
TMG public IP Any Any * 443 TCP CRL lookup / Windows Update
TMG public IP Any Any 53 UDP DNS lookup

One could choose (for Win Update Svc only) to allow for access to only *.update.microsoft.com and such sites).

Inner perimeter/firewall:

Source Port Destination Port Proto Description
Internal network * Any Edge private IP 443 TCP STUN – MRAS Svc
Lync Front End Any Edge private IP 4443 TCP HTTPS – CMS Replication Svc
Lync Front End Any Edge private IP 5061 TCP SIP traffic
Lync Front End Any Edge private IP 5062 TCP SIP – MRAS Svc
Lync Front End Any Edge private IP 8057 TCP PSOM – Edge Web Svc
Internal network * Any Edge private IP 3478 UDP STUN – MRAS Svc
Edge private IP Any AD CS server 80 TCP CRL lookup
Edge private IP Any Lync Front End 5061 TCP SIP traffic
TMG private IP Any AD CS server 80 TCP CRL lookup
TMG private IP Any Domain Controllers 88 TCP Kerberos traffic
TMG private IP Any Domain Controllers 135 TCP DCE/RPC traffic
TMG private IP Any Domain Controllers 389 TCP LDAP traffic
TMG private IP Any Domain Controllers 445 TCP AD DS/SMB traffic
TMG private IP Any Domain Controllers 3268 TCP LDAP traffic
TMG private IP Any Lync Front End 4443 TCP HTTPS traffic
TMG private IP Any DNS servers 53 UDP DNS lookup
TMG private IP Any Domain Controllers 135 UDP LDAP traffic
TMG private IP Any Domain Controllers 389 UDP LDAP traffic

As denoted by the asterisk (*) some ports are required for all internal network, that is all servers and clients that need external Lync connectivity.

One could of course both be less restrictive, allowing for more traffic through inner perimeter (network share access from Edge etc), but this I reckon is the minimum one would have to open for this kind of design to work.

One could also argue that the 50-60k range in/out for TCP and UDP is more than the minimum requirement from MSFT – which is true. Nevertheless, in federation scenarios any restrictions would cause lack of interoperability (vs OCS2007) or added load on Edge server(s) as traffic would have to be tunneled between respective Edge servers if client-client traffic is prohibited. Also, as an argument versus security/firewall administrators (who would probably be the only ones to object in the first place), ports in these ranges are only active when the Edge server make use of them (ICE setup) during media connectivity – they are NOT subject to any backdoor issues outside of this usage, even though packets may traverse the firewall and hit the Edge server.

Another option, regarding software updates, is of course to apply WSUS instead of Windows Update. In such a case internal perimeter need the same firewall exception, pointing to the address of the internal WSUS server. Note that the outer perimeter ports would still be required for other services such as CRL.

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