Skype for Business Client and VPN Connection Problems

Skype for Business Client and VPN Connection Problems

Reading 1 Comment




This article documents VPN Lync connection problems.  The research troubleshoots Skype for Business clients on a VPN, that connect to external Lync clients.  The full article explains traffic flow for both Lync servers and Lync clients.

   *Update 12/6/2016:  Bypass the VPN using NRTP and Firewall GPOs.      

Problem Statement: 

     Skype for Business audio and video (AV) does not work between an internal-to-external call between the branch office VPN and staff working from home.
 
Problem Symptoms:
  • Instant messaging (IM) works between the VPN branch office and external users. 
  •  VPN Lync clients are unable to establish conference calls to external users. 
  • The problem only occurs between the VPN branch office and external users. 

o   External Lync clients successfully establish individual audio and video calls to clients at the data center. 
o   Lync clients on the VPN successfully establish individual audio and video calls to Lync clients at the data center. 
Audio and video calls work between VPN clients and external clients when both connect to a conference established by a data center Lync client.
Take Away: 

     The communication problem between VPN clients and external clients result from a missing persistent route to the branch office’s subnet.  The Access Edge server resides between the DMZ and the Perimeter network.  The Access Edge has a gateway on the DMZ interface.  The gateway is not configured on the Perimeter interface for traffic restriction purposes.  The Access Edge server is configured to communicate with the data center subnet.  There is not a persistent route that forwards traffic to the VPN branch office subnet.

Available Solutions:
  1. Add a persistent route that forwards to the branch office subnet on the Access Edge server’s local route table.  This is a quick fix (see next solution).
  2. VPN tunnels add unnecessary packet overhead that introduce jitter and network latency.  Pushing external AV traffic can also saturate available VPN bandwidth.  Microsoft recommends branch offices bypass the VPN tunnel and instead connect through the outside Access Edge server as external clients.
    http://download.microsoft.com/download/F/0/C/F0C2688A-2C1C-4005-9DF5-0645A9F273F1/Networking_Guide_Lync_Server.docx
  3. Deploy an additional Reverse Proxy and AV edge server at remote site.  There is no additional Lync licensing for this solution.  The servers require additional Windows licenses and may operate on physical or virtual servers.
    http://technet.microsoft.com/en-us/library/bb803631(v=office.12).aspx     

 Explanation:

Topology:


  • Branch office VPN is split-tunnel.  All Internet traffic exits local gateway.  All company traffic uses the VPN.
  • Branch office subnet is not restricted.  VPN provides access to all internal resources.   

2 Instant messaging.  

          The Front End Server provides most Lync server functionality.  Instant messaging (IM) provides text-based messages. Both two-party and multiparty IM sessions are supported.  A participant in a two-party IM conversation can add a third participant to the conversation at any time. When this happens, the Conversation window changes to support conferencing features.

      Lync clients send and receive instant messages using Instant Messaging Multipoint control unit (IMMCU).  IMMCU is a Lync Front End service that provides instant message communication between Lync clients.  Peer-to-peer communication (and multi-party IM) is only possible when the Lync server and IMMCU is active and available.

http://technet.microsoft.com/en-us/library/gg398109.aspx



      Lync clients use SIP and TLS TCP protocols to communicate.  Lync server-to-server communication use SIP and MTLS protocols.   External Lync clients communicate from a dynamic source port.  The external traffic is received on inbound port 443 on the public interface of the Lync Access Edge server.  Access Edge forwards the packets to the Lync Front End server from its internal interface using SIP/MTLS:5061.  Lync Front End receives then delivers packets through the LAN (and VPN) to the branch office client using SIP.MTLS:5061.  http://technet.microsoft.com/en-us/magazine/hh272676.aspx

     Lync client communication is often referred to as peer-to-peer.  Technically, the two clients communicate in a one to one conversation, with the Instant Messaging multipoint control unit (IMMCU) in the middle. The IMMCU is a component of Front End Server. Placing the IMMCU in the required communication workflow allows call detail recording and other features that the Front End Server enables. Communication is from a dynamic source port on the client to the Front End Server port TLS/TCP/5061 (assuming the use of the recommended transport layer security). By design, peer-to-peer communication (as well as multi-party IM) is possible only when Lync Front End server and the IMMCU is active and available.
