It does nothing but steer it. For performance reasons and troubleshooting (if you ever have a problem, MS will blame Netskope) bypassing streaming traffic (if you are not blocking it) is advisable.

Netskope only steers TCP 80/443 traffic unless you have CFW. If you have CFW then you will need to make exceptions for that outbound UDP Traffic teams uses for audio and video.

Team,

I just saw this post.

We had issues with Teams dropping audio calls after 10 seconds when Netskope was enabled.

If you go to the link below, Microsoft uses the same IPs for TCP and UDP for Teams. However, it appears they use different ports for the UDP traffic. Can the Netskope client determine when to use UDP vs. TCP for the IPs below?

13.107.64.0/18

52.112.0.0/14

52.122.0.0/15

When you get to the site, go to “Skype for Business Online and Microsoft Teams

https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide

Is everyone still having audio/video issues when trying to steer Teams through Netskope? 

To make exceptions via CFW, you need to create an allow outbound firewall rule using:

UDP ports: 3478-3481 and destination ip ranges: 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15

Sourced from: https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide

Hi.  Is this documented anywhere?  I’ve searched…. What about zoom or google meet? I have cloud firewall and no one mentioned we need to do this in our onboarding and now we’re having issues with google meet in particular.  I have a ticket open. It would be great to see a best practices document around web conferencing / VoIP steering  and if what exceptions / cloud firewall rules are needed 

I have not seen evidence of Netskope's ability to steer web conferencing applications properly. The strange thing is it does not appear to affect everyone. The common issue is dropped calls or the inability to open applications when steered through Netskope.

We have bypasses for the following:

WebEx

MS Teams

I think web conferencing apps using TCP and UDP simultaneously could be causing the issues. If I'm not mistaken, Netskope does not steer UDP traffic. The Netskope client is supposed to distinguish between TCP and UDP traffic; however, if the application uses the same IPs for both protocols like Microsoft does for Teams, this may cause hit-and-misses by the client to make the right choice regarding steering. This is just my theory; our TAM is currently investigating our issue with Teams. Bypasses are not suitable due to losing DLP functionality for MS Teams.

Currently, there is no documentation regarding web conferencing applications and Netskope. The solution at this time is to bypass the traffic.

My apologies. I missed the critical "no" in my statement above. 🙂

More to come.

That’s exactly the issue I have with google meet.  Most are not complaining, but others are with same configuration/hardware stack. I have a sku with netskope where all traffic goest through it, including UDP.  I was able to prove this on a client with google meet running.  

2023/08/04 16:40:22.353557 stAgentNE p47814 t956187 debug tunnel.cpp:869 nsTunnel DTLS SsessId 501] Tunneling UDP flow from addr: 1.0.0.1:65534, process: google chrome helper to host: 74.125.250.195, addr: 74.125.250.195:3478 to app-fw

Right now support is having me bypass google meet IPs essentially creating split tunnel for the media traffic.  But not necessarily the signaling and meet URLs.   Well see real quick tomorrow morning when 180 people in meet heavy conferencing traffic experience it.  

@Lockdown. Can you point me to the documentation?  I must be blind or there is a 5th documentation source that I don’t know about lol. Thanks! 

Thanks for the update. I'm going to start a live Teams chat regading ZTNA and Netskope. Would you be interested in joining? 

Note: if the UDP traffic doesn't have a relevant path it fails back to UDP. Please ensure you have followed the vendor best practices highlighted https://community.netskope.com/t5/Next-Gen-Secure-Web-Gateway-SWG/Facing-User-Issues-while-steering-Web-Conferencing-Apps/m-p/7512#M625

If you are steering the TCP traffic you need to ensure the UDP path is valid or it will fail-back to TCP. Ensure all vendor best practices are followed for the QoS traffic to go direct.

https://community.netskope.com/t5/Next-Gen-Secure-Web-Gateway-SWG/Facing-User-Issues-while-steering-Web-Conferencing-Apps/m-p/7512#M625