Many organizations that deploy Lync Server 2010 encounter voice quality issues associated with the usage of a client VPN solution in combination with Lync 2010. When users connect to the corporate network using a VPN client, Lync media traffic is sent through the VPN tunnel. This configuration can create additional latency and jitter because media traffic must pass through an additional layer of encryption and decryption. The issue is compounded when the VPN concentrator is busy. Real time media traffic is not prioritized. This means that other network activity, such as a large file transfer, can potentially degrade the call experience of users.

To provide users with the best possible media quality, organizations should deploy a solution that prevents time sensitive real time media (voice/video) from traversing the VPN and simultaneously allows standard corporate network traffic to traverse the VPN.  When considering this solution organizations should know the following:

• All Lync 2010 traffic is encrypted by default. SIP signaling traffic is encrypted using TLS, and all media traffic (audio, video and application sharing) is encrypted using SRTP. Because of this, Lync traffic does not need to be routed through encryption tunnels unless your organization specifically requires dual layer encryption.
• The Edge Server was designed to provide superb media quality to internet-based users. Because of this, media that relays through the Edge Server is typically more reliable and of higher quality than media, that traverses the corporate client VPN Solution.

Because end users typically require continuous VPN connectivity, it is not feasible for users to disconnect from the VPN before making or receiving Lync calls. The solution is to force Lync traffic around the client VPN, while allowing users to connect to other internal corporate resources. The solution encompasses the following areas:

• Create a split tunnel VPN configuration.
• Revise the Windows Firewall policy or corporate VPN firewall rules.
• Configure specialized DNS entries.

The Problem

Lync Server 2010 utilizes the Interactive Connectivity Establishment (ICE) protocol to establish media sessions between all Lync 2010 endpoints and servers. ICE attempts to establish media sessions between clients using all available ICE candidates on the client at the time of the call. Candidates are a combination of available IPv4 addresses and randomly allocated media ports on the machine with Lync 2010 installed. When a client VPN is connected, it often registers an IP address on a remote access interface on the client PC. Because of this, it is considered a valid IPv4 address; a candidate will be allocated for media connectivity to other clients. This is important because ICE tries candidates in the order shown below. When a media path is validated, the connectivity checks stop and the media is established.

1. UDP Direct- Physical (or virtual RAS) interfaces with IPv4 addresses assigned.

2. UDP NAT- Applies only when two users, who are outside the corporate firewall,are connected to the Lync infrastructure through the Edge Server. This scenario involves  trying connectivity through the reflexive IP addresses for each home user. The reflexive IP address is the public IP address of the home router.

3. UDP Relay- Between two external users or an external user and an internal user. This connectivity is relayed through the public IP address of the Audio/Video Edge service.

4. TCP Relay- The relay address (Audio/Video Edge Server public interface) when connectivity is not available on UDP. TCP Relay is a last resort.

When a Lync 2010 user is connected through VPN and attempts to call an internal Lync 2010 client, or tries to establish a media session with a Lync 2010 Server (Mediation Server, A/V Conferencing Server), the traffic attempts to pass through the VPN interface and is considered a UDP Direct candidate. If this connectivity check succeeds, the media traverses the client VPN solution.

Figure 1. Lync 2010 Call Process through VPN- The Problem

This scenario is a common default configuration issue. The requirements below define a solution that forces Lync client traffic through the Lync Edge Server (UDP Relay candidates).

For more details on how ICE works for all Lync 2010 scenarios, see the Lync 2010 Resource Kit External User Access Chapter.

Solution Configuration

The solution to force VPN traffic through the Edge Servers must allow external Lync clients connected through VPN to do the following:

1. Connect to corporate and external resources (split-tunnel).

2. Resolve external DNS entries for the Lync Edge services, Lync Web Services and Exchange Web Services.

3. Register through the Lync Access Edge service.

4. Block connectivity from VPN connected Lync 2010 clients to all Lync Servers and all internal client subnets through the VPN tunnel. In our example, we used Windows Firewall to block this traffic. You can achieve similar results, however, if your VPN appliance has detailed rules to firewall client VPN traffic.

5.Allow VPN connected clients to establish media through the A/V Edge Server public interface.