|http://technet.microsoft.com/en-us/library/gg398109.aspx


IM Traffic Flow:


      *The missing persistent route on the Access Edge prevents AV communication on the internal interface to the VPN branch office.  IMs continue to work between the VPN and external clients because IMs are sent to-and-from the Front End server; not the Access Edge.

Lync Audio Video (AV).

     Lync clients communicate differently from IM when using AV services.  Clients prefer to communicate via peer-to-peer.   Internal and external clients use the Interactive Connectivity Establishment (ICE) RFC 5245 framework to determine the most direct path between endpoints.  Benefits of peer-to-peer transmission include:

·         Improved media quality.

·         Improved network load.

·         Removes processing and memory loads off Front-End server.

·         Access Edge design serves fraction of total network users. 

     ICE  uses 2 protocols to determine the network path between Lync clients.  Session Traversal Utilities for NAT (STUN) reflects Lync client’s NAT IP and public IP.  The process provides IP topology to promote network path candidates.  Traversal Using Relay NAT (TURN) allocates media ports on the external AV edge interface.  The key difference between STUN and TURN is that media travels directly between both endpoints when STUN is used, and media is proxied through the Access Edge server when TURN is used. http://blog.schertz.name/2012/10/lync-edge-stun-turn/.   


     Candidates consist of an IP address and available UDP or TCP port.  ICE considers all potential network paths as candidates.  The ICE framework uses the following preferred hierarchy to promote candidates:

 1.        UDP Direct.  UPD direct occurs when ICE determines both Lync clients communicate using only host (or local candidate) IP addresses.

 ·         UDP Direct assumes no firewall or Natting is used between Lync clients.
·         Clients that reside within the same broadcast domain or reside on the same subnet.
·         Example may be two Lync clients used at an office or at the same hotel.

2.  UDP NAT.  ICE determines if external clients use an internally Natted subnet that is different than its publicly facing IP

An example may be one or both external Lync clients used from home.  Most DSL and cable modems use NAT with the ISP’s publicly assigned IP address.


3.        UDP Relay.  Lync Access Edge server may provide a relay bridge for clients.  This type of connection is considered a TURN candidate.
  • For clients that cannot communicate directly peer-to-peer.  Routing or firewall problem may prevent communications.
  • Both clients can individually communicate to the Access Edge server.

   ICE candidate determination is used for internal clients as well as external.  Lync uses UDP relay for internal-to-internal and internal-to-external media communication between clients.  This type of connection is considered a STUN candidate. 


*  Important:  Internal clients will always use the Access AV Edge server for external communications.

Distinction worth noting is that internally connected Lync clients will ignore the TURN (or server relay) candidate provided by the ICE server.  This IP address is used only by external (e.g. foreign) endpoints like federated Lync clients.  A Lync client will be made aware of its assigned media relay server via in-band provisioning details provided during initial registration and sign-in to Lync and it will always connect to this FQDN for media relay functionality.  http://blog.schertz.name/2012/10/lync-edge-stun-turn/

4.        TCP Relay.  Access AV Edge relays via TCP when UDP ports are unavailable between client endpoints.
  • UDP is preferred but TCP is always considered as a candidate.
  • There are always 2 potential candidates per network path; UDP and TCP.

ICE candidate promotion and Lync traffic flow should be the same at both data center and at the VPN branch office.  Lync clients at both locations are considered internal clients.  Candidate promotion process allow snooping client traffic to confirm specific breakdown.

My next blog will provide instruction to allow Lync clients to bypass the VPN.  There is already good documentation available on the Internet but I have a couple thoughts specific to Lync 2013, DNS, and GPO.  
 
Last updated  December 1st, 2016 by Steven Jordan

1 Comments

  1. RobertFebruary 19, 2017 at 12:03 AM

    I’ve been searching for some decent stuff on the subject and haven't had any luck up until this point, You just got a new biggest fan!..
    Certified Public Accountant in Key West

    ReplyDelete

Subscribe to: Post Comments ( Atom )

My Instagram