Table Of Contents

Internal Firewall Deployments with Cisco TelePresence

Overview

Cisco Firewall Platforms

Firewall Deployment Options

Transparent versus Routed Mode

Equal versus Unequal Interface Security Levels

Network Address Translation (NAT)

Application Layer Protocol Inspection

TelePresence Protocol Requirements

Device Provisioning Flows

Dynamic Host Configuration Protocol (DHCP)

Domain Name System (DNS)

Configuration Download Protocols

Call Scheduling and Services Flows

Call Signaling Flows

Media Flows

Point-to-Point TelePresence Calls

Multipoint TelePresence Calls

Management Flows

HTTP, HTTPS, and SSH

SNMP Traps

ESE Firewall Test Results

Example Firewall Configuration

Internal Firewall Deployments with Cisco TelePresence

---

Overview

This chapter t discusses the deployment of Cisco TelePresence within an enterprise organization which may implement internal firewalling. Internal firewalling may be deployed within an organization for a number of reasons, including:

•Access control within an enterprise campus

Firewalling may be implemented within an enterprise campus in order to provide access control for a corporate department, division, or service module within the campus network. This may be done for regulatory or internal security reasons.

•Access control between enterprise campus locations

Firewalls may be implemented to provide NAT services between two campus locations. For example, when two companies merge, there may be a period of time where NAT is done due to an overlapping IP address space between the two sides of the company. Access control between the two campus locations may also be implemented if necessary.

•Access control from branch locations to corporate campus sites

Firewalling may be implemented at WAN aggregation points within an enterprise organization in order to restrict inbound access from branch locations to certain protocols and/or resources within the corporate campus locations. This may be done to enhance the trust boundary between the branch locations and the corporate campus.

•Access control within enterprise branch locations

Firewalling may be implemented within branch locations in order to restrict access to certain devices within a branch. An example would be the isolation of IP-based point-of-sale terminals within a store location.

Figure 13-1 shows the deployment of firewalling in these four areas in relation to a TelePresence deployment.

Figure 13-1 Internal Firewalling within an Enterprise Organization

The following flows may need to be enabled through the firewall in order to support the TelePresence deployment:

•Device provisioning flows between the Cisco Unified Communications Manager (CUCM) cluster and CTS endpoints in order to successfully bring the CTS endpoints onto the network and register with CUCM.

•Call scheduling and service flows between the CTS Manager and the CTS endpoints.

•Call signaling flows between CTS endpoints and the CUCM cluster in order to initiate and terminate TelePresence meetings.

•The actual audio and video media flows between CTS endpoints in a point-to-point call.

•The actual audio and video media flows between CTS endpoints and the Cisco TelePresence Multipoint Switch (CTMS) in a multipoint call.

•Flows between network management stations and the CTS endpoints to successfully manage the TelePresence deployment.

Cisco Firewall Platforms

Cisco currently provides three firewall product lines:

•ASA 5500 Series of firewall appliances

•IOS Firewall running on Cisco IOS router platforms

•Firewall Service Module (FWSM) for the Catalyst 6500 switches and Cisco 7600 Series routers

This chapter includes test results from the ASA 5500 Series of firewall appliances only. The recommendations do not apply to the FWSM or IOS Firewall, which have not been tested within the ESE lab.

The following firewall platform and software version was tested for the recommendations within this document:

•ASA5550, 4096 MB RAM, CPU Pentium 4 3000 MHz

•Software Version ASA722-K8

---

Note The Cisco PIX firewall series of appliances have not been tested since they have been replaced with the ASA 5500 Series of firewall appliances.

---

Firewall Deployment Options

The following sections discuss some of the options available when deploying a firewall within an Enterprise. Where appropriate, information regarding the affect of the choice of firewall deployment on TelePresence deployments is discussed.

Transparent versus Routed Mode

Firewalls such as the Cisco ASA 5500 Series can operate either as a Layer 2 (transparent mode) or a Layer 3 (routed mode) device. A firewall operating in transparent mode does not mean that access control decisions are made based upon Layer 2 MAC address information. Access control decisions are still made based upon Layer 3 and higher (in the case of Application Layer Protocol Inspection) information. A firewall operating in transparent mode has the same IP subnet on both sides of the firewall as shown in Figure 13-2. This is often beneficial for deploying firewalling in existing networks, since IP addressing does not have to be changed to insert the firewall.

