Contact Us

Configuring Internet Firewall Rules for Microsoft Teams Direct Routing

Introduction

This is the fourth in a series of articles on hardening AudioCodes Session Border Controllers (SBCs). The series is mostly following the guidance provided by AudioCodes. These configuration notes are referenced at the end of this article. These articles are components of eGroup | Enabling Technologies’ security mantra:

  1. Trust no one.
  2. Harden everything.

We are going to look at the rules that need to be added to an organization’s internet-facing firewall to provide connectivity between Microsoft Teams and AudioCodes SBCs configured to support Teams Direct Routing:

  • Microsoft documentation on the required firewall rules for Teams Direct Routing.
  • Defining the media port ranges to be used by the Teams Direct Routing untrusted interface on the SBC.
    • We’ll review the specific signaling and media range rules needed for several different tenant types:
      • Microsoft 365
      • Office 365
      • Office 365 DOD
      • Office 365 GCC
      • Office 365 GCC High
    • Discuss the additional rules needed to support Microsoft Teams Media Bypass and Local Media Optimization (LMO).
    • We’ll also touch on the rules needed for other solutions connected to other untrusted interfaces:
      • SIP Trunks
      • Emergency Routing Service Provider (ERSP)
      • Contact Center solutions, etc.

Background

In the previous article in this series, Separation of Un-trusted Network Traffic on AudioCodes SBCs, we talked about the concept of trusted and untrusted interfaces on an AudioCodes SBC. Most SBCs will have:

  • A single trusted interface connected to the organization’s local area network.
  • At least one untrusted interface connected to a SIP Trunk, Microsoft Teams, an Emergency Routing Service Provider (ERSP), Contact Center solution, etc.
    • Microsoft Teams Direct Routing SBCs will have a minimum of two (2) untrusted interfaces:
      • An interface to Microsoft Teams
      • A second untrusted interface providing a path to the Public Switched Telephone Network (PSTN).
        • SIP Trunks.
        • T1/E1 circuits.
        • Primary Rate Interfaces (PRIs) or Basic Rate Interfaces (BRIs).
  • The SBC may be interfaced to an organization’s upstream Public Branch Exchange (PBX) through which it can access the PSTN. The PBX connection is typically established on the trusted LAN interface of the SBC.

It is a well-accepted and understood practice to deploy a firewall solution between the internet and an organization’s DMZ and trusted networks. The main purpose of a firewall is to block all inbound traffic from the internet while only allowing permitted bidirectional traffic to be routed to the organization’s DMZ and trusted networks.

  • The organization’s internet firewall should always be used to route bidirectional traffic from the internet to the untrusted interfaces on an AudioCodes SBC.
  • The internet firewall is the first line of defense protecting the traffic flowing between the internet and the untrusted interfaces of the SBC.
    • The articles in this series describe the additional defensive lines that should be configured on an SBC.
  • The rules on the internet firewall should only permit traffic between the IP addresses provisioned by Microsoft Teams, the SIP Trunk vendor, ERSP, etc., and their respective untrusted interfaces on the SBC.
  • Traffic from all other IP networks should be blocked.
  • The rules should limit the port ranges and traffic types (TCP, UDP, TLS) between the SBC and the vendor’s solutions.
  • The firewall should route traffic bidirectionally to specific port ranges on the SBC for each untrusted interface. The ranges are defined on the SBC through SIP Interfaces and Media Realms.
  • There are exceptions, mainly for SIP Trunks installed over dedicated direct connections to the vendor.

Dedicated circuits or direct connections between an organization and a vendor usually bypass the organization’s internet firewall. Most SIP Trunk vendors when implementing a dedicated SIP Trunk circuit will install their own SBC(s) or SBC/firewall combination on the organization’s premises. The vendor SBCs are then cross-connected to an untrusted interface on an AudioCodes SBC over a small, dedicated network with between two (2) and four (4) endpoints. Hardening the SBC protects it from unwanted traffic coming from the vendor’s equipment much like the organization’s own internet firewall.

Microsoft Teams Direct Routing Firewall Requirements

The firewall requirements for the different Microsoft and Office 365 tenants can be found on the Plan Direct Routingweb page. For each type of tenant, the web page provides the:

  1. Fully Qualified Domain Names (FQDNs) of the Direct Routing connection points.
  2. The subnets the FQDNs will resolve to.
  3. The SIP signaling ports.
  4. Media traffic port ranges.
  • These rules apply when a Network Address Translation (NAT) address is associated with the Public IP address of the Teams interface and when one is not.
  • For a NATted configuration, the organization’s firewall engineers will need both the Public IP address and the NATted address.
  • The NATted address is assigned to the Teams network interface on the SBC.
  • Microsoft Teams uses the same addresses for SIP signaling and media. Other SIP service providers (SIP Trunks, ERSPs, Contact Center Solutions, etc.) may not.
  • Application Layer Gateway (ALG), Deep Packet Inspection, and other similar firewall features should not be applied to Teams traffic in general and to Teams traffic routing to and from a Direct Routing SBC.

