Forefront TMG is SIP-aware

Published: November 2009

Yariv Trabelsi – Senior SDE, Microsoft Forefront Edge Team

Rachel Aldams - Technical Writer


Voice over IP (VoIP) in offices is becoming more and more common, and it’s not hard to understand the reasons. Today, in the global economy era, offices are spread around the world, and telecommunication is becoming a significant part of daily operations, creating a growing need for advanced features like video calls, IM, and voice/video conferencing, which are problematic and expensive to implement by using traditional telephony.

Obviously, the main incentive to start using VoIP is pricing. VoIP offerings, with attractive prices- especially for international calls- are available everywhere. There are many reasons why VoIP is cheaper (I won’t list all of them in this posting); however, the main reason is the minimal operational cost achieved by using existing Internet infrastructure.

VoIP communications are transmitted via the Internet and therefore need to be allowed to pass through your firewall. I’ll explain the basic flow of a VoIP call based on Session Initiation Protocol (SIP), which is the most common protocol used today.

A SIP VoIP call is carried out using User Datagram Protocol (UDP), and incorporates two protocols: SIP for call establishment and termination, and Real Time Protocol (RTP) for media (audio and/or video). SIP can also be carried out using Transmission Control Protocol (TCP) but for the purpose of this post I will refer to SIP carried out using UDP.

VoIP network connections between two endpoints

Diagram 1 illustrates a call with one media channel opened (usually voice). However, some phones support additional media channels during a call, for example, a video call; during a video call, there will be two additional red lines between Bob and Alice, for video RTP and RTCP.

VoIP network connections using PBX

As you can see in diagram 2, the endpoints connect to two locations during this call: a connection from each endpoint to the PBX for signaling routing, and two direct connections between Bob and Alice for media. Some PBXs relay the media as well, for different reasons, in which case all the connections from the endpoints are to the PBX.

Enabling SIP calls in Forefront TMG

As you can see in diagrams 1 and 2, in order to allow a SIP call to pass through your firewall, you need to open three UDP connections between the two endpoints, one for signaling (SIP) and two for media (RTP and RTCP).To configure the firewall you will need to open three UDP connections between all the phones in the organization to the external network or PBX to the external network. These rules produce many security issues, for example opening a wide range of media ports to the external network and not to a specific address, because there are many implementations where the media relay or media gateway are spread around the world for quality reasons, in which case the media addresses are dynamic.

Next you will need to configure all your phones to use the port ranges you configured in the rules.

Now, to gather all the info about the SIP traffic, configure Forefront TMG, and configure all your phones, is not very straightforward and requires preliminary VoIP understanding. I can personally attest that troubleshooting firewall issues that way is a serious nightmare. Plus, configuring it this way is not very secure. Therefore, we developed a SIP filter to do the configuration for you.

Configuring VoIP using Forefront TMG SIP filter

The Forefront TMG SIP filter will do the entire configuration for you. The filter will also manage the opening and closing of the media connections automatically, based on the SIP transactions between allowed endpoints, and will ensure a quota of registrations and calls, in order to prevent DoS attacks.

Configuring VoIP with the Forefront TMG SIP filter is very easy and straightforward. We divided the usage of VoIP in organizations into two scenarios: a scenario where the organization owns a PBX, and a scenario where the organization is using a remote VoIP service and the PBX (or any other SIP proxy) is located remotely on the VoIP service provider network.

The base of this division is the understanding that when deploying VoIP in an organization that doesn’t own a PBX, you need to ensure that all the phones in the organization can access the VoIP provider and vice versa. If you own a PBX, you need to ensure that all the phones in and out of the organization can access the PBX and that the PBX can access other VoIP equipment as well.

Obviously, the deployments are different in most offices, but when you break them down it always start with whether you own a PBX or not.

Here are two images illustrating the basic deployments I mentioned above:

Centrex scenario

In diagram 3 we see a deployment where the organization doesn’t own a PBX, and phones in the organization are connected to the VoIP service provider. This scenario is most commonly referred to as SIP Centrex, and I will do so throughout this blog.

SIP truck scenario