Figure 13-2 Transparent Mode versus Routed Mode Firewall

A firewall operating in routed mode has different IP subnets on both sides of the firewall, as shown in Figure 13-2. This is the more traditional mode of operation of a firewall and was the only configuration tested and discussed within this document.

Equal versus Unequal Interface Security Levels

Firewalls such as the Cisco ASA 5500 Series operate based upon the concept of levels of trust within the network. This is reflected through security levels configured on firewall interfaces. Security levels range from 100, which is the most secure interface, to 0, which is the least secure interface. These are often referred to as the "inside" and "outside" interfaces on a firewall with only two interfaces.

By default, traffic initiated from a device on an interface with a higher security level is allowed to pass to a device on an interface with a lower security level. Return traffic corresponding to that session is dynamically allowed from the lower interface security level to the interface with the higher security level. Note that the term "session" can also apply to return UDP-based traffic, although there is no actual session as with TCP-based traffic. The use of symmetric port numbering in point-to-point TelePresence calls can actually provide a benefit when traversing firewalls due to this behavior. This is shown in Figure 13-3.

Figure 13-3 Symmetric TelePresence Ports and Firewalls

In Figure 13-3, since the UDP ports are symmetric, the video generated by the CTS endpoint on the interface with the lower security level appears as if it is the return traffic of the CTS endpoint on the higher security level and is therefore allowed back through the firewall. However, it should be noted that this symmetric use of ports does not necessarily hold for multipoint TelePresence calls.

By default, traffic initiated from a device on an interface with a lower security level is not allowed to pass to a device on an interface with a higher security level. This behavior can be modified with an ingress access-control list (ACL) on the lower security interface level. For example, in Figure 13-3, an ingress ACL on the interface with the lower security level is needed to allow both the primary codec and the associated IP phone of the CTS endpoint to register with the CUCM cluster via the SIP protocol. As well as an inbound ACL, static translations may need to be configured within the firewall to allow the devices on the "inside" network to be visible to the "outside" network.

Depending upon the firewall deployment, an ingress ACL applied to the interface with the higher security level may also be desired to limit traffic going from higher level security interfaces to interfaces with lower security levels.

Cisco ASA 5500 Series firewalls can also be allowed to operate with interfaces having equal security levels. By default traffic is not allowed to pass between interfaces having the same security level unless the same-security-traffic permit inter-interface global command is also configured within the firewall. Again, ingress ACLs applied on each interface and static translations can be used to specifically allow access between certain devices and protocols connected to interfaces with equal security levels.

TelePresence has been tested in point-to-point configurations using both unequal and unequal cost interface configurations on the ASA 5000 firewall. Specific protocols which may be required within ACLs are discussed in TelePresence Protocol Requirements.

Network Address Translation (NAT)

NAT is normally used to hide the internal IP addressing of an enterprise organization when accessing resources on the Internet. It is not utilized often in internal firewall deployments, unless overlapping IP address ranges exist within the enterprise. These could temporarily result from acquisitions and mergers between companies.

NAT utilizes the concept of dynamic address pools which are used to translate "local" addresses to "global" addresses, as well as individual static translations between devices on the "local" side and the "global" side. Figure 13-4 provides an example of one-sided NAT within a TelePresence deployment.

Figure 13-4 TelePresence Deployment with NAT

Note that in Figure 13-4, the access-control lists allowing appropriate inbound and outbound addresses and protocols are not shown in order to simplify the figure.

When deploying TelePresence within a one-sided NAT environment, static translations are need between the "inside" or "local" IP addresses of the CTS endpoint, associated IP 7970 Phone, the CUCM, and possibly the DNS server. These translate to the "global" IP addresses which are visible to the network on the "outside" interface. In this type of deployment, the "inside" network is aware of the entire IP address range of the "outside" network and proper IP routing must be configured for reachability. The "outside" network, however, is not aware of the "inside" IP addressing. All "inside" addresses are translated to "global" IP addresses by the firewall. Therefore, IP routing on the outside must only be able to reach the IP subnet of the "global" address pool. Note that many-to-one NAT, also referred to as Port Address Translation (PAT), does not work in this environment due to the requirements for static translations.