***These are not the firewall requirements for Microsoft Teams traffic. These can be found on the Office 365 URLs and IP address ranges web page.

On Windows Servers running the Azure Monitor Agent, use data collection rules to define the data to collect from each agent. Besides for the predefined sets of events that you can select to ingest, such as All events, Minimal, or Common, data collection rules enable you to build custom filters and select specific events to ingest. The Azure Monitor Agent uses these rules to filter the data at the source, and then ingest only the events you’ve selected, while leaving everything else behind. 

Microsoft 365, Office 365, and Office 365 GCC Tenants

Microsoft Office 365 DOD Tenants

Microsoft Office 365 GCC High Tenants

Teams Media Port Ranges and Media Realms on the SBC

In a previous article in this series, Separation of Un-trusted Network Traffic on AudioCodes SBCs, the physical and logical separation of the SIP traffic traversing the SBC was discussed. On the logical side, we talked about each SIP service (Teams, SIP Trunks, ERSPs, etc.) having its own set of defined parameters. Each SIP service on the SBC should have its own:

  • Network Interface
  • Media Realm
  • SIP Interface
  • Proxy Set
  • IP Group
  • IP Profile
  • Coder Group
  • Allowed Audio Coder Group (as needed)
  • Message Manipulation Rule Set (as needed)

In terms of the organization’s internet firewall rules the two (2) SBC elements that come into play are the Media Realms and the SIP Interfaces. A Media Realm defines a specific range of UDP ports to be used for SIP Media traffic. Media Realms are in turn assigned to SIP Interfaces and IP Groups. Each SIP service should have its own Media Realm, SIP Interface and IP group.

SIP signaling traffic is usually configured on ports in the 5060 to 5075 range. To avoid these ports, the default starting port for SIP media on an AudioCodes SBC is 6,000 with the available ports extending to 65,535. When defining a Media Realm port range, you need to specify the starting port and number of media session legs. The ending port is calculated based on these inputs. We are not going to dive deeper into the nuances of configuring Media Realms in this document. Typical practice is to separate the starting ports of the ranges by 1,000 and configure 100 media session legs. Each of these ranges would have 1,000 ports and no overlapping. This is assuming that the “UDPPortSpacing” parameter on the SBC is set to ten (10).

On a new SBC, the Media Realm for the LAN (trusted) interface would usually start at port 6,000 and extend to 6,999. If Teams is the first SIP service added to the SBC, the ports in its realm should be from 7,000 to 7,999. It is this range that is referred to as the “SBC Media Realm Range for Teams” in the tables above. In the tables, 7,000-7,999 can be inserted in the cells that currently say, “SBC Media Realm Range for Teams”.

The next SIP service added to the SBC will have its Media Realm setup for ports 8,000 through 8,999.

Teams Media Bypass and Teams Local Media Optimization (LMO)

Teams Media Bypass and Teams Local Media Optimization (LMO) are optional features that can be enabled on Direct Routing SBCs. Both reduce the number of hops and improve performance for SIP Media traffic between Teams endpoints and the Session Border Controller. Enabling Media Bypass requires the addition of several more firewall rules. LMO requires the same set of rules on the organization’s internet firewall. If there is a firewall between the internal endpoints and the trusted interface of the SBC, additional rules may need to be added to this firewall.

  • Media Bypass
    • Requires several externally facing additional rules on the organization’s internet firewall.
    • Routing and/or firewall rules may be needed to provide internally connected endpoints direct access to the SBCs Teams Public or NATted IP addresses.
    • Media Bypass may improve performance for some internally and externally connected endpoints by bypassing the Teams Media Processors and using the Teams Transport Relays.
    • There is some additional configuration required to enable Media Bypass in the Teams Admin Center (TAC) or through Teams PowerShell. There should not be any changes required on the SBC.
    • Internally connected users in the same building or network as the SBC, given direct access to the SBCs Public IP (or possibly the NATted IP), should see a significant performance improvement. This would remove the Teams Media Processors and Transport Relays from these devices’ media path.
  • Local Media Optimization
    • Requires the same rules as Media Bypass on the internet-facing firewalls.
    • Internally connected users would not need direct access to the SBCs’ Public or NATted IP addresses.
    • One or more rules would need to be added to the built-in firewall on the AudioCodes SBC to permit internal device traffic to route bidirectionally through the SBCs’ trusted interface. For more information on configuring the built-in firewall, please see the previous article in the series, Configuring the Firewall Rules on AudioCodes SBC for Microsoft Teams.
    • Enabling LMO requires changes in the TAC or through Teams PowerShell. These changes are more extensive than those needed for Media Bypass.
    • The configuration on the SBC also needs to be modified to support LMO.
    • If there is an organizational firewall between the internal devices and the trusted interface on the SBC, rules will have to be created to permit bidirectional traffic.
    • LMO is only beneficial to internally connected devices.
    • Besides taking the Teams Media Processors and Transport Relays out of the SIP media path, LMO enables a path to route SIP media through the trusted LAN interface of the SBC.

