First published on TECHNET on Nov 14, 2011
NOTE : As part of the Skype Operations Framework , Microsoft has released practical guidance on how to implement VPN Split Tunnel for Skype for Business Online. You can download the document here .
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:
NOTE : As part of the Skype Operations Framework , Microsoft has released practical guidance on how to implement VPN Split Tunnel for Skype for Business Online. You can download the document here .
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
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 .
Example:
Table 2. Example Edge Server 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
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.
Example:
Table 4. Example Exchange Web Services DNS Entries
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
NOTE : As part of the Skype Operations Framework , Microsoft has released practical guidance on how to implement VPN Split Tunnel for Skype for Business Online. You can download the document here .
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:
- 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:
NOTE : As part of the Skype Operations Framework , Microsoft has released practical guidance on how to implement VPN Split Tunnel for Skype for Business Online. You can download the document here .
- 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 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.
Windows Firewall Policy
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:
- Corporate subnets all fall within the 10.0.0.0/8 range.
- VPN subnet is 172.16.1.0/8.
- A Connection type of Remote Access is shown in windows when VPN is connected.
- A Network type of Domain is shown in windows when connected to the VPN.
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
| Source | Destination | Port | Description |
| 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. |
| Client VPN Subnets | 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.
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 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.
Specialized DNS Entries
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 Server services (Access Edge, Web Conferencing Edge, and Audio/Video Edge).
- Simple URLs (reachable through the reverse proxy).
- Exchange Web Services (EWS), Autodiscover service and all other client connectivity.
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 .
Example:
Table 2. Example Edge Server DNS Entries
| Record | Resolves to | Description |
| Sip.contoso.com | 167.55.49.32 | Access Edge interface |
| _sip._tls.contoso.com | Sip.contoso.com:443 | Auto Login SRV record for clients |
| Web.contoso.com | 167.55.49.33 | Web Conferencing Edge Server |
| Av.contoso.com | 167.55.49.34 | A/V Edge Server |
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
| Record | Resolves to | Description |
| Web-external.contoso.com | 167.55.49.35 | Pool external web services |
| Meet.contoso.com | 167.55.49.35 | Meeting join page |
| Dialin.contoso.com | 167.55.49.35 | 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.
Example:
Table 4. Example Exchange Web Services DNS Entries
| Record | Resolves to | Description |
| autodiscover.contoso.com | 167.55.49.36 | Exchange Auto Discover |
| owa.contoso.com | 167.55.49.36 | Exchange Web Services/Outlook Web Access |
Summary
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
Reference Articles
Lync Server Resources
- Lync Server 2010 documentation in the TechNet Library
- DrRez blog
- Lync Server and Communications Server resources
We Want to Hear from You
Keywords : Lync, VPN, ICE, Lync Edge Server, Windows Firewall, Virtual Private Network
Updated May 20, 2019
Version 2.0