The ASA 5500 firewall also has an option for translating IP addresses within DNS replies. This allows the DNS server to be deployed on the "inside" of the NAT firewall and still correctly hand out IP addresses to devices "outside" the firewall. Modifications to the configuration of the CTS endpoint are also required for this configuration to operate correctly. The DNS server entry in CTS#2 needs to be configured to point to the "global" address of the DNS server (10.10.4.4 in the example above). The entry for the CUCM cluster configured in CTS#2 can utilize the hostname of the CUCM server. The DNS translation function of the firewall will ensure that the "local" CUCM address is translated to the "global" address before it is handed to CTS#2. Otherwise, the configuration of CTS#2 would have to be modified to include the "global" address of the CUCM server as well. An alternative to translation of DNS replies within the firewall is a split DNS implementation. In this configuration a DNS server is deployed on both sides of the firewall with the appropriate records for the particular addressing used on that side of the firewall. However, this method doubles the amount of administrative work in maintaining DNS across the enterprise.

Point-to-Point TelePresence has been tested in one-sided NAT configurations as well as non-NAT configurations.

Application Layer Protocol Inspection

Application layer protocol inspection is required for services that embed IP addressing information in user data sections of a packet or that open secondary channels on dynamically assigned ports. These protocols require the firewall to perform a deep packet inspection in order to extract such information. The Cisco TelePresence solution embeds IP addressing information within the SIP signaling between CTS endpoints and the CUCM cluster. SIP signaling is also used to dynamically specify the RTP audio and video media ports, which range from UDP port 16384 to 32677. The firewall therefore dynamically opens and closes the required audio and video media ports based upon inspection of the SIP signaling between the CTS endpoints and the CUCM cluster.

Without SIP inspection, the network administrator may have to statically open these UDP port ranges for the IP addresses corresponding to each CTS endpoint which needs to pass through the firewall. This presents a larger security vulnerability from a firewall perspective. Therefore, when possible, the use of application layer protocol inspection of SIP traffic for TelePresence deployments is recommended. Point-to-point TelePresence has been tested in configurations with and without application layer protocol inspection of SIP traffic.

Note also that DNS and TFTP application layer protocol inspection are enabled by default with the ASA 5500 Series of firewall appliances. It is recommended to leave these enabled.

TelePresence Protocol Requirements

The following sections discuss some of the protocols which may need to be enabled through a firewall, depending upon the configuration of the network and CTS endpoints. The discussion is geared toward identification of TelePresence protocol requirements based upon the following functions:

•Provisioning the devices onto the network

•Registering the devices with the CUCM

•Call scheduling and services flows

•Call signaling flows needed to initiate and terminate a TelePresence meeting

•Support of the actual media flows across the network

•Management of the devices on the network

Device Provisioning Flows

Device provisioning flows are the signaling and data flows needed by CTS endpoints to boot up and register with the CUCM cluster.

Dynamic Host Configuration Protocol (DHCP)

DHCP is used for dynamic IP address assignment. Client-sent DHCP packets have UDP source port 68 and destination port 67. Server-sent DHCP packets have UDP source port 67 and destination port 68. If both the primary codec of the CTS-endpoint as well as its associated IP phone use static IP addressing, then DHCP is not required. If either the primary codec or its associate IP phone use dynamic IP addressing, then DHCP may be required to pass through the firewall, depending upon the network configuration. Figure 13-5 shows three DHCP deployment options where no firewall ACL entries are needed to support TelePresence.

Figure 13-5 DHCP Deployments Not Requiring Firewall ACL Entries for TelePresence

The initial DHCP DISCOVERY packet is sent by the CTS endpoint to the IP broadcast address (255.255.255.255). Therefore either the DHCP server functionality must be local to the IP subnet or a router can be configured to provide DHCP relay functionality to a DHCP server on another IP subnet. As long as the DHCP server functionality is on the same side of the firewall, no ACL entries are needed for DHCP flows from TelePresence devices.

Figure 13-6 shows two DHCP deployment options where firewall ACL entries are needed to support TelePresence.