In diagram 4 we see a deployment where the organization does own a PBX, which is located in different segment than the phones, and the organization’s phones are connected directly to it. You can also see that the PBX is connected to a VoIP service provider for long distance calls termination.

After this long intro you probably want to know how to configure our SIP filter. Ok, now let’s get down to the nitty-gritty.

To start the VoIP wizard, click the Configure VoIP button: Configure VoIP button

To configure a Centrex scenario (no PBX in the organization):

  1. Select the first radio button saying you don’t own a PBX.

    Centrex scenario: select SIP deployment option

  2. Select the location of your VoIP provider servers. We are allowing you to select External network, but it’s not recommended at all for security reasons. Instead, enter specific computer addresses.

    Centrex scenario: select VoIP servers location

  3. Select the networks in which your phones are located (usually Internal and VPN, but if you have phones in other networks, except the External network, you must add these networks as well).

    Centrex scenario: select internal phones network

After you click finish the wizard will add the following rules:

VoIP rules in Centrex scenario

In the screenshot above you see three rules created by the wizard:

  1. SIP signaling to allow SIP between the network where your phones are located and the VoIP service provider.

  2. Rules 1 and 2 are RTP (media traffic from Internal to External and vice versa)

There’s one thing I would like to emphasize: the RTP rules are not actually opening the connections between internal and external, the filter does it, on a call-by-call basis. The rules are there to allow RTP traffic after the filter opens the connections.

To configure a SIP Trunk scenario (your PBX is in the office):

  1. Select the second radio button saying you have a PBX in your organization.

    SIP Trunk scenario: select SIP deployment option

  2. The next dialog box basically allows you to select between three common deployment scenarios.

    SIP Trunk scenario: PBX deployment details

    1. The first scenario is your PBX is connected directly to the Public Switched Telephone Network (PSTN), and your phones are connected to the PBX via IP.

      PBX connected directly to the PSTN

    2. The second scenario is almost identical to the first one, with one big difference: your PBX is connected to a SIP trunk.

      PBX is connected to a SIP trunk

    3. The last scenario is somewhat strange, but there are providers who deploy it. In this deployment, every phone registered on your PBX is also registered on a hosted remote PBX by your PBX. The reasoning behind this is not very clear to me since I don’t see the need for the internal PBX. However, as far as I can see, the second registration (to the hosted service) is usually with a different phone number in the AOR, giving your office phone the ability to use another number, for example, in other countries.

      Internal PBX connected to hosted PBX and PRI

    Each of the deployments mentioned above has the ability to connect to:

    • Session Border Controller (SBC) - SBC is most commonly used for NAT traversal and/or media relay.

    • Voice gateway - Voice gateways are usually used to connect SIP traffic PSTN. Some PBXs can function as a gateway.

    The first two deployments (Internal PBX w/o SIP trunk) will create a rule to publish your PBX. This will allow external VoIP components to register or call on your PBX.

    Published PBXs have two main limitations you must be aware of:

    • May not work with external VoIP components behind a NAT, even if PBX has NAT traversal capabilities.

    • External components connecting to PBX must listen on the SIP protocol port (usually port 5060).

  3. Select SBC and/or gateway location. SBC should be configured as a computer in the external network, so that users behind a NAT in the external network can connect to the internal PBX.

    SIP Trunk scenario: external SBC server SIP Trunk scenario: SIP Gateway

  4. Define the internal PBX IP address.

    SIP Trunk scenario: internal PBX IP address

  5. If you selected SIP trunk you must enter SIP trunk server.

    SIP Trunk scenario: SIP trunk server

  6. Select the networks in which your phones are located (usually Internal and VPN, but if you have phones in other networks, except the external network, then you must add these networks as well).

    SIP Trunk scenario: phone network addresses

After you click finish the wizard will add the following rules:

VoIP rules in SIP Trunk scenario

In the screenshot above you see three rules created by the wizard:

  1. SIP publishing rule, because I selected a SIP trunk deployment.

  2. RTP rules enabling RTP between all the networks involved, including the SBC and gateway I selected.

  3. SIP rules enabling SIP between all the networks involved, including the SBC and gateway I selected.

Obviously, the rules may change, depending on your selection in step 2.