Teams LBR - "Call not allowed in this location" despite matching subnet

The behavior indicates that Teams is probably classifying the endpoint as an unknown location, so add the home network’s actual public egress IP to Trusted IPs before expecting Teams to match [IP Address] to the office site.

Teams first compares the endpoint’s external public IP with the tenant’s trusted-IP list. Only after that match does it evaluate the endpoint’s internal subnet; without a trusted public-IP match, an LBR-enabled Direct Routing user is classified as unknown and PSTN calls are blocked. GatewayLbrEnabledUserOverride = $true explicitly permits calls from an unknown or mismatched site, which explains your test result.^1^^2^

Configure and validate the location

1. Identify the public IP Teams sees.
   • Collect the Teams client logs.
   • Open MSTeams Diagnostics Log [date]__[time]_calling.txt.
   • Locate the client public IP recorded in that file. Microsoft documents this log-based check for diagnosing whether Teams considers a client internal or external.^3^
2. Add that address as a trusted IP.
   • Teams admin center → Locations → Network topology → Trusted IPs → Add.
   • Enter the public NAT address and its appropriate network range.
   • If the connection can egress over both IPv4 and IPv6, add both public addresses; Teams can use either address family for matching.^1^
   PowerShell equivalent:

      Connect-MicrosoftTeams
   
      Get-CsTenantTrustedIPAddress
   
      New-CsTenantTrustedIPAddress `
        -IPAddress "<public-egress-IP>" `
        -MaskBits 32 `
        -Description "Home LBR test egress"
   

3. Validate the private subnet association.
   • Teams admin center → Locations → Network topology → Network sites.
   • Edit office.
   • Confirm that it belongs to the intended network region, has Location based routing enabled, and contains:
     • IP address: [IP Address]
     • Network range: /24
   • Each subnet can be associated with only one site.^4^
   You can also inspect the configured topology with PowerShell:

      Get-CsTenantNetworkSite -Filter "office" | Format-List *
      Get-CsTenantNetworkSubnet |
        Where-Object NetworkSiteID -eq "office" |
        Format-Table Identity, MaskBits, NetworkSiteID
      Get-CsOnlinePSTNGateway -Identity "cube.menathcloudcollab.online" |
        Format-List Identity, GatewaySiteId, GatewaySiteLbrEnabled,
                    GatewayLbrEnabledUserOverride
   

4. Allow propagation, then restart Teams and retest. Network-topology changes can take up to four hours to become available to clients.^4^

Private-address support

A 192.168.x.x endpoint subnet is supported. Microsoft’s topology documentation itself uses [IP Address]/24 as an example tenant subnet, so RFC1918 addressing is not inherently the problem.^4^

Also check whether the client has IPv6. LBR checks for a matching IPv6 address first and falls back to IPv4 only if IPv6 is absent. If the client is using IPv6, define its internal IPv6 subnet and trust the corresponding public IPv6 egress address.^5^

There is no documented admin view in these sources that directly displays a live “effective LBR site” for a client. The practical verification is therefore:

• Client calling log: public IP Teams observed.
• Trusted-IP configuration: that public IP matches.
• Network topology: the internal endpoint subnet maps to office.
• Gateway configuration: the gateway also maps to office.
• Retest with GatewayLbrEnabledUserOverride = $false.

If a VPN, secure web gateway, or cloud proxy changes the source IP, Teams may see that service’s public IP instead of the home connection. Network-configuration lookups are not supported when a cloud proxy modifies Teams clients’ source addresses.^1^

References

1. Network settings for cloud voice features in Microsoft Teams
2. Scenarios for Location-Based Routing for Direct Routing
3. Issues with Local Media Optimization for Direct Routing
4. Manage your network topology for cloud voice features in Microsoft Teams
5. Configure network settings for Location-Based Routing