Figure 13-6 DHCP Deployments Requiring Firewall ACL Entries for TelePresence

Option 1 of Figure 13-6 shows that even if the firewall provides the DHCP server functionality, an ACL entry may be needed to allow the inbound DHCP DISCOVERY packet as well as further DHCP packet exchanges. If a router provides DHCP relay functionality to a DHCP server on the opposite side of a firewall, as shown in Option 2, an ACL entry may be needed to allow the relayed DHCP exchanged to occur as well.

Domain Name System (DNS)

DNS utilizes UDP port 53 for hostname to IP address resolution. When DHCP returns an IP address to a CTS endpoint, it can also provide further information, such as the CUCM cluster to which the CTS-endpoint must register and its configuration download server (typically the CUCM cluster again). This information can be provided in the form of IP addresses or hostnames. Note that DHCP typically also provides the IP address of the DNS server and the domain name of the CTS endpoint. Alternatively, the network administrator can statically configure either the IP address or hostnames of the CUCM cluster and configuration download server within the CTS endpoints. Regardless of which method used, if hostnames are provided to the CTS endpoint, DNS is required in order for the CTS endpoint to resolve the hostname to an IP address.

DHCP may be required to pass through the firewall, depending upon the network configuration. DNS queries are initiated by the CTS endpoints. Therefore, if the DNS server is located on the same side of the firewall as the CTS endpoint, no ACL entry may be needed for DNS. However, if the DNS server is located on the opposite side of the firewall from the CTS endpoint, an ACL entry allowing DNS queries from the CTS endpoint may be needed. These two deployment options are shown in Figure 13-7.

Figure 13-7 DNS support for TelePresence in a Firewall Deployment

---

Note As mentioned previously, application layer protocol inspection of DNS packets is on by default within the ASA 5500 Series of firewall appliances.

---

Configuration Download Protocols

Configuration download protocols include those needed by the CTS codecs as well as their attached IP phones to upgrade system load images and download device configuration files. The CUCM cluster often provides the download server functionality and is therefore the only example discussed within this chapter. Further, this section of the discussion assumes that the CUCM cluster is on the opposite side of the firewall from the CTS endpoint.

Trivial File Transfer Protocol (TFTP)

The IP 7970 Phone which serves as the user interface for TelePresence calls requires the TFTP protocol for downloading system images during upgrades as well as for downloading configuration files. TFTP servers listen on UDP port 69, but then dynamically assign a different port number for actual file transfers. Therefore, it is recommended to leave application layer protocol inspection enabled for TFTP within the firewall, which is the default for ASA 5500 Series firewall appliances. However, an ACL entry allowing the initial TFTP read request from the CTS endpoint to the CUCM cluster may be needed.

TCP Port 6970

Unlike IP phones, TelePresence codecs do not use TFTP for download of system images and configuration files. TelePresence codecs utilize HTTP over TCP port 6970 to download system images and configuration files. An ACL entry allowing the session to be initiated by the CTS endpoint on the opposite side of the firewall from the CUCM cluster may be required.

Figure 13-8 shows both protocols required by the CTS endpoints for system image upgrade and configuration download.

Figure 13-8 Configuration Download Protocol Support for TelePresence in a Firewall Deployment

SIP Registration

Once the CTS codec(s) and associated IP phone have completed downloading their configuration files, and possibly upgrading their system images, both perform a SIP registration with the CUCM cluster. SIP signaling uses either TCP or UDP port 5060. The connection-oriented nature of TCP makes it preferred for TelePresence deployments and is the only protocol discussed within this chapter. Note that this section of the discussion also assumes that the CUCM cluster is on the opposite side of the firewall from the CTS endpoint.

Since SIP REGISTER requests are initiated by the CTS primary codec and associated IP phone, ACL entries on the firewall which allow the inbound traffic may be required. Figure 13-9 shows the SIP protocol required for registration by both the CTS primary codec and associated IP phone.

Figure 13-9 SIP Registration Support for TelePresence in a Firewall Deployment

It should be noted that if additional IP phones which support the SCCP protocol exist on the firewall interface with the lower security level, then an ingress ACL entry on the firewall interface with the lower security level may be needed to allow such devices to register with CUCM. These may be utilized due to the audio add-on feature of TelePresence meetings.

