This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(0, 28.000000000000004%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESM%3C/text%3E%3C/svg%3E)
• The caller must be on the VPN (Remote Access Service)
• The called party must be on a site LAN (but it can be any Company site)
• The call will work perfectly until 10 seconds and then will end / be torn down
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(6.4, 19%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERF%3C/text%3E%3C/svg%3E)
We have noticed that all of a sudden, inbound "from DirectAccess to guy on LAN" calls are working. This started in the last few days. I'm hesitant to trust that this is permanently fixed BUT initial testing suggests the thing that changed was an upgrade to Windows 10 21H1.
At the moment it looks like it requires the guy on the internal LAN to be on 21H1, whereas the guy on the DirectAccess VPN (using force tunnel) can still be on 20H2, and it'll connect an inbound call.
In other words:
20H2 on DirectAccess --> 21H1 on LAN works
21H1 on DirectAccess --> 21H1 on LAN works
20H2 on DirectAccess --> 20H2 on LAN still doesn't work
Since it's an enablement package we're cracking on with upgrades and I will report back if this behaves itself over hte coming days, and when i get additional people upgraded and see if the pattern holds. Fingers crossed, but i won't get my hopes up :-)
Thanks RonanFahy for the information please keep us posted if tis could be the solution, in the meantime I will find out from our IT team if we have anyone with Windows 10 21h1 to test that as well.
Regards
Sydney
So the 21H1 thing was a false alarm sorry, but we have we think solved it.
We spotted that our proxy was blocking some traffic that wasn't obviously teams related.
At the moment where the "receiver" inside the network clicks the button to accept the incoming call Teams tries to connect out to an IP address rather than to a hostname, which is awful practice of course. That IP address (in our case were seeing things like https://52.113.201.115 and https://52.113.201.169) were being blocked as failing the SSL inspection - the certificate common names didn't match the host name, again, terrible practice Microsoft. We had to bypass SSL inspection for that entire range along with other identified ones, before it would work. I don't like doing that, as we can only trust that nothing else runs on the same IP's, but who has a choice.
Ranges used were:
52.112.0.0/14
13.107.64.0/18
52.238.119.141
52.244.160.207
52.120.0.0/14
We use a proxy that can subscribe to managed lists so these were referred to as "Lync Online IPv4 Ranges" so some are probably related to old Lync / SfB rather than Teams, but it worked.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(108.80000000000001, 25%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGS%3C/text%3E%3C/svg%3E)
We have the exact same problem today. Unsure if long outstanding or not.
Anyone managed to find a fix. We don't allow split tunnelling.
The one thing we noticed that works from VPN client to HQ (Behind an ASA) is meetings. These load fine.
Its only affecting Teams calls/video directly.
Hi Luca, thanks for the reply to my question, but the puzzle is the call will get established for the first 10secs and then drops, so I'm failing to understand how the firewall/router would have allowed the traffic in the first place if it then drops it away immediately?
Hi,
please check the routing between the client in VPN and the client in LAN.
In a point-to-point call between two Teams clients, the two clients will try to establish a Media direct flow between the two clients.
If something in the middle (routing, firewall etc) block this UDP traffic, the call will drop after 10 sec.
Best
Luca
Hi,
I understand your doubts.
I've seen fw that do not drop UDP packets immediately...
Anyway:
Thank you. Best. Luca
I did monitor the traffic on the firewall during a live troubleshooting session and I could see not the drop of traffic, the logs will just stop when the call dropped.
Yes when the call is established without that VPN the Teams call works fine. Maybe I need to drill a bit more into the specific VPN tunnel in question.
Thanks for your help.
Sydney
Hi,
I suggest to take PCAP Traces directly on the two Teams Clients with Wireshark, this should help you to find the issue.
I'll thank you if you will update this thread.
Thanks
Luca