Many organizations utilize Virtual Private Networks (VPNs) to secure traffic when users are outside the corporate network. VPNs have numerous security benefits, but they can actually degrade the call experience for Microsoft Lync users. This occurs because Lync traffic is already secured. This article explores this common Lync Server 2010 deployment issue, and demonstrates how to utilize the existing infrastructure to redirect media traffic to bypass the corporate client VPN Solution. This solution maintains a secure environment and improves the Lync 2010 user experience.
Authors: Kevin Peters, Randy Wintle
Publication date: November 15, 2011
Product version: Lync Server 2010
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:
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:
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.
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.
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 later in this article in the section Specialized DNS entries.
It is critical that all public IP addresses used for the Lync and Exchange environments are excluded from entering the VPN tunnel. A tunnel-all VPN policy does not allow traffic to bypass the tunnel and does not work with this solution.
Configuration of the VPN appliance is considered out of scope for this document; please consult your VPN appliance vendors’ documentation for more information on configuration recommendations.
Administrators can create a custom Windows Firewall rule set to prevent Lync client traffic from entering the VPN. There are multiple options to push this policy, but this article will use the Windows Firewall snap-in to create the rules. Using group policy, administrators can follow the same configuration tasks. Deploying rules through group policy scales well in larger environments. For the scenario described below, we assume the following:
Note: If you are not using Windows Firewall, but want to deploy firewall rules through your VPN appliance, consider the following rules:
Table 1. Firewall Rules to Block Lync Traffic over VPN
Client VPN Subnets
Corporate VPN network
1024-65535 TCP/UDP (this is by default; however these port ranges are configurable. See the QoS Deployment Guide for more details.
Lync 2010 client media traffic to all other internal clients.
All Lync Servers, including the Edge Server internal interface
All Ports TCP/UDP
Lync 2010 client traffic to Lync Servers, all should be blocked.
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.
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 2. New Inbound Rule Type Custom
Next, specify the executable for Lync or Communicator (Communicator.exe) as shown in Figure 3. Although this article only covers the Lync client, the same principles can be applied to other applications such as Microsoft Office Live Meeting 2007 or the Microsoft Lync 2010 Attendee.
Figure 3. Communicator.exe specified as the program path
For protocols and ports, leave the default settings as shown in Figure 4. This blocks all ports and all protocols.
Figure 4. Default Configuration for Protocol and Ports
To scope, define the VPN subnet in the Which local IP addresses does this rule apply to box, and the corporate and VPN subnets in the Which remote IP addresses does this rule apply to box. See Figure 5. Defining the VPN subnet in the remote IP address field prevents hair-pinning. Hair-pinning occurs when traffic enters and leaves the same interface on a network device, such as a VPN concentrator. Blocking hair-pinning prevents two VPN based users, from sending their peer to peer media traffic through the VPN tunnel.
Figure 5. VPN subnet defined as the local IP, VPN and corporate subnets defined as remote subnets.
When in the Scope section, customize the interface type to include only Remote Access. See Figure 6. This prevents the configuration from being applied when not connected to the corporate VPN.
Figure 6. Custom Interface Type of Remote Access selected
For action, choose block as shown in Figure 7.
Figure 7. Blocking configured to prevent connections from utilizing VPN based IP address
In the Profile screen select Domain. See Figure 8. This ensures the settings are only applied when connected to the users’ corporate Active Directory domain. This setting cannot be used for machines that are not joined to the domain. This setting keeps the configuration from being applied when connected to VPN networks other than the users’ corporate connection with the same network numbering.
Figure 8. Network profile type of Domain
Give the rule a meaningful name and description see Figure 9.
Figure 9. Configure the name of your rule and provide a description
After creating the inbound rule, create an outbound rule with the same configuration.
Because connections to all internal IP addresses are blocked, you must provide valid DNS entries that resolve public IP addresses in response to queries from the Lync client. To achieve this use a dedicated DNS server, with pin point zones as explained in the article Communicator Automatic Configuration and Split-Brain DNS.
The Lync client makes connections to the following resources. You need to provide the public IP addresses back for those requests:
Lync Edge Services
To force the Lync client traffic around the VPN, the public IP addresses for all three Edge services must be returned to the Lync client when it makes a query. This allows the Lync client to connect to the Access Edge as an external client. This is required because users must register as external to obtain proper Media Relay Authentication Server (MRAS) credentials. For more details on MRAS, see Microsoft Lync Server 2010 Resource Kit: External User Access.
Table 2. Example Edge Server DNS Entries
Access Edge interface
Auto Login SRV record for clients
Web Conferencing Edge Server
A/V Edge Server
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.
Table 3. Example Simple URL DNS Entries
Pool external web services
Meeting join page
Dial-In conferencing settings page
Exchange Web Services
Because you are blocking the Lync client from reaching any internal subnets, you must ensure that all Exchange services are reached through their public IP addresses.
Table 4. Example Exchange Web Services DNS Entries
Exchange Auto Discover
Exchange Web Services/Outlook Web Access
When these changes are implemented, the Lync client will connect to the Access Edge Server for all signaling connections when on the corporate VPN (see Figure 10). In addition, media sessions will not be allowed to establish connectivity through the VPN tunnel. Media sessions will be routed through the A/V Edge Server public interface (see Figure 11).
Figure 10. Lync client signaling bypassing the corporate VPN with windows firewall configuration
Figure 11. Lync client media bypassing the corporate VPN with windows firewall configuration
Keywords: Lync, VPN, ICE, Lync Edge Server, Windows Firewall, Virtual Private Network
NICE! Good work, Randy, Kevin. Good to see that this is FIANLLY documented and I can leverage this in the current and next iteration of the Edge docs.
Very creative solution! Cool article, guys.
Good article! I second Rick, finally this was documented on an authoritative blog!
Nice Job. This is an effective resolution to a voice quality problem for our remote users connecting with VPN. The solution works well. We are piloting this now and plan to deploy soon.
Nice article guys!
Your blog is very Informative.
Finally, this has been properly documented. I have to start testing it, and if works, becomes part of my implementation best practices list. Good job!
I am confused, I already have an internal DNS entry for "Sip.contoso.com" pointing to an internal address, this suggests resolving it to the edge interface. What will happen to internal users?
Same goes for meet and dialin, I already have these registered on internal DNS using internal IP's.
You would want to use a separate DNS server for VPN clients, so public IPs are provided to the VPN users (bypassing the tunnel), but internal IPs are still provided to your internal users. This could not be done from the same DNS server, so you'd need to create at least one, specifically for serving the VPN connections.
Nice article, keep it up good work, kevin and randy!
does link media bypass <a href="bestvpnservice.com/.../strong_vpn.html">strong vpn</a>?
Has anyone that implemented this noticed that the Lync client takes a long time to login when on VPN? Just a nusance, otherwise this solution rocks! Users "Internal" flag is set to fale when on VPN and traffic is routing over the Internet tunnel exclusively - excelelnt article!
I have one question for you though. If I was to give my VPN users a separate DHCP pool, could I implement the firewall rules on the Lync server side rather than the client side? It would be a gigantic undertaking to modify all of my mobile users windows firewalls to make the suggested change. My thought is to block the VPN IP Subnet on the servers themselves so that the client would be forced to look at the edge for connectivity. Thoughts?
If you block the traffic on the server side there is still the possibility of Peer to Peer connectivity (from one Lync client to another) over the tunnel. So unless you also block internal client subnets from reaching VPN subnets that wouldn't resolve the problem for all media flows.
Hope this helps!
Agreed with the others, great article.
For the pinpoint DNS server, I simply installed the 'DNS' role on my Lync Front-ends. Then I modified my Cisco ASA VPN Clients to use the FrontEnd servers for DNS. Any DNS entries that the Front Ends do not have entries for, they forward them on to our corporate DNS servers where everything works normally.
Also, the Cisco AnyConnect VPN client allows you to define certain IPs to route OUTSIDE the VPN tunnel. Very helpful. Then in the ASA configuration, you can setup ACLs to block certain traffic to your Lync servers. Make sure you allow port 53 traffic from your VPN users to the Lync Front Ends if you are going to use the Lync server as your pinpoint DNS server. It still needs to do DNS lookups, even though you do not want the VPN users accessing any services directly off the front-end.