Microsoft 365, Office 365, and Office 365 GCC Tenants

Microsoft Office 365 DOD Tenants

Microsoft Office 365 GCC High Tenants

Firewall Rules for SIP Trunks, ERSPs and other SIP Entities

  • We can’t provide specific examples of the firewall rules you will need to connect your SBC to other SIP service providers (or entities).
  • Here is some generic guidance on configuring these rules for over the internet connections to a SIP Service provider:
    1. The SIP service provider will have to provide you with the following information:
      1. The SIP Signaling address(es) on their side that the SBC should route SIP signaling traffic to.
      2. The SIP Media address(es). They are usually the same as the signaling addresses, but not always.
      3. The port and protocol they will use for SIP Signaling to communicate with your SBC. In most cases this will be 5060/UDP. If you have separated the SIP entities on your SBC, this should not be a problem, even if more than one provider wants to use 5060/UDP.
      4. The port and protocol they want the SBC to use for SIP Signaling. This will usually be the same as that being used for the inbound traffic to the SBC.
      5. The range of Media Ports they will be using to communicate with your SBC. These are not very consistent from vendor to vendor. Once again SIP entity separation will prevent any conflicts if more than one provider uses the same or overlapping media port range. Some examples of provider media port ranges:
        1. 30,000-60,000
        2. 6,000-65,535
        3. 50,000-59,999
    2. Create a Media Realm and setup the next “available” 1,000 port block of ports for this new SIP service provider.
    3. Provision a Public IP address for the new service. Provide this address to the vendor. Allocate a NATted IP address as needed.
    4. When planning out your firewall rules, they must match the media port ranges provided by the vendor. Even if you think that the range they require, 6,000-65,535, is too broad and a potential security risk, do not use a different smaller range in your rules. Doing so can cause call failures between your endpoints and the service provider.
    5. Define the rules you will need on the organization’s internet firewall for the new service:
      1. SIP Signaling rules
        1. Provider to the SBC
        2. SBC to the provider
      2. SIP Media rules
        1. Provider to the SBC
        2. SBC to the provider

Summary

  • The first layer of defense for the untrusted interfaces of a Teams Direct Routing SBC is the organizations internet facing firewall.
  • This series of articles details the 2nd, 3rd and additional layers that should be configured on the SBC itself.
  • Organizations must decide on placing a firewall in front of the trusted interface of the SBC. This essentially boils down to a question of how much you trust, or don’t trust, what’s flowing through your trusted network.
  • Application Layer Gateway (ALG), Deep Packet Inspection, and other similar firewall features should not be applied to Teams traffic in general and to Teams traffic routing to and from a Direct Routing SBC.
  • Do not guess what firewall rules need to be when adding a SIP service to the SBC. Get the information from the vendor.
  • Make sure your firewall rules for SIP media match those provided to you by the vendor. If you are concerned about the size of the SIP media port range, ask the vendor if it can be narrowed. Do not reduce it yourself when creating your rules.

 

eGroup | Enabling Technologies is available and ready to answer any questions that you might have about defining the required organizational internet firewall rules for Teams Direct Routing. While we did not go into Media Bypass and Local Media Optimization in depth, we are ready to show you how these features can improve the performance of SIP media for your Direct Routing users.

This series is part of our effort to help our customers implement a “Trust No One and Harden Everything” security infrastructure. If you need help in implementing Teams Direct Routing or a security infrastructure for your organization, please contact us!

Bibliography

AudioCodes has written documents addressing security on their Session Border Controllers and Gateways. There are versions for the 7.2 and 7.4 firmware in which they discuss the importance of setting up the SBC’s firewall rules:

The AudioCodes SBC user manuals can also be found in the Library section of the AudioCodes website.

Picture of John Miller

John Miller

Cloud Solutions Architect - eGroup | Enabling Technologies

Page Links
Contacts
Facebook Twitter Instagram Linkedin