Call Scheduling and Services Flows

Call scheduling flows are the data flows between the CTS Manager and CTS endpoints used to update the meeting schedule information which appears on the IP 7970 phone associated with the CTS endpoint. CTS Manager uses XML/SOAP in order to push scheduling information out to the CTS endpoints. CTS endpoints then push the content to the GUI interface of the phone via XML.

From a firewall perspective, since the session is initiated from the CTS Manager on the higher security level interface to the CTS endpoint on the lower security level interface, no ACL entry is needed to support the call scheduling information flows. This is shown inFigure 13-10.

Figure 13-10 Call Scheduling Flow Support for TelePresence in a Firewall Deployment

Call service flows include things such as directory lookup services available via the graphical user interface of the IP phone associated with the CTS endpoint. IP phones use XML over HTTP port 8080 to communicate with the CUCM cluster and potentially other servers to provide these services. This is shown in Figure 13-11.

Figure 13-11 Call Services Flows Support for TelePresence in a Firewall Deployment

Since these flows originate with the IP phone associated with the CTS endpoint or other IP phones which may be bridged onto a TelePresence meeting, an ingress ACL entry on the firewall interface with the lower security level may be required to allow these to pass through the firewall.

Call Signaling Flows

Call signaling flows are the SIP signaling (UDP and TCP Port 5060) flows between the CTS endpoints and the CUCM used to start, stop, and put calls on hold. From a firewall perspective, since SIP is already allowed through the firewall in order for the CTS endpoint to register with the CUCM cluster, no additional ACL entries are needed to support call signaling flows. This is shown in Figure 13-12.

Figure 13-12 Call Signaling Flow Support for TelePresence in a Firewall Deployment

Note that in Figure 13-12, outbound call signaling from the CUCM to the CTS endpoint on the opposite side of the firewall are automatically allowed from an interface with a higher security level to an interface with a lower security level.

Media Flows

Media flows are the actual RTP/UDP streams that carry the audio and video of the TelePresence meeting. Video streams from individual cameras are carried within individual RTP streams. Likewise, audio streams from individual microphones are carried within individual RTP streams. All of the audio RTP streams are multiplexed into a single audio UDP stream before being sent over the network. Likewise, all of the video RTP streams are multiplexed into a single video UDP stream before being sent over the network. In addition, RTCP control information for each audio and video stream is also multiplexed within each UDP stream. This eases firewall traversal, since only a single UDP audio stream and single UDP video stream is sent from a CTS endpoint.

There are slight variations in media flows between point-to-point TelePresence calls and multipoint TelePresence calls. Each is discussed individually.

Point-to-Point TelePresence Calls

In point-to-point TelePresence calls, the audio and video UDP streams flow directly between the CTS endpoints. Because there is only one UDP audio stream and one UDP video stream, the flows are symmetric, as shown in Figure 13-3. Therefore, TelePresence may be deployed without any ACL entry on the lower security interface which allows the inbound UDP media streams (typically UDP ports 16384 and 16388). This assumes no application-level inspection of SIP traffic to dynamically open media ports either. Once SIP signaling has completed, each CTS endpoint independently begins to send audio and video media. The audio and video media from the CTS endpoint on the lower security interface of the firewall are temporarily blocked by the firewall. However, when the audio and video media from the CTS endpoint on the higher security interface of the firewall passes through the firewall, it will dynamically allow the "reverse" traffic through. This unblocks the audio and video media from the CTS endpoint on the lower security interface of the firewall. Figure 13-13 shows this functionality.

Figure 13-13 Firewall Behavior with Symmetric TelePresence Flows

This behavior allows the network administrator to implement the firewall without having to open static RTP port ranges on the lower security interface, reducing the security vulnerability of the network. The network administrator can certainly configure an ingress ACL on the lower security interface allowing UDP ports 16384 and 16388 (or a larger range of ports from 16384 to 32677) if the initial blocking of video presents an issue.

However, despite this functionality, this configuration is not recommended. Instead, Cisco recommends enabling application-level protocol inspection of SIP traffic in order to allow the firewall to dynamically open and close the necessary UDP ports for the audio and video media. An example of this is shown in Figure 13-14.