Split-Tunnel VPN Policy 

To allow Lync traffic to reach the public IPs of all services, the VPN appliance must be configured to allow a split-tunnel.  A split-tunnel is a VPN connection that allows connections intended for internal resources to traverse the VPN. All other user requests are sent through the internet connection and bypass the corporate network.  For more information on spilt-tunnel VPNs read Split tunneling.

In most split-tunnel VPN scenarios, DNS is provided by an internal DNS server. The server needs to be configured as described in the section later in the article Specialized DNS entries.

Windows Firewall Policy

  

The above rules, used in conjunction with the remaining configurations, allow you to force Lync 2010 traffic to relay through the Edge Server.

As mentioned above, all Windows Firewall configurations shown here are created using the local Windows Firewall Snap-In.

Windows Firewall Policy Configuration Steps

To begin, create a new inbound rule for the Lync application (Communicator.exe).This rule needs to be a  Custom rule. See Figure 2 below.

Figure 4. Default Configuration for Protocol and Ports

Figure 5.VPN subnet defined as the local IP, VPN and corporate subnets defined as remote subnets.

Figure 7.Blocking configured to prevent connections from utilizing VPN based IP address

Specialized DNS Entries

Simple URLs

Just like SIP traffic, you must block all https pool traffic from entering the VPN.  All URLs defined for simple URLs and pool web services (including external web services FQDNs) must return a public IP address routed outside of the VPN tunnel.

Example:

Table 3. Example Simple URL DNS Entries

  

Figure 11.Lync client media bypassing the corporate VPN with windows firewall configuration

Ref Articles:

Information on A/V Edge Ports and Public IP Addresses

OCS 2007 R2: What’s new for Media Traversal?

 By Kevin Peters and Randy Wintle

If you are using a hardware load balancer, it will perform periodic health checks for Lync to make sure it is distributing the load evenly to all servers that are functional. Because of the checks, you may end up with a large number of protocol errors in your FE logs showing a connection error with the VIP IP from the load balancer or one of its SNAT addresses. Here is an example of the error:

Source: LS Protocol Stack
Event ID: 14502
Level: Error
A significant number of connection failures have occurred with remote server IP 10.255.106.202. There have been 120 failures in the last 180 minutes. There have been a total of 291 failures.
The specific failure types and their counts are identified below.
Instance count   - Failure Type
291                 0x80072746(WSAECONNRESET)

This can be due to credential issues, DNS, firewalls or proxies. The specific failure types above should identify the problem.

Notice in the error, the IP of my VIP is listed (10.255.106.202).

Although these are expected, if you have not specified a Hardware Load Balancing (HLB) monitoring port, they certainly cause an awful lot of unwanted noise in the logs. 

To combat the issue, enable an HLB port on your FE servers (or any other pool you are using HLB on) and configure the health checks for the load balancer to use that port instead of the port used for TLS traffic. For more information on this blog, go here.

By Kevin Peters 

While working with a client, we ran into two front-end servers and an edge server that would not replicate. The CMS was hosted in another country with plenty of firewalls in between, which definitely complicated the issue.  However, the root cause wasn’t a network issue or firewall.

We started by tackling the front-end servers. Two out of four front-end servers in a pool were showing out of date in the topology.  From the server hosting the CMS I verified I could ping each front-end server by name and to my surprise I could also telnet to them on port 445. 

Now that we knew the path used to connect was valid and the server was listening for the connection, I started a packet capture using NetMon, and ran the invoke-csmanagementstorereplication CMDlet to kick off replication. I captured data for 30 seconds and applied a Display Filter so I could look at the SMB traffic first.

There was “Access Denied” all over the logs. I tried to view the properties of the RTCReplicaRoot folder (by default this folder is on the root of the drive Lync is installed on), but didn’t have permission. Although this would seem like an error, it is actually expected behavior and it is best not to modify permissions to this directory. I discussed the build process with the client and determined a security script meant to tighten NTFS permissions had inadvertently broken CMS replication for those two servers. Instead of trying to fix the NTFS issue and risking other problems, we removed the boxes from the topology, re-installed the OS, and added them back as Lync servers after a clean rebuild without the security script. For more information on this blog, go here

By Kevin Peters