Components Required for External User Access
Topic Last Modified: 2012-10-17
Most Edge components are deployed in a perimeter network (also known as a DMZ, demilitarized zone, or screened subnet). The following components make up the edge topology of the perimeter network. Except where noted, the components are part of all three reference architectures and are in the perimeter network. Edge components include the following:
Edge Server(s)
Reverse proxy
Load balancing for Scaled Edge Topologies (either DNS load balancing or a hardware load balancer)
Firewall
Director (in internal network)
Edge Server
The Edge Server controls traffic across the firewall and usage of the internal deployment by external users. The Edge Server runs the following services:
Access Edge service The Access Edge service provides a single, trusted connection point for both outbound and inbound Session Initiation Protocol (SIP) traffic.
Web Conferencing Edge service The Web Conferencing Edge service enables external users to join meetings that are hosted on your internal Microsoft Lync Server 2010 deployment.
A/V Edge service The A/V Edge service makes audio, video, application sharing, and file transfer available to external users. Your users can add audio and video to meetings that include external participants, and they can share audio and video directly with an external user in point-to-point sessions. The A/V Edge service also provides support for desktop sharing and file transfer.
Authorized external users can access the Edge Servers in order to connect to your internal Lync Server deployment, but the Edge Servers do not provide any other access to the internal network.
Note
Edge servers are deployed to provide connections for enabled Lync clients and other edge servers (as in federation scenarios). They are not designed to allow connections from other end point client or server types. The XMPP Gateway server can be deployed to allow connections with configured XMPP partners. The Edge server and XMPP Gateway can only support end point connections from these client and federation types.
Reverse Proxy
A reverse proxy is a required infrastructure component for most scenarios that you enable as part of Microsoft Lync Server 2010. Most deployments use the existing reverse proxy that you have already installed and configured for use in your organization. Typically, there are new publishing rules that will be required and no change to your existing proxy server rules should be required. New or updated certificates are typical to handle the new publishing rules. Types of reverse proxies include, but are not limited to:
Microsoft Internet and Acceleration Server (ISA) 2006 with Service Pack 1
Configuration of a basic Microsoft Threat Management Gateway 2010 is used for the deployment example in Deploying Edge Servers. Microsoft Threat Management Gateway 2010 and Microsoft Internet and Acceleration Server (ISA) 2006 with Service Pack 1 are similar in how you configure publishing for Lync Server 2010. For details, see Configure Web Publishing Rules for a Single Internal Pool in the Deployment documentation.
Microsoft Threat Management Gateway (TMG) 2010
For details on how to configure Microsoft Threat Management Gateway (TMG) 2010 as a reverse proxy for your Lync Server 2010 deployment, see Configure Web Publishing Rules for a Single Internal Pool in the Deployment documentation.
Third party reverse proxy servers that can be configured to publish internal HTTP and HTTPS content
Third party firewalls that include the ability to publish internal HTTP and HTTPS content
Other devices and appliances not listed, such as hardware load balancers and HTTP content engine appliances may also be able to provide the required functions
For information on configuration of third party devices, servers and appliances, refer to the documentation from the third party vendor on how to configure publishing.
Important
Collocating the Edge Server and a reverse proxy is not a valid configuration option. The Edge Server must remain as a single purposed role to manage the session initiation protocol, Web conferencing and audio/video (as well as other media types) features for your deployment.
The reverse proxy is required for the following:
To allow users to connect to meetings or dial-in conferences using simple URLs
To enable external users to download meeting content
To enable external users to expand distribution groups
To allow the user to obtain a user-based certificate for client certificate based authentication
To enable remote users to download files from the Address Book Server or to submit queries to the Address Book Web Query service
To enable remote users to obtain updates to client and device software
To enable mobile devices to automatically discover Front End Servers offering mobility services
To enable push notifications to mobile devices from the Office 365 or Apple push notification services
Note
External users do not need a VPN connection to your organization in order to participate in Lync Server-based communications. External users who are connected to your organization’s internal network over a VPN bypass the reverse proxy.
Firewall
You can deploy your edge topology with only an external firewall or both external and internal firewalls. The reference architectures include two firewalls. Using two firewalls is the recommended approach because it ensures strict routing from one network edge to the other, and it protects your internal deployment behind two levels of firewall.
Director
In Lync Server 2010 a Director is a separate server role in Lync Server 2010 that does not home user accounts, or provide presence or conferencing services. Instead, it can serve as an internal next hop server to which an Edge Server routes inbound SIP traffic destined for internal servers. The Director authenticates inbound requests and redirects them to the user’s home pool or server.
If your organization is going to enable external access, we recommend that you deploy a Director. By authenticating inbound SIP traffic from remote users, the Director relieves Standard Edition servers and Front End Servers in Enterprise Edition Front End pools from the overhead of performing authentication of remote users. It also helps insulate Standard Edition servers and Front End Servers in Enterprise Edition Front End pools from malicious traffic such as denial-of-service (DoS) attacks. If the network is flooded with invalid external traffic in such an attack, this traffic ends at the Director, and internal users should not see any effect on performance. For details about the use of Directors, see Director.
Hardware Load Balancers
The Lync Server 2010 scaled consolidated Edge topology is optimized for DNS load balancing for new deployments federating primarily with other organizations using Lync Server 2010. If high availability is required for any of the following scenarios, a hardware load balancer must be used on Edge Server pools for the following:
Federation with organizations using Office Communications Server 2007 R2 or Office Communications Server 2007
Exchange UM for remote users
Connectivity to public IM users
To determine whether your hardware load balancer supports the necessary features required by Lync Server 2010, see "Lync Server 2010 Load Balancer Partners" at https://go.microsoft.com/fwlink/p/?LinkId=202452.
Hardware Load Balancer Requirements – General Considerations
Destination Network Address Translation (DNAT), which uses the incoming destination IP address of the virtual IP (VIP) of the load balancer, is converted to the destination IP address of the server. Your load balancer vendor may suggest using Source NAT (SNAT). Carefully consider which type of NAT you use, and be aware that this NAT is unique to the HLB and is a relationship between the HLB VIP and hosted servers. It is not the same as the NAT managed at perimeter firewalls.
Use Source affinity (also referred to as TCP affinity – check vendor documentation). All traffic within a single session should be associated with the same destination (i.e. server). In the event that there are multiple sessions from a single source, the sessions can be associated with different destination servers – using the source affinity to provide the session state.
Unless other information (performance needs, testing definitions, standards or vendor documentation) dictates, TCP Idle Timeout should be set to 30 mins (1800 secs.).
Warning
You cannot use DNS load balancing on one interface and hardware load balancing on another. You must use hardware load balancing on both interfaces or DNS load balancing for both. A combination is not supported.
Note
If you are using a hardware load balancer, the load balancer deployed for connections with the internal network must be configured to load-balance only the traffic to the Access Edge service and the A/V Edge service. It cannot load balance the traffic to the internal Web Conferencing Edge service.
Note
The direct server return (DSR) NAT is not supported with Lync Server 2010.
Hardware Load Balancer Requirements for Edge Servers Running the A/V Edge Service
Following are the hardware load balancer requirements for Edge Servers running the A/V Edge Service:
Turn off TCP nagling for both internal and external ports 443. Nagling is the process of combining several small packets into a single, larger packet for more efficient transmission.
Turn off TCP nagling for external port range 50,000 – 59,999.
Do not use NAT on the internal or external firewall.
The edge internal interface must be on a different network than the Edge Server external interface and routing between them must be disabled.
The external interface of the Edge Server running the A/V Edge Service must use publically routable IP addresses and no NAT or port translation on any of the edge external IP addresses.
Hardware Load Balancer Requirements for Web Services
Following are the hardware load balancer requirements for Director and Front End pool Web Services:
For external Web Services virtual IPs (VIPs), set cookie-based persistence on a per port basis for external ports 4443, 8080 on the hardware load balancer. For Lync Server 2010, cookie-based persistence means that multiple connections from a single client are always sent to one server to maintain session state. To configure cookie based persistence the load balancer must decrypt and re-encrypt SSL traffic. Therefore, any certificate assigned to the external Web Services FQDN must also be assigned the 4443 VIP of hard load balancer.
For internal Web Services VIPs, set Source_addr persistence (internal port 80, 443) on the hardware load balancer. For Lync Server 2010, Source_addr persistence means that multiple connections coming from a single IP address are always sent to one server to maintain session state.
Use TCP idle timeout of 1800 seconds.
On the firewall between the reverse proxy and the next hop pool’s hardware load balancer, create a rule to allow https: traffic on port 4443, from the reverse proxy to the hardware load balancer. The hardware load balancer must be configured to listen on ports 80, 443, and 4443.