Firewall Rules for Teams and Webex — Ports, Protocols, and What Breaks
If you’ve ever watched a UCaaS deployment go live cleanly in the lab and fall apart the moment it hit the production network, the firewall is usually where the investigation starts. Not because firewall engineers do bad work — but because the port and protocol requirements for cloud voice platforms are broader, more dynamic, and less forgiving than most enterprise firewall policies are built to handle.
This article covers the full port and protocol requirements for Microsoft Teams and Cisco Webex Calling, the firewall configuration principles that apply to both, and the real-world mistakes that take deployments down at go-live.
How Cloud Voice Platforms Use the Network
Before you touch a firewall rule, it helps to understand what Teams and Webex are actually doing at the network layer.
Both platforms use a two-layer communication model. Signaling traffic — the setup, teardown, and management of calls — runs over HTTPS and is TCP-based. Media traffic — the actual audio and video — runs over RTP/SRTP, which is UDP. These two traffic types have different port requirements, different latency tolerances, and different failure modes when the firewall gets in the way.
The critical characteristic of both platforms is that they are cloud-hosted and use dynamic infrastructure. Microsoft and Cisco don’t publish a static list of IP addresses you can hard-code into your firewall and call it done. Their infrastructure spans multiple data centers across multiple regions, and the addresses your endpoints connect to will change. The correct approach is wildcard domain and URL-based rules, not static IP ACLs.
Microsoft Teams — Port and Protocol Requirements
Microsoft publishes its network requirements through the Microsoft 365 endpoint service, categorized into three priority tiers: Optimize, Allow, and Default. For Teams Calling specifically, the Optimize and Allow categories are what your firewall policy needs to handle correctly.
Signaling and Authentication:
| Traffic Type | Protocol | Port | Destination |
|---|---|---|---|
| HTTPS / Signaling | TCP | 443 | *.teams.microsoft.com |
| HTTPS / Signaling | TCP | 443 | *.skype.com |
| HTTPS / Auth | TCP | 443 | login.microsoftonline.com |
| HTTPS / Auth | TCP | 443 | *.msecnd.net |
Media (Audio / Video / Sharing):
| Traffic Type | Protocol | Port Range | Destination |
|---|---|---|---|
| RTP / SRTP Audio | UDP | 3478–3481 | 13.107.64.0/18, 52.112.0.0/14 |
| RTP / SRTP Media | UDP | 50000–50059 | Microsoft 365 IP ranges |
| STUN / TURN | UDP / TCP | 3478, 3479 | *.transport.teams.microsoft.com |
Key requirement: The UDP port range 50000–50059 must be open outbound for Teams media to flow correctly. This is the range Teams uses for peer-to-peer and server-relayed media. Blocking it forces Teams to attempt TCP fallback, which degrades call quality and increases latency.
For the complete and current Microsoft 365 endpoint list, always reference the official Microsoft endpoint service at aka.ms/o365endpoints rather than static documentation — Microsoft updates these endpoints and the service reflects current requirements.
Cisco Webex Calling — Port and Protocol Requirements
Webex Calling follows the same two-layer model but with its own endpoint requirements. The critical distinction for Webex is that it requires wildcard domain access — attempting to lock down Webex to static IP addresses is one of the most common firewall mistakes in Webex deployments and is covered in the mistakes section below.
Signaling:
| Traffic Type | Protocol | Port | Destination |
|---|---|---|---|
| HTTPS / Signaling | TCP | 443 | *.webex.com |
| HTTPS / Signaling | TCP | 443 | *.ciscospark.com |
| HTTPS / Signaling | TCP | 443 | *.wbx2.com |
| SIP Signaling | TCP / TLS | 5060, 5061 | *.broadworks.net |
Media:
| Traffic Type | Protocol | Port Range | Destination |
|---|---|---|---|
| RTP / SRTP Audio | UDP | 5004, 9000 | *.webex.com media nodes |
| RTP / SRTP Media | UDP | 8000–8100 | Webex media infrastructure |
| STUN / TURN | UDP / TCP | 3478, 5004 | *.webex.com |
For the complete and current Webex endpoint list, reference Cisco’s Webex network requirements documentation directly — Webex infrastructure evolves and static documentation goes stale.
Firewall Configuration Principles for Both Platforms
Regardless of platform, the same core principles apply:
Use wildcard domain rules, not static IP ACLs. Both Microsoft and Cisco operate cloud infrastructure that spans dynamic IP ranges across multiple regions. Static IP whitelists break when infrastructure changes — and it will change. Your firewall needs to resolve and permit traffic based on domain patterns, not hard-coded addresses. Next-gen firewalls with FQDN-based rules handle this natively. If your platform doesn’t support FQDN rules, work with your vendor — this is a solved problem.
Permit the full UDP port ranges. Don’t cherry-pick ports from the required ranges. The platforms use dynamic port allocation within their published ranges for a reason — available ports shift based on load and media negotiation. Blocking any portion of the required UDP range forces degraded fallback behavior or outright failure.
Exclude Teams and Webex traffic from SSL/TLS inspection. Both platforms use end-to-end encryption. Inserting a firewall into that encrypted stream via SSL inspection breaks certificate validation, disrupts signaling, and causes calls to fail at the authentication layer. Add Teams and Webex domains to your SSL inspection bypass list before go-live — not after.
Bypass the proxy. Teams and Webex are not designed to traverse web proxies. Proxy latency adds to media path delay, proxy authentication interrupts signaling flows, and many proxies don’t handle UDP at all. The correct configuration is a proxy bypass rule for all Microsoft 365 and Webex domains. Trying to force cloud voice traffic through a proxy is a reliable path to one-way audio, dropped calls, and a frustrating go-live.
Don’t run deep packet inspection on encrypted voice traffic. DPI on SRTP streams accomplishes nothing useful — the payload is encrypted and the inspection engine can’t read it. What it does accomplish is adding latency to a traffic type that has zero tolerance for it. Whitelist Teams and Webex traffic at the firewall and let it pass uninspected.
What Breaks — Real Examples
Static IP whitelisting for Webex. A customer’s network team locked down their next-gen firewall to only permit traffic to a specific list of Webex IP addresses they pulled from an old Cisco document. Webex Calling worked intermittently during testing and failed completely at go-live when calls started hitting different media nodes. The fix was removing the static IP rules entirely and replacing them with wildcard domain rules for *.webex.com and *.ciscospark.com. The static IP list was never the right approach — Webex explicitly documents that its infrastructure is dynamic and requires domain-based rules.
Proxy misconfiguration killing signaling. A mid-size deployment had all internet traffic routed through an authenticated web proxy. Teams signaling was intermittent — some users could make calls, others couldn’t, and the failure pattern made no sense until someone checked the proxy logs. Authentication failures on *.teams.microsoft.com were silently dropping signaling requests. The fix was a proxy bypass rule for all Microsoft 365 endpoints. Took ten minutes to implement. The troubleshooting took two days.
SSL inspection breaking Teams authentication. A security-hardened environment with SSL inspection enabled on all outbound HTTPS traffic. Teams wouldn’t authenticate at all — login failures across the board. The firewall was intercepting the TLS handshake to login.microsoftonline.com and presenting its own certificate, which Teams rejected. Adding Microsoft 365 authentication endpoints to the SSL inspection bypass list resolved it immediately.
UDP blocked by default policy. A network that had been locked down for PCI compliance had a default-deny policy on outbound UDP. Teams fell back to TCP for media, calls connected but audio quality was consistently poor — choppy, delayed, and one-way on congested links. Nobody had documented the UDP block because it predated the Teams deployment by years. Opening UDP 50000–50059 outbound fixed the quality immediately.
NAT table exhaustion at go-live. A 300-user deployment went live and within the first hour calls started failing randomly across the organization. The firewall had a single public IP handling PAT for the entire site. At peak usage, simultaneous RTP streams from 300 users exhausted the NAT translation table — the firewall ran out of port mappings and started dropping new connection attempts. The fix was adding additional public IPs to the NAT pool and distributing the load. The network had been sized for web browsing concurrency, not concurrent RTP streams.
Asymmetric routing dropping return traffic. A multi-WAN site with two ISP connections and policy-based routing. Outbound Teams traffic was leaving on WAN1, but return traffic was arriving on WAN2 — the stateful firewall on WAN1 had no record of the session and dropped the packets. Calls connected then immediately dropped, or connected with one-way audio. The fix was ensuring symmetric routing for Teams and Webex traffic, or configuring the firewall to handle asymmetric state correctly.
DNS resolution failures. Teams calls failing at the signaling layer with no obvious firewall log entries. The problem was upstream — internal DNS servers couldn’t resolve *.teams.microsoft.com because an overly restrictive DNS policy was blocking external resolution for certain domain patterns. Calls never got far enough to hit a port rule. Adding the Microsoft 365 domains to the DNS resolution allowlist resolved it. Always check DNS before spending hours on port rules. For production DNS configuration and forwarder setup, see DNS and DHCP for Enterprise Networks.
Quick Reference Checklist
Before any Teams or Webex go-live, verify the following at the firewall:
- TCP 443 outbound permitted to Microsoft 365 and Webex domains
- UDP 3478–3481 and 50000–50059 outbound permitted for Teams media
- UDP 5004, 8000–8100 outbound permitted for Webex media
- Wildcard domain rules in place — no static IP ACLs
- SSL/TLS inspection bypass configured for all Microsoft 365 and Webex domains
- Proxy bypass configured for all Microsoft 365 and Webex domains
- DPI disabled or bypassed for Teams and Webex traffic
- DNS resolution verified for all required domains
- NAT pool sized for concurrent RTP streams, not just web browsing
- Routing verified as symmetric for voice traffic paths
What Comes Next
With your firewall rules locked in, the next layer to address is split tunneling for remote workers. VPN configurations that route all traffic through the corporate tunnel before it reaches Microsoft or Cisco infrastructure add latency and congestion that kills voice quality. Split Tunneling for UCaaS — VPN Configuration That Doesn’t Kill Voice Quality covers how to configure it correctly for both platforms.
For the network layer underneath all of this, VLAN Design for Voice Networks covers how to segment your voice traffic correctly before it ever reaches the firewall.
For a pre-deployment validation checklist that includes firewall readiness alongside DNS, DHCP, VLAN, and QoS checks, see Network Readiness Assessment for UCaaS.