GVC Users in Tunnel All Mode are Unable to initiate calls on Microsoft Teams
08/13/2021 4 People found this article helpful 31,920 Views
Administrators having users connected with Global VPN clients and running in Tunnel all mode may run across into an issue where they are not able to engage each other on Microsoft Teams calls (Audio/Video).
The symptom may include total or partial Internet connectivity loss from the client's end while the GVC application will remain connected. As the call never got established, hence when the GVC application is disconnected and connected back again, the other user will receive a notification as a missed call alert.
This is observed in IPsec client VPN only, not in the SSL VPN client
Microsoft has clearly mentioned in their official document that it is their recommendation to avoid the tunnel-all traffic and use the split tunnel mechanism.
We recommend that you provide an alternate path for Teams traffic that bypasses the virtual private network (VPN), commonly known as split-tunnel VPN. Split tunneling means that traffic for Microsoft 365 or Office 365 doesn't go through the VPN but instead goes directly to Microsoft 365 or Office 365. Bypassing your VPN will have a positive impact on Teams quality, and it reduces load from the VPN devices and the organization's network. To implement a split-tunnel VPN, work with your VPN vendor.
Other reasons why we recommend bypassing the VPN:
VPNs are typically not designed or configured to support real-time media.
Some VPNs might also not support UDP (which is required for Teams).
VPNs also introduce an extra layer of encryption on top of media traffic that's already encrypted.
Connectivity to Teams might not be efficient due to hair-pinning traffic through a VPN device
Reference : https://docs.microsoft.com/en-us/microsoftteams/prepare-network#network-optimization
Use the Split Tunnel vpn configuration .
A workaround which can be tried in tunnel-all mode to avoid the STUN traffic and take an alternate way is to block few ports by performing the following steps :
- Create a service group for port UDP 3478 - 3481, UDP 80 and UDP 443
- Create a DENY rule from VPN to WAN zone with source as ANY destination as ANY and service as the group with the above ports.
This will allow the client to send packets to a relay server and the condition of the two clients to communicate with peer's VPN local IP will not be satisfied.
The traffic to Internet will start flowing and the meeting can be hosted.
CAUTION: This doesn't guarantee good quality on the voice or audio as forming connection does not necessarily mean good quality of WebRTC. Hence, if the workaround is not providing adequate result, it is strongly suggested to use the split tunnel mechanism.