Exclude lync traffic from SSL inspection

[Michael Eriksson]

We're using Ironport WSA as our Web Proxy and we're experiencing problems with Lync. The problem appears when we're invited from other external companies to a Lync meeting. When you click the invitation URL the meeting try to start but as soon as it does it shuts down.

If we connect without the Ironport WSA Everything works perfect and we have come to the conclusion that it is SSL inspection that is the problem, so my question is:

Is it possible to disable SSL inspection on all Lync traffic? Since we have no idea who will invite us, so it's not an option to just exclude single addresses, we need to find a way to identify all Lync traffic and let it through with no interferance.

I hope someone can help me.

Regards

Micke

[Ken Stieers]

I think this will work:

In Web Security/Decryption Policies, add a policy above your global policy. Leave it a all identities, but click on advanced, and add  "\(Microsoft Lync\)" to the User Agents box.   Set URL filtering to all passthrough, disable web reputation, set default action to passthrough.

It should look like this:

Your categories in "Access Policies" will still apply, this is just what to do with the SSL traffic.

[Michael Eriksson]

Hi,

Thank you very much for your answer, I had to wait for a guy at our Communication department to test this.

Unfortunatly it didn't work though. The signal goes through because it goes outside the WSA on port 5061, but when the https stream are setting up the meeting breaks instantly.

Thank you for taking your time to try :o) We will continue to try and if we find a solution I will post it.

Regards

Micke

[Ken Stieers]

The 5061 traffic is SIP protocol. The WSA has no idea what to do with that traffic. You need to allow that traffic out through your firewall and not redirected to the WSA at all.

[Michael Eriksson]

Absolutly, 5061 do not go through the Proxy. I just tried to explaine what happens when we try to start a meeting. 5061 works, so the invite is fine, but after that the datastream over 443 will setup and that traffic goes through the Proxy and because it terminates the traffic the meeting ends.

Best regards

Micke

[kussriva]

Hi,

You can try bypassing Lync Traffic from HTTPS Decryption in the following ways:

1.  Create a Custom URL Category and add the following to the Sites, then submit the change;
 
.onmicrosoft.com, .microsoftonline.com, .microsoftonline-p.com, .sharepoint.com, .outlook.com, .lync.com, onmicrosoft.com, microsoftonline.com, microsoftonline-p.com, sharepoint.com, outlook.com, lync.com, osub.microsoft.com, 65.54.54.128/25, 65.55.121.128/27, 65.55.127.0/24, 111.221.17.128/27, 111.221.22.64/26, 111.221.23.0/25, 111.221.76.96/27, 111.221.76.128/25, 111.221.77.0/26, 132.245.0.0/16, 157.55.40.128/25, 157.55.46.0/27, 157.55.46.64/26, 157.55.104.96/27, 157.55.229.128/27, 157.55.232.128/26, 157.55.238.0/25, 207.46.5.0/24, 207.46.7.128/27, 207.46.57.0/25, 69.167.114.48/28, 91.194.5.240/28, 69.167.115.0/26, 91.220.9.16/28
 
2.  For HTTPS proxy create a decryption policy using the new Custom URL Category and set it to Pass Through for the Custom Category and submit the change.

Regards,

Kush Srivastava
Cisco PDI TA
http://www.cisco.com/web/partners/tools/pdita.html

[Michael Eriksson]

Hi,

Is the solution you're proposing for Office365 solutions? Just want to be sure before asking my collegue to try.

I guess I missed to give that information in the first place. We're running Lync on-premise and the problem occures when a non federated external part invites us to a meeting.

The companies we've invited so far works fine, there is no problem at all, because their Proxys do not interfer with the https traffic.

Feels like a har nut to crack this....

Regards

Micke