Audio, video and/or desktop sharing is not working on Skype for Business when going through a ProxySG or Advanced Secure Gateway

Products

Asset Management Solution Data Center Security Monitoring Edition Advanced Secure Gateway Software - ASG ProxySG Software - SGOS

Issue/Introduction

Audio, video, and/or desktop sharing with Skype for Business (SfB) does not work when the following conditions are true:

If ProxySG or Advanced Secure Gateway is deployed transparently:
- HTTPS service set to Intercept and proxy type is SSL proxy
- SSL interception policy is installed
- Tunnel on protocol error feature is disabled
- NAT exists between client and Lync/SfB server
If ProxySG or Advanced Secure Gateway is deployed explicitly:
- Protocol detection is enabled on the HTTP Explicit service or through policy
- SSL interception policy is installed
- Tunnel on protocol error feature is disabled
- NAT exists between client and Lync/SfB server

Cause

SfB uses multiple protocols when establishing connections, connecting to meetings and sharing content. Two protocols used when audio, video, or desktop sharing is part of a Skype meeting are Session Initiation Protocol (SIP) and Traversal Using Relay NAT (MS-TURN) over Pseudo-TLS. Both of these protocols use the SSL port but either do not follow the SSL protocol completely or use a protocol within SSL that is not HTTPS. When these protocols are sent through a ProxySG or Advanced Secure Gateway appliance, they could be disconnected or fail because SIP and MS-TURN is not following a protocol specification that the proxy understands.

Resolution

A new feature was added to the ProxySG that allows detection and correct processing of SIP and MS-TURN traffic. With this feature, audio, video, and desktop sharing with SfB meetings work without issues when a ProxySG or Advanced Secure Gateway appliance is processing the traffic. This feature is available in SGOS 6.5.10.4.

Notes:

SGOS 6.5.9.14 and 6.5.9.15 is no longer the recommended release. 6.5.10.4 and later 6.5 releases contain important fixes for Office 365 support. See the Office 365 Web Guide for additional details.
Availability in Advanced Secure Gateway and SGOS 6.6.x are to be determined.
SGOS 6.7.2.X supports these fixes as well, we currently recommend 6.7.3.5 at the time of this article.
For more information on Office 365 Best practices, check the following document:

https://origin-symwisedownload.symantec.com/resources/webguides/sgos/o365/pdf/O365_SfBLync.pdf

See article 000032599 which includes information on added support for OCSP/CRL check processing which is also part of the SfB feature and is needed for being able to log into SfB and/or join meetings.

Step 1 - Enable protocol detection

After upgrading the appliance to a release with the new feature, services must be modified to ensure that protocol detection is enabled. This is needed for SIPS and MS-TURN traffic passing through those services to be detected.

In the Management Console, select Configuration > Services > Proxy Services.
If the appliance is intercepting traffic explicitly, enable protocol detection for the explicit proxy service. If the appliance is intercepting traffic transparently, enable protocol detection for the HTTPS service (port 443). The following is an example showing the HTTPS service with protocol detection enabled:

Step 2 - Trigger protocol detection for SSL interception

Next, add/modify policy that triggers protocol detection for SSL interception. Optionally, block unknown protocols using SSL.

Create a new SSL Interception layer. If an SSL Interception layer exists, proceed to the next step,
Do one of the following:

Add a rule with an SSL Interception object with Action set to "Enable SSL Interception with proxy handoff".
If there are rules in a previously created SSL Interception layer that include SSL Interception objects set to "Enable HTTPS Interception", change them to "Enable SSL Interception with proxy handoff".

Step 3 - (Recommended) Add CPL to deny unknown protocols using SSL

When policy includes the object configured in Step 2, the appliance STunnels unknown protocols using SSL. This behavior is different from using the HTTPS interception object which responds with an error when an unknown protocols uses SSL. To emulate the HTTPS interception object behavior while still being able to use SSL interception with automatic protocol detection, add the CPL in this step.

Create a new CPL layer or modify an existing CPL layer.
Add the following CPL to the end of the CPL layer:

<proxy>
DENY client.protocol=!ssl tunneled=yes

This CPL ensures that unknown protocols using SSL will be denied. The only caveat to using the above is for explicit transactions with protocol detection disabled. If explicit proxy is being used and certain traffic has protocol detection disabled, ensure that the rules to disable protocol detection occur within the CPL above. Example if example.com has protocol detection disabled:

<proxy>
url.domain=example.com detect_protocol(none)
DENY client.protocol=!ssl tunneled=yes

With a supported release installed and policy configured, audio, video, and desktop sharing with SfB work. To confirm that SIP and MS-TURN protocol detection is working, you can see which protocols have been detected in active sessions, as follows:

Workaround

If you are running a release that does not support SIP and MS-TURN protocol detection, refer to the following workarounds.

To prevent SIP requests from failing, install SNI-based bypass policy with SSL intercept (SGOS 6.5.6.1 and later):

<ssl-intercept>
url.host.substring=url_substring ssl.forward_proxy(no)
ssl.forward_proxy(https)

Where url_substring is:

lync.com—For an Office 365-hosted Lync server.
Local domain—For an on-premises Lync server.

To prevent MS-TURN requests from failing, enable tunnel on protocol error using the CLI command:

#(config general) tunnel-on-protocol-error enable