MS teams calls drops after 10 seconds when using AnyConnect

[Chess Norris]

Hello,

I have a customer that are reporting that Microsoft teams calls being dropped after 10 seconds when they are using AnyConnect to make direct calls to to their organization. This happens only when the caller use AnyConnect and the called party are on the company LAN. The call will work perfectly until 10 seconds and then will end / be torn down. 

This issue seems to be quite common and maybe not directly related to AnyConnect, but more a VPN problem in general, but so far I cannot find any other solution that to use split-tunneling to exclude MS teams IP range and unfortunately that is not an option due to company policy. Here's a link that describing this issue.

https://learn.microsoft.com/en-us/answers/questions/44736/what-would-cause-ms-teams-calls-to-drop-after-abou?page=3#answers 

Has anyone else being able to resolve this issue without using split-tunneling?

Not sure if I should ask the customer to raise a ticket with Microsoft or Cisco or maybe both?

Thanks

/Chess

[mbemis]

Hello 

I am having the same issue.  Were you able to get this resolved?  

[Chess Norris]

No, the only way I was able to resolve it, was to include the MS teams IP addresses in the Split ACL.

/Chess

[Rob Ingram]

@mbemis @Chess Norris you could use dynamic split tunnel and define the MS Teams associated URLs

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215383-asa-anyconnect-dynamic-split-tunneling.html

[Chess Norris]

Yes, that is true. We decided to go with the public IP ranges we got from this site - https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide but MS might change those addresses in the future.

However, from what I've heard they still use the same ranges since many years back, but how knows.

/Chess

[Rob Ingram]

@Chess Norris dynamic split tunnel doesn't rely on the IP addressess, just the URLs - so if the IP addresses do change the URL would suffice.

[JohnBemp]

We are having the same issue. Had a ticket in with Microsoft NO HELP what so ever. We did find that if you block traffic on the UDP ports 3478, 3479, 3480, and 3481 then the Calls stay connected, BUT the call quality is not as good and you will get some choppy audio and some frozen video...... I will update if we find anything else....

[JohnBemp]

OK so Here is an update 

We have a rule that allows all traffic from our vpn to our inside user ip ranges.

We have a rule that allows our inside IP ranges outbound to vpn users and to teams ips for the UDP ports 3478, 3479, 3480, and 3481.

When a User on the VPN calls a user at the office the call drops after 10 to 15 seconds

When the same user from the office calls the user on the VPN the call is fine.

If I disable the outbound UDP rule we get audio and video quality issues BUT the calls from the VPN to the office work without the drop!

I can not for the life of me figure out why.

[Tim Byrnes]

John

I found this thread because I'm trying to help solve the same issue.
Question: Do your on-prem endpoints and VPN endpoints end up getting the same public IP NAT when communicating to the Internet (MS Teams call control)?

We're seeing different behavior if VPN users connect to DR VPN Headend (no call drops) than when VPN users connect to the Primary VPN Headend (call drops) so I'm trying to determine if that's consistent with others experiencing the issue.

[eclifford]

We are running into this near exact problem except sometimes the VPN remote user calls will work when calling the LAN... It is a strange one, I read it has something to do with SSL certs being denied, could that be the cause why it is intermittent?

[Tim Byrnes]

@eclifford 

We temporarily solved the issue by applying a Dynamic VPN split-tunnel ACL as described above.

My assumption was that in our case MS initially establishes the Teams call routing through the cloud-based Call Proxy.  When it sees/believes that both endpoints are on the same LAN (which it would if a VPN endpoint appears to be coming from the same public IP as the LAN endpoint) then it attempts to switch to a direct peer-to-peer path.  That's where the calls were dropping.

We had some NAT and Routing issues so the future solution will be to separate RA VPN services to a another cluster of FTDs and utilize unique public NAT IPs for VPN endpoints.