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.

Advertisement