Figure 13-14 TelePresence with SIP Application Level Protocol Inspection

Enabling SIP application level protocol inspection causes the firewall to inspect the SDP packets within SIP INVITE requests for the particular IP addresses and UDP ports required for audio and video media in each direction. The firewall continues to inspect any re-INVITES and inspects the SIP BYE message and dynamically closes the media ports as well.

---

Note Dynamically closing the media ports has been observed to cause temporary blocking of a large number of TelePresence audio and video media packets, since the codecs typically send SIP BYE messages before actually stopping the media flows.

---

Multipoint TelePresence Calls

In multipoint TelePresence calls, the audio and video UDP streams flow between the CTS endpoints and the CTMS. Again, there is only one UDP audio stream and one UDP video stream for each CTS endpoint. However, since the CTMS has a single IP address and has to support multiple UDP audio and video streams from multiple CTS endpoints, the flows are not necessarily symmetric from a UDP port numbering perspective. Therefore the network administrator may need to statically open a range of UDP ports to the IP address of the CTMS on the lower security interface of the firewall if SIP application-level protocol inspection is not utilized. However, as with point-to-point Telepresence, it is recommended to enable SIP application level protocol inspection in order to allow the firewall to dynamically open and close the necessary media ports.

Note that TelePresence has currently been tested only in a point-to-point configuration within the ESE test lab, both with and without SIP application level protocol inspection enabled.

Management Flows

Management flows are needed by management stations or end-user PCs to monitor, configure, and troubleshoot the CTS endpoints. CTS codecs currently support management connections utilizing the HTTPS and SSH protocols. The associated IP phone also supports management connections utilizing HTTP, HTTPS, and SSH protocols. In addition CTS codecs can be configured to send SNMP traps to a management station.

HTTP, HTTPS, and SSH

HTTP utilizes TCP port 80. HTTPS utilizes TCP port 443. SSH utilizes TCP port 23. Since all of these protocols are initiated from management stations on the interface with the higher security level toward the CTS endpoint on the interface with the lower security level, no ingress ACL entry is required on the firewall interface with the lower security level. This is shown in Figure 13-15.

Figure 13-15 Management Station Initiated Protocols

SNMP Traps

SNMP management stations typically listen on UDP Port 162 for SNMP traps. Since SNMP traps are unsolicited events from the CTS endpoints, an ingress ACL entry on the firewall interface with the lower security level may be needed to allow them to pass to the management server on the interface with the higher security level. This is shown in Figure 13-16.

Figure 13-16 CTS Endpoint Initiated Management Protocols

CTS endpoints and their associated IP7970 phones have also been observed to send ICMP Type 3 Code 3 (destination unreachable, port unreachable) packets to each other occasionally. It is not certain why these are sent, perhaps to inform the other side when the audio and video ports have been closed and to stop sending RTP traffic. Operation of TelePresence appears normal with these blocked. However, since they have been observed in firewall syslog output during testing, ICMP Type 3 (destination unreachable) packets may also need to be enabled through the firewall. Enabling SNMP through a firewall should be used with caution however.

ESE Firewall Test Results

Table 13-1 summarizes the results of ESE TelePresence testing in a point-to-point configuration with an ASA 5500 firewall.

Table 13-1 Firewall Configurations Evaluated

Firewall Mode	Interface Security Level	SIP Application Layer Protocol Inspection	One-Sided Address Translation	Results
Routed (Layer 3)	Unequal	Enabled	No NAT	Tested - Passed
			NAT	Tested - Passed
		Disabled	No NAT	Tested - Passed
			NAT	Tested - Failed
	Equal	Enabled	No NAT	Tested - Passed
			NAT	Not Tested
		Disabled	No NAT	Tested - Passed
			NAT	Not Tested

The operation of TelePresence through a firewall operating in transparent mode was not tested. For each of the routed mode firewall configurations tested above, various the call signaling and media flow scenarios were tested, including CTS endpoint reload and upgrade, call initiation from the CTS endpoint on either side of the firewall, and audio add-on of an IP phone on either side of the firewall.

