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.
![](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(128, 25%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
We have the same issue, BUT only one way.
Site 2 Site between HQ and Branch Office (BO)
ASA in BO and Firepower in HQ
Tunnel is stable and other services are running good
Wireshark and and Debug is not helpfull
Ended up blocking ALL UDP Traffic from BO to HQ
this works , i THINK it is because "voodoo" stuff happens between firewalls, this way i force Microsoft to be the source and destination for connectionw and not P2P
But this is what worked for me.
![](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(268.8, 12%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMH%3C/text%3E%3C/svg%3E)
Does anyone have a solution as we also cannot do split tunnel?
Unfortunately we have not yet found a solution, we have had several troubleshooting sessions with CiscoTAC to no avail. Split Tunnelling still not accepted as an option
Same problem here and interested in any developing solutions. Split tunnel not a solution.
![](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(272, 66%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ED%3C/text%3E%3C/svg%3E)
We're experiencing the exact same issue:
The caller must be on the VPN
The called party must be on a site LAN
The call will work perfectly until 10 seconds and then will end / be torn down
LAN to VPN works
VPN to VPN works
Version:
Microsoft Teams Version 1.4.00.8872 (32-bit)
Split tunneling is not an option for us.
The only workaround at this time (that is not split tunneling) is to use the Teams Web Client via https://portal.office.com then select Teams on the left hand App bar. Now test your call.
Same scenario, VPN to LAN via the Teams Web Client works perfectly.
Teams application bug issue? Please advise. We're submitting a Unified Support Ticket with Microsoft to hopefully get us all some resolution.
![](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(208, 28.000000000000004%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC%3C/text%3E%3C/svg%3E)
I have been fighting with this exact same problem - Cisco ASA 5506 and when clients connected to VPN call someone in the office the call drops after about 10 seconds.
Has anyone had any success fixing this without split tunneling?
Thanks,
Jon
Please check the response from other people in the chat as they have a solution (split tunnelling VPN configuration and bypass all Microsoft services from traversing the tunnel) which isn't ideal but seems to resolve the issue. In my case the company policy does not allow split tunnelling
Similar issue here, trying to avoid split tunneling. Was hoping to find a solution w/out having to split tunnel...