Although for each firewall configuration, both voice and TelePresence traffic were configured into a priority queue on the firewall, no attempt was made at evaluating the performance of the firewall under traffic load. The results of such testing are highly dependent upon the amount and type of traffic traversing the firewall, the number of connections that need to be set up and torn down by the firewall, as well as the structure of the access-control lists allowing or denying traffic. Therefore, only the firewall signaling control plane was evaluated.

In all the tests with SIP application layer protocol level inspection enabled, only one minor issue was observed. If a TelePresence call is initiated by the CTS endpoint on the opposite side of the firewall from the CUCM, and the call is subsequently put on hold by the CTS endpoint on the same side of the firewall as the CUCM, the SIP signaling between the CUCM and the CTS endpoint on the opposite side of the firewall does not allow the firewall to correctly set up the necessary RTP pinhole connections to allow music-on-hold (MOH) between the CUCM server and the CTS endpoint. Firewall syslog output indicated RTP traffic from the CUCM destined for UDP port 16384 of the CTS endpoint was blocked. No music-on-hold was heard on the CTS endpoint. This is considered to be a minor issue and was only observed because an ingress ACL on the interface with the higher security level was used to determine specific ports required for TelePresence deployments through the firewall. The default behavior of a firewall which allows all flows from an interface with a higher security level to an interface with a lower security level would normally allow this to work correctly.

The test with unequal security levels on the interfaces, one-sided NAT, and SIP application level protocol inspection disabled failed during the CTS endpoint reload test and is therefore not a recommended configuration to support TelePresence.

Example Firewall Configuration

The following shows part of an example firewall configuration between CTS endpoints on two campuses as shown in Figure 13-17.

Figure 13-17 Example Firewall Configuration

The firewall for this example has been configured for routed mode operation, with unequal interface security levels, no NAT, and with SIP application layer protocol inspection enabled.

Interface Security Levels:

!

interface GigabitEthernet0/0

 description Connection to tp-c1-6500-2 Gig3/1

 speed 1000

 duplex full

 nameif CAMPUS

 security-level 50		! Higher security level

 ip address 10.16.7.2 255.255.255.0 

!

!

interface GigabitEthernet1/0

 description Connection to tp-c1-7200-1 Gig0/2

 speed 1000

 duplex full

 nameif WAN

 security-level 40		! Lower security level 

 ip address 10.16.8.2 255.255.255.0 

!

Static Xlates:

!

static (CAMPUS,WAN) tp-c1-server tp-c1-server netmask 255.255.255.255 dns 

! Allow the Campus 1 DNS server to be reachable from the lower security interface

static (CAMPUS,WAN) tp-c1-ct3000 tp-c1-ct3000 netmask 255.255.255.255 dns 

! Allow the Campus 1 TelePresence unit to be reachable from the lower security interface

static (CAMPUS,WAN) tp-c1-7960-1 tp-c1-7960-1 netmask 255.255.255.255 dns 

! Allow the Campus 1 IP7960 phone to be reachable from the lower security interface

static (CAMPUS,WAN) tp-c1-7970-1 tp-c1-7970-1 netmask 255.255.255.255 dns 

! Allow the Campus 1 IP7970 phone to be reachable from the lower security interface

static (CAMPUS,WAN) tp-c1-cm tp-c1-cm netmask 255.255.255.255 dns

! Allow CUCM to be reachable from the lower security interface

WAN ACL:

!

access-list NEW_WAN extended permit icmp any any unreachable

! Allow ICMP unreachables from all devices to be sent.  Not necessarily needed for 
TelePresence operation,  but

!  ICMP unreachables were observed in the firewall syslog output and added to the ACL.

access-list NEW_WAN extended permit tcp host tp-c2-ct3000 host tp-c1-cm eq sip 

access-list NEW_WAN extended permit tcp host tp-c2-7970-1 host tp-c1-cm eq sip 

access-list NEW_WAN extended permit tcp host tp-c2-7970-2 host tp-c1-cm eq sip 

! Allow SIP devices to register with CUCM

access-list NEW_WAN extended permit tcp host tp-c2-7960-1 host tp-c1-cm eq 2000 

! Allow SCCP devices to register with CUCM

access-list NEW_WAN extended permit udp host tp-c2-ct3000 host tp-c1-server eq domain 

access-list NEW_WAN extended permit udp host tp-c1-7960-1 host tp-c1-server eq domain 

access-list NEW_WAN extended permit udp host tp-c1-7970-1 host tp-c1-server eq domain 

access-list NEW_WAN extended permit udp host tp-c2-7970-2 host tp-c1-server eq domain 

! Allow devices to access the DNS server to translate names to valid IP addresses

access-list NEW_WAN extended permit udp host tp-c2-7970-1 host tp-c1-cm eq tftp 

access-list NEW_WAN extended permit udp host tp-c2-ct3000 host tp-c1-cm eq tftp 

access-list NEW_WAN extended permit udp host tp-c2-7960-1 host tp-c1-cm eq tftp 

access-list NEW_WAN extended permit udp host tp-c2-7970-2 host tp-c1-cm eq tftp

! Allow devices to access the TFTP server within CUCM for downloading of configuration and 
OS

access-list NEW_WAN extended permit tcp host tp-c2-7970-1 host tp-c1-cm eq 8080 

access-list NEW_WAN extended permit tcp host tp-c2-7960-1 host tp-c1-cm eq 8080

! Allow XML access from the IP Phones to CUCM

access-list NEW_WAN extended permit tcp host tp-c2-ct3000 host tp-c1-cm eq 6970

! TCP port used during firmware upgrades of the TelePresence CTS-3000 units. 

!

! Note: ACL entry for SNMP traps not included in this configuration.

!

Campus ACL:

!

access-list NEW_CAMPUS extended permit icmp any any unreachable 

! Allow ICMP unreachables from all devices to be sent.  Not necessarily needed for 
TelePresence operation,  but

!  ICMP unreachables were observed in the firewall syslog output and added to the ACL.

access-list NEW_CAMPUS extended permit udp host tp-c1-cm host tp-c2-ct3000 eq 16384

! Explicitly allows music-on-hold from CUCM to the CTS-3000.  Necessary currently because 
of a

! potential issue with SIP signaling on the TelePresence CTS-3000s when a call is placed 
on hold. 

access-list NEW_CAMPUS extended permit tcp host tp-c1-blaster host tp-c2-ct3000 eq https 

access-list NEW_CAMPUS extended permit tcp host tp-c1-blaster host tp-c2-ct3000 eq ssh 

access-list NEW_CAMPUS extended permit tcp host tp-c1-blaster host tp-c2-7960-1 eq www 

access-list NEW_CAMPUS extended permit tcp host tp-c1-blaster host tp-c2-7970-1 eq www 

access-list NEW_CAMPUS extended permit tcp host tp-c1-server host tp-c2-ct3000 eq https 

access-list NEW_CAMPUS extended permit tcp host tp-c1-server host tp-c2-ct3000 eq ssh 

access-list NEW_CAMPUS extended permit tcp host tp-c1-server host tp-c2-7960-1 eq www 

access-list NEW_CAMPUS extended permit tcp host tp-c1-server host tp-c2-7970-1 eq www 

! This section of allows background and management traffic.

!

! Note:  Typically no ACL would be utilized from the higher level security interface to 
the lower level security interface.

! The ACL was configured mostly for test purposes.  Actual deployments will not likely 
utilize ingress ACLs on the

! higher level security interface.

Application of ACLs Inbound on Interfaces:

!

access-group NEW_CAMPUS in interface CAMPUS

access-group NEW_WAN in interface WAN

!

Global Policy Which Includes SIP Application Specific Protocol Inspection:

!

policy-map type inspect dns migrated_dns_map_1

 parameters

  message-length maximum 512

!

policy-map asa_global_fw_policy

 class inspection_default

  inspect dns migrated_dns_map_1 

  inspect ftp 

  inspect h323 h225 

  inspect h323 ras 

  inspect netbios 

  inspect rsh 

  inspect rtsp 

  inspect http

  inspect esmtp 

  inspect sqlnet 

  inspect sunrpc 

  inspect tftp 

  inspect xdmcp 

  inspect sip 

  inspect skinny

! SIP, SCCP, TFTP and DNS application layer protocol inspection enabled. 

 !             

service-policy asa_global_fw_policy global

!