Table Of Contents

Configuring Cisco Unified Communications Proxy Features

Overview of the Adaptive Security Appliance in Cisco Unified Communications

TLS Proxy Applications in Cisco Unified Communications

Licensing for Cisco Unified Communications Proxy Features

Phone Proxy

About the Phone Proxy

Phone Proxy Limitations and Restrictions

Phone Proxy Configuration

Configuration Prerequisites

Requirements to Support the 7960 and 7940 IP Phones

Addressing Requirements for IP Phones on Multiple Interfaces

Supported Cisco UCM and IP Phones for the Phone Proxy

End-User Phone Provisioning

Configuring the Phone Proxy in a Non-secure Cisco UCM Cluster

Importing Certificates from the Cisco UCM

Configuring the Phone Proxy in a Mixed-mode Cisco UCM Cluster

Phone Proxy Configuration for Cisco IP Communicator

Configuring Linksys Routers for UDP Port Forwarding

About Rate Limiting TFTP Requests

Troubleshooting the Phone Proxy

Debugging Information from the Security Appliance

Debugging Information from IP Phones

IP Phone Registration Failure

Media Termination Address Errors

Audio Problems with IP Phones

Saving SAST Keys

TLS Proxy for Encrypted Voice Inspection

Overview

Configuring TLS Proxy

Debugging TLS Proxy

CTL Client

Cisco Unified Mobility and MMP Inspection Engine

Mobility Proxy Overview

Mobility Proxy Deployment Scenarios

Establishing Trust Relationships for Cisco UMA Deployments

Configuring the Security Appliance for Cisco Unified Mobility

Debugging for Cisco Unified Mobility

Cisco Unified Presence

Architecture for Cisco Unified Presence

Establishing a Trust Relationship in the Presence Federation

About the Security Certificate Exchange Between Cisco UP and the Security Appliance

Configuring the Presence Federation Proxy for Cisco Unified Presence

Debugging the Security Appliance for Cisco Unified Presence

Sample Configurations for Cisco Unified Communications Proxy Features

Phone Proxy Sample Configurations

Example 1: Nonsecure Cisco UCM cluster, Cisco UCM and TFTP Server on Publisher

Example 2: Mixed-mode Cisco UCM cluster, Cisco UCM and TFTP Server on Publisher

Example 3: Mixed-mode Cisco UCM cluster, Cisco UCM and TFTP Server on Different Servers

Example 4: Mixed-mode Cisco UCM cluster, Primary Cisco UCM, Secondary and TFTP Server on Different Servers

Example 5: LSC Provisioning in Mixed-mode Cisco UCM cluster; Cisco UCM and TFTP Server on Publisher

Example 6: VLAN Transversal

Cisco Unified Mobility Sample Configurations

Example 1: Cisco UMC/Cisco UMA Architecture - Security Appliance as Firewall with TLS Proxy and MMP Inspection

Example 2: Cisco UMC/Cisco UMA Architecture - Security Appliance as TLS Proxy Only

Cisco Unified Presence Sample Configuration

Configuring Cisco Unified Communications Proxy Features

---

This chapter describes how to configure the adaptive security appliance for Cisco Unified Communications Proxy features.

This chapter includes the following sections:

•Overview of the Adaptive Security Appliance in Cisco Unified Communications

•TLS Proxy Applications in Cisco Unified Communications

•Phone Proxy

•TLS Proxy for Encrypted Voice Inspection

•Cisco Unified Mobility and MMP Inspection Engine

•Cisco Unified Presence

•Sample Configurations for Cisco Unified Communications Proxy Features

Overview of the Adaptive Security Appliance in Cisco Unified Communications

This section describes the Cisco UC Proxy features on the Cisco ASA 5500 series appliances. The purpose of a proxy is to terminate and reoriginate connections between a client and server. The proxy delivers a range of security functions such as traffic inspection, protocol conformance, and policy control to ensure security for the internal network. An increasingly popular function of a proxy is to terminate encrypted connections in order to apply security policies while maintaining confidentiality of connections. The Cisco ASA 5500 Series appliances are a strategic platform to provide proxy functions for unified communications deployments.

The Cisco UC Proxy includes the following solutions:

Phone Proxy: Secure remote access for Cisco encrypted endpoints, and VLAN traversal for Cisco softphones

The phone proxy feature enables termination of Cisco SRTP/TLS-encrypted endpoints for secure remote access. The phone proxy allows large scale deployments of secure phones without a large scale VPN remote access hardware deployment. End-user infrastructure is limited to just the IP endpoint, without VPN tunnels or hardware.

The Cisco adaptive security appliance phone proxy is the replacement product for the Cisco Unified Phone Proxy. Additionally, the phone proxy can be deployed for voice/data VLAN traversal for softphone applications. Cisco IP Communicator (CIPC) traffic (both media and signaling) can be proxied through the security appliance, thus traversing calls securely between voice and data VLANs.

For information about the differences between the TLS proxy and phone proxy, go to the following URL for Unified Communications content, including TLS Proxy vs. Phone Proxy white paper:

http://www.cisco.com/go/secureuc

TLS Proxy: Decryption and inspection of Cisco Unified Communications encrypted signaling

End-to-end encryption often leaves network security appliances "blind" to media and signaling traffic, which can compromise access control and threat prevention security functions. This lack of visibility can result in a lack of interoperability between the firewall functions and the encrypted voice, leaving businesses unable to satisfy both of their key security requirements.

The security appliance is able to intercept and decrypt encrypted signaling from Cisco encrypted endpoints to the Cisco Unified Communications Manager (Cisco UCM), and apply the required threat protection and access control. It can also ensure confidentiality by re-encrypting the traffic onto the Cisco UCM servers.

Typically, the security appliance TLS Proxy functionality is deployed in campus unified communications network. This solution is ideal for deployments that utilize end to end encryption and firewalls to protect Unified Communications Manager servers.

Mobility Proxy: Secure connectivity between Cisco Unified Mobility Advantage server and Cisco Unified Mobile Communicator clients

Cisco Unified Mobility solutions include the Cisco Unified Mobile Communicator (Cisco UMC), an easy-to-use software application for mobile handsets that extends enterprise communications applications and services to mobile phones and the Cisco Unified Mobility Advantage (Cisco UMA) server. The Cisco Unified Mobility solution streamlines the communication experience, enabling single number reach and integration of mobile endpoints into the Unified Communications infrastructure.

The security appliance acts as a proxy, terminating and reoriginating the TLS signaling between the Cisco UMC and Cisco UMA. As part of the proxy security functionality, inspection is enabled for the Cisco UMA Mobile Multiplexing Protocol (MMP), the protocol between Cisco UMC and Cisco UMA.

Presence Federation Proxy: Secure connectivity between Cisco Unified Presence servers and Cisco/Microsoft Presence servers

Cisco Unified Presence solution collects information about the availability and status of users, such as whether they are using communication devices, such as IP phones at particular times. It also collects information regarding their communications capabilities, such as whether web collaboration or video conferencing is enabled. Using user information captured by Cisco Unified Presence, applications such as Cisco Unified Personal Communicator and Cisco UCM can improve productivity by helping users connect with colleagues more efficiently through determining the most effective way for collaborative communication.

Using the security appliance as a secure presence federation proxy, businesses can securely connect their Cisco Unified Presence (Cisco UP) servers to other Cisco or Microsoft Presence servers, enabling intra-enterprise communications. The security appliance terminates the TLS connectivity between the servers, and can inspect and apply policies for the SIP communications between the servers.

TLS Proxy Applications in Cisco Unified Communications

Table 26-1 shows the Cisco Unified Communications applications that utilize the TLS proxy on the security appliance.

Table 26-1 TLS Proxy Applications and the Security Appliance

Application	TLS Client	TLS Server	Client Authentication	Security Appliance Server Role	Security Appliance Client Role
Phone Proxy and TLS Proxy	IP phone	Cisco UCM	Yes	Proxy certificate, self-signed or by internal CA	Local dynamic certificate signed by the security appliance CA (might not need certificate for phone proxy application)
Mobility Proxy	Cisco UMC	Cisco UMA	No	Using the Cisco UMA private key or certificate impersonation	Any static configured certificate
Presence Federation Proxy	Cisco UP or MS LCS/OCS	Cisco UP or MS LCS/OCS	Yes	Proxy certificate, self-signed or by internal CA	Using the Cisco UP private key or certificate impersonation

The security appliance supports TLS proxy for various voice applications. For the phone proxy, the TLS proxy running on the security appliance has the following key features:

•The security appliance forces remote IP phones connecting to the phone proxy through the Internet to be in secured mode even when the Cisco UCM cluster is in non-secure mode.

•The TLS proxy is implemented on the security appliance to intercept the TLS signaling from IP phones.

•The TLS proxy decrypts the packets, sends packets to the inspection engine for NAT rewrite and protocol conformance, optionally encrypts packets, and sends them to Cisco UCM or sends them in clear text if the IP phone is configured to be in nonsecure mode on the Cisco UCM.

•The security appliance acts as a media terminator as needed and translates between SRTP and RTP media streams.

•The TLS proxy is a transparent proxy that works based on establishing trusted relationship between the TLS client, the proxy (the security appliance), and the TLS server.

For the Cisco Unified Mobility solution, the TLS client is a Cisco UMA client and the TLS server is a Cisco UMA server. The security appliance is between a Cisco UMA client and a Cisco UMA server. The mobility proxy (implemented as a TLS proxy) for Cisco Unified Mobility allows the use of an imported PKCS-12 certificate for server proxy during the handshake with the client. Cisco UMA clients are not required to present a certificate (no client authentication) during the handshake.

For the Cisco Unified Presence solution, the security appliance acts as a TLS proxy between the Cisco UP server and the foreign server. This allows the security appliance to proxy TLS messages on behalf of the server that initiates the TLS connection, and route the proxied TLS messages to the client. The security appliance stores certificate trustpoints for the server and the client, and presents these certificates on establishment of the TLS session.

Licensing for Cisco Unified Communications Proxy Features

The Cisco Unified Communications proxy features supported by the security appliance require a Unified Communications Proxy license:

•Phone proxy

•TLS proxy for encrypted voice inspection

•Mobility proxy

•Presence federation proxy

The Unified Communications proxy features are licensed by TLS session. For the phone proxy or TLS proxy, each IP phone may have a single connection to the Cisco UCM server or two connections —one connection to the primary Cisco UCM and one connection to the backup Cisco UCM. In the second scenario, the phone proxy uses two Unified Communications Proxy sessions because two TLS sessions are set up. For the mobility proxy and presence federation proxy, each endpoint utilizes one Unified Communications Proxy session.

Table 26-2 shows the Unified Communications Proxy license details by platform.

Table 26-2 License Requirements for the Security Appliance

Security Appliance Platform	Max UC Proxy Licenses	Tiers for UC Proxy Licenses
ASA 5505	24	24
ASA 5510	100	24, 50, 100
ASA 5520	1,000	24, 50, 100, 250, 500, 750, 1000
ASA 5540	2,000	24, 50, 100, 250, 500, 750, 1000, 2000
ASA 5550	3,000	24, 50, 100, 250, 500, 750, 1000, 2000, 3000

A Unified Communications Proxy license is applied the same way as other licensed features (such as, SSL VPN), via the activation-key command. To check the license on the security appliance, use the show version or show activation-key command:

hostname# show activation-key 

Serial Number:  P3000000179

Running Activation Key: 0xa700d24c 0x98caab35 0x88038550 0xaf383078 0x02382080 

Licensed features for this platform:

Maximum Physical Interfaces  : Unlimited 

Maximum VLANs                : 150       

Inside Hosts                 : Unlimited 

Failover                     : Active/Active

VPN-DES                      : Enabled   

VPN-3DES-AES                 : Enabled   

Security Contexts            : 10        

GTP/GPRS                     : Enabled   

VPN Peers                    : 750       

WebVPN Peers                 : 750       

AnyConnect for Mobile        : Disabled  

AnyConnect for Linksys phone : Disabled  

Advanced Endpoint Assessment : Enabled   

UC Proxy Sessions            : 1000       

This platform has an ASA 5520 VPN Plus license.

The flash activation key is the SAME as the running key.

hostname# 

See the following links for additional information on licensing. If you are a registered user of Cisco.com and would like to obtain a Unified Communications Proxy license, go to the following website:

http://www.cisco.com/go/license

If you are not a registered user of Cisco.com, go to the following website:

https://tools.cisco.com/SWIFT/Licensing/RegistrationServlet

Provide your name, e-mail address, and the serial number for the security appliance as it appears in the show version command output.

Phone Proxy

This section includes the following topics:

•About the Phone Proxy

•Phone Proxy Configuration

•Troubleshooting the Phone Proxy

About the Phone Proxy

The phone proxy on the security appliance bridges IP telephony between the corporate IP telephony network and the Internet in a secure manner by forcing data from remote phones on an untrusted network to be encrypted. Telecommuters can connect their IP phones to the corporate IP telephony network over the Internet securely via the phone proxy without the need to connect over a VPN tunnel as illustrated by Figure 26-1.

Figure 26-1 Phone Proxy Secure Deployment

The phone proxy supports a Cisco UCM cluster in mixed mode or nonsecure mode. Regardless of the cluster mode, the remote phones that are capable of encryption are always forced to be in encrypted mode. TLS (signaling) and SRTP (media) are always terminated on the security appliance. The security appliance can also perform NAT, open pinholes for the media, and apply inspection policies for the SCCP and SIP protocols. In a nonsecure cluster mode or a mixed mode where the phones are configured as nonsecure, the phone proxy behaves in the following ways:

•The TLS connections from the phones are terminated on the security appliance and a TCP connection is initiated to the Cisco UCM.

•SRTP sent from external IP phones to the internal network IP phone via the security appliance is converted to RTP.

In a mixed mode cluster where the internal IP phones are configured as authenticated, the TLS connection is not converted to TCP to the Cisco UCM but the SRTP is converted to RTP.

In a mixed mode cluster where the internal IP phone is configured as encrypted, the TLS connection remains a TLS connection to the Cisco UCM and the SRTP from the remote phone remains SRTP to the internal IP phone.

Since the main purpose of the phone proxy is to make the phone behave securely while making calls to a nonsecure cluster, the phone proxy performs the following major functions:

•Creates the certificate trust list (CTL) file, which is used to perform certificate based authentication with remote phones.

•Modifies the IP phone configuration file when it is requested via TFTP, changes security fields from nonsecure to secure, and signs all files sent to the phone. These modifications secure remote phones by forcing the phones to perform encrypted signaling and media.

•Terminates TLS signaling from the phone and initiates TCP or TLS to Cisco UCM

•Inserts itself into the media path by modifying the Skinny and SIP signaling messages.

•Terminates SRTP and initiates RTP/SRTP to the called party.

Phone Proxy Limitations and Restrictions

The phone proxy has the following limitations and restrictions:

•Packets from phones connecting to the phone proxy over a VPN tunnel are not inspected by the security appliance inspection engines.

•The phone proxy is not supported when the security appliance is running in transparent mode or multimode.

•The phone proxy does not support IP phones sending Real-Time Control Protocol (RTCP) packets through the security appliance. Disable RTCP packets in the Cisco Unified CM Administration console from the Phone Configuration page. See your Cisco Unified Communications Manager (CallManager) documentation for information about setting this configuration option.

•The phone proxy does not support IP phones sending SCCP video messages using Cisco VT Advantage because SCCP video messages do not support SRTP keys.

Phone Proxy Configuration

This section includes the following topics:

•Configuration Prerequisites

•Requirements to Support the 7960 and 7940 IP Phones

•Addressing Requirements for IP Phones on Multiple Interfaces

•Supported Cisco UCM and IP Phones for the Phone Proxy

•End-User Phone Provisioning

•Configuring the Phone Proxy in a Non-secure Cisco UCM Cluster

•Importing Certificates from the Cisco UCM

•Configuring the Phone Proxy in a Mixed-mode Cisco UCM Cluster

•Phone Proxy Configuration for Cisco IP Communicator

•Configuring Linksys Routers for UDP Port Forwarding

Configuration Prerequisites

Before configuring the phone proxy, ensure that the security appliance meets the following configuration requirements:

•The security appliance must have an IP address for media termination that meets the following criteria:

–The IP address is a publicly routable address that is an unused IP address within an address range associated with the outside network interface on the security appliance.

–The IP address cannot be the same address of an interface on the security appliance. This includes using the IP address of the external interface on the security appliance to which remote IP phones connect.

–The IP address cannot overlap with existing static NAT pools or NAT rules.

–The IP address cannot be the same as the Cisco UCM or TFTP server IP address.

–For IP phones behind a router or gateway, add routes to the media termination address on the router or gateway so that the phone can reach the media termination address.

---

Note If your organization security policy dictates that IP phones on internal networks must not have routes to external networks, we recommended that you use a Unified-Communications-aware NAT device on the internal network. By representing the media termination address with an address within the internal network address range, you do not need to expose the internal IP phones to external routes.

---

•The TFTP server must reside on the same interface as the Cisco UCM.

•If you have an fully qualified domain name (FQDN) configured for the Cisco UCM rather than an IP address, you must configure and enable DNS lookup on the security appliance. For information about the dns domain-lookup command and how to use it to configure DNS lookup, see Cisco Security Appliance Command Reference.

After configuring the DNS lookup, make sure that the security appliance can ping the Cisco UCM with the configured FQDN.

If you have a CAPF service enabled and the Cisco UCM is not running on the Publisher, and the Publisher is configured with a FQDN instead of an IP address, you must also configure DNS lookup.

•Access-list rules must be configured to allow TFTP requests.

Table 26-3 lists the access-list rule that must be configured for TFTP on the security appliance:

Table 26-3 Access List Rule for TFTP

Address	Port	Protocol	Description
TFTP Server	69	UDP	Allow incoming TFTP

---

Note 3804 is the default value for the CAPF Service. This default value should be modified if it is modified on the Cisco UCM. If NAT is configured for the TFTP server or Cisco UCMs, the translated "global" address must be used in the access lists.

---

For information about configuring access-lists on the security appliance, see Access List Overview, page 17-1.

•If the phone proxy is deployed behind an existing firewall, access-list rules to permit signaling, TFTP, and media traffic to the phone proxy must be configured. If NAT is required for Cisco UCM, it must be configured on the security appliance, not on the existing firewall.

Table 26-4 lists the ports that are required to be configured on the existing firewall:

Table 26-4 Port Configuration Requirements

Address	Port	Protocol	Description
Media Termination	1024-65535	UDP	Allow incoming SRTP
TFTP Server	69	UDP	Allow incoming TFTP
Cisco UCM	2443	TCP	Allow incoming secure SCCP
Cisco UCM	5061	TCP	Allow incoming secure SIP
CAPF Service (on Cisco UCM)	3804	TCP	Allow CAPF service for LSC provisioning

---

Note All these ports are configurable on the Cisco UCM, except for TFTP. These are the default values and should be modified if they are modified on the Cisco UCM. If NAT is configured for the TFTP server or Cisco UCMs, the translated "global" address must be used in the access lists.

---

•If NAT is configured for the TFTP server, the NAT configuration must be configured prior to configuring the tftp-server command under the phone proxy.

•The Cisco UCM can be on a private network on the inside but you need to have a static mapping for the Cisco UCM on the security appliance to a public routable address.

•The following PAT configuration requirements must be met for the phone proxy:

–When the Skinny inspection global port is configured to use a non-default port, then you must configure the nonsecure port as the global_sccp_port+443.

Therefore, if global_sccp_port is 7000, then the global secure SCCP port is 7443. Reconfiguring the port might be necessary when the phone proxy deployment has more than one Cisco UCM and they must share the interface IP address or a global IP address:

/* use the default ports for the first CUCM */

static (inside,outside) tcp interface 2000 10.0.0.1 2000

static (inside,outside) tcp interface 2443 10.0.0.1 2443

/* use non-default ports for the 2nd CUCM */

static (inside,outside) tcp interface 7000 10.0.0.2 2000

static (inside,outside) tcp interface 7443 10.0.0.2 2443

---

Note Both PAT configurations—for the nonsecure and secure ports—must be configured.

---

–When the IP phones must contact the CAPF on the Cisco UCM and the Cisco UCM is configured with static PAT (LCS provisioning is required), you must configure static PAT for the default CAPF port 3804.

Requirements to Support the 7960 and 7940 IP Phones

To support the 7960 and 7940 IP phones with the phone proxy, you must meet the following requirements:

•An LSC must be installed on these IP phones because they do not come pre installed with a MIC. Install the LSC on each phone before using them with the phone proxy to avoid opening the nonsecure SCCP port for the IP phones to register in nonsecure mode with the Cisco UCM.

See the following document for the steps to install an LSC on IP phones:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/7_0_1/secugd/secucapf.html#wp1093518

---

Note If an IP phone already has an LSC installed on it from a different Cisco UCM cluster, delete the LSC from the different cluster and install an LSC from the current Cisco UCM cluster.

---

•The CAPF certificate must be imported onto the security appliance.

•The CTL file created on the security appliance must be created with a CAPF record-entry.

•The phone must be configured to use only the SCCP protocol because the SIP protocol does not support encryption on these IP phones.

•If LSC provisioning is done via the phone proxy, you must add an ACL to allow the IP phones to register with the Cisco UCM on the nonsecure port 2000.

Addressing Requirements for IP Phones on Multiple Interfaces

When IP phones reside on multiple interfaces, the phone proxy configuration must have the correct IP address set for the Cisco UCM in the CTL file.

See the following example topology for information about how to correctly set the IP address:

phones --- (dmz)-----|

             |----- ASA PP --- (outside Internet) --- phones

phones --- (inside)--|

In this example topology, the following IP address are set:

•Cisco UCM on the inside interface is set to 10.0.0.5

•The DMZ network is 192.168.1.0/24

•The inside network is 10.0.0.0/24

The Cisco UCM is mapped with different global IP addresses from DMZ > outside and inside interfaces > outside interface.

In the CTL file, the Cisco UCM must have two entries because of the two different IP addresses. For example, if the static statements for the Cisco UCM are as follows:

static (inside,outside) 128.106.254.2 10.0.0.5

static (inside,dmz) 192.168.1.2 10.0.0.5

There must be two CTL file record entries for the Cisco UCM:

record-entry cucm trustpoint cucm_in_to_out address 128.106.254.2

record-entry cucm trustpoint cucm_in_to_dmz address 192.168.1.2

Supported Cisco UCM and IP Phones for the Phone Proxy

Cisco Unified Communications Manager

The following release of the Cisco Unified Communications Manager are supported with the phone proxy:

•Cisco Unified CallManager Version 4.x

•Cisco Unified CallManager Version 5.x

•Cisco Unified Communications Manager 6.x

•Cisco Unified Communications Manager 7.x

Cisco Unified IP Phones

The following IP phones in the Cisco Unified IP Phones 7900 Series are supported with the phone proxy:

•Cisco Unified IP Phone 7975

•Cisco Unified IP Phone 7971

•Cisco Unified IP Phone 7970

•Cisco Unified IP Phone 7965

•Cisco Unified IP Phone 7962

•Cisco Unified IP Phone 7961

•Cisco Unified IP Phone 7961G-GE

•Cisco Unified IP Phone 7960 (SCCP protocol support only)

•Cisco Unified IP Phone 7945

•Cisco Unified IP Phone 7942

•Cisco Unified IP Phone 7941

•Cisco Unified IP Phone 7941G-GE

•Cisco Unified IP Phone 7940 (SCCP protocol support only)

•Cisco Unified Wireless IP Phone 7921

•CIPC for softphones ( CIPC versions with Authenticated mode only)

---

Note The Cisco IP Communicator is supported with the phone proxy VLAN Traversal in authenticated TLS mode. We do not recommend it for remote access because SRTP/TLS is not supported currently on the Cisco IP Communicator.

---

End-User Phone Provisioning

The phone proxy is a transparent proxy with respect to the TFTP and signaling transactions. If NAT is not configured for the Cisco UCM TFTP server, then the phone needs to be configured with the Cisco UCM cluster TFTP server address.

If NAT is configured for the Cisco UCM TFTP server, then the Cisco UCM TFTP server global address is configured as the TFTP server address on the phone.

•Option 1 (Recommended) - Stage the IP phones at corporate headquarters before sending them to the end users:

–The phones register inside the network. IT ensures there are no issues with the phone configurations, image downloads, and registration.

–If Cisco UCM cluster was in mixed mode, the CTL file should be erased before sending the phone to the end user.

–Advantages of this option are:

· Easier to troubleshoot and isolate problems with the network or phone proxy because you know whether the phone is registered and working with the Cisco UCM.

· Better user experience because the phone does not have to download firmware from over a broadband connection, which can be slow and require the user to wait for a longer time.

•Option 2 - Send the new phone to the end user

–The user must be provided instructions to change the settings on phones with the appropriate Cisco UCM and TFTP server IP address.

In both options, deploying a remote IP phone behind a commercial Cable/DSL router with NAT capabilities is supported.

Configuring the Phone Proxy in a Non-secure Cisco UCM Cluster

---

Step 1 Create trustpoints and generate certificates for each entity in the network (Cisco UCM, Cisco UCM and TFTP, TFTP server, CAPF) that the IP phone must trust. The certificates are used in creating the CTL file.

You need to create trustpoints for each Cisco UCM (primary and secondary if a secondary Cisco UCM is used) and TFTP server in the network. The trustpoints need to be in the CTL file for the phones to trust the Cisco UCM.

a. Create a keypair that can be used for the trustpoints by entering the following command:

hostname(config)# crypto key generate rsa label key-pair-label modulus size

b. Create the trustpoints for each Cisco UCM (primary and secondary) by entering the following commands:

hostname(config)# crypto ca trustpoint trustpoint_name

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# keypair keyname

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca enroll trustpoint

Entering these commands generates a self-signed certificate and specifies the keypair whose public key is being certified. This is the keypair created in substep a. Entering the crypto ca enroll command requests the certificate from the CA server and causes the security appliance to generate the certificate.

c. Create the trustpoint for the TFTP server by entering the following commands:

hostname(config)# crypto ca trustpoint trustpoint_name

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# keypair keyname

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca enroll trustpoint

---

Note You are only required to perform this step when the TFTP server resides on a different server from the Cisco UCM. See Example 3: Mixed-mode Cisco UCM cluster, Cisco UCM and TFTP Server on Different Servers for an example of this configuration.

---

d. When prompted to include the device serial number in the subject name, type Y to include the serial number or type N to exclude it.

e. When prompted to generate the self-signed certificate, type Y.

f. Import the following certificates which are stored on the Cisco UCM. These certificates are required by the security appliance for the phone proxy.

•Cisco_Manufacturing_CA

•CAP-RTP-001

•CAP-RTP-002

See Importing Certificates from the Cisco UCM. For example, the CA Manufacturer certificate is required by the phone proxy to validate the IP phone certificate.

g. (Optional) If LSC provisioning is required or you have LSC enabled IP phones, you must import the CAPF certificate from the Cisco UCM. See Importing Certificates from the Cisco UCM.

---

Note If the Cisco UCM has more than one CAPF certificate, you must import all of them to the security appliance.

---

Step 2 Create the CTL file that will be presented to the IP phones during the TFTP. The address here must be the translated or global address of the TFTP server or Cisco UCM if NAT is configured.

a. If you are using domain names for your Cisco UCM and TFTP server, you must configure DNS lookup on the security appliance. Add an entry for each of the outside interfaces on the security appliance into your DNS server, if such entries are not already present. Each security appliance outside IP address should have a DNS entry associated with it for lookups. These DNS entries must also be enabled for Reverse Lookup. Enable DNS lookups on your security appliance with the dns domain-lookup interface_name command (where the interface_name specifies the interface that has a route to your DNS server). Additionally, define your DNS server IP address on the security appliance; for example: dns name-server 10.2.3.4 (IP address of your DNS server).

---

Note You can enter the dns domain-lookup command multiple times to enable DNS lookup on multiple interfaces. If you enter multiple commands, the security appliance tries each interface in the order it appears in the configuration until it receives a response.

---

b. Create the CTL file instance by entering the following command:

hostname(config)# ctl-file ctl_name

c. Create the record entry for the TFTP server by entering the following command. Use the global or mapped IP address of the TFTP server.

hostname(config-ctl-file)# record-entry tftp trustpoint trustpoint_name address 
TFTP_IP_address

d. Create the record entry for the each Cisco UCM (primary and secondary) by entering the following command. Use the global or mapped IP address of the Cisco UCM.

hostname(config-ctl-file)# record-entry cucm trustpoint trustpoint_name address 
IP_address

e. (Optional) If LSC provisioning is or you have LSC enabled IP phones, create the record entry for CAPF by entering the following command:

hostname(config-ctl-file)# record-entry capf trustpoint trust_point address

f. Create the CTL file by entering the following command:

hostname(config-ctl-file)# no shutdown

When the file is created, it creates an internal trustpoint used by the phone proxy to sign the TFTP files. The trustpoint is named _internal_PP_ctl-instance_filename.

g. Save the certificate configuration to Flash memory by entering the following command:

hostname(config)# copy running-configuration startup-configuration

Step 3 Create the TLS proxy instance to handle the encrypted signaling.

a. Create the TLS proxy instance by entering the following command:

hostname(config)# tls-proxy proxy_name

b. Configure the server trustpoint and reference the internal trustpoint named _internal_PP_ctl-instance_filename:

hostname(config-tlsp)# server trust-point _internal_PP_ctl-instance_filename

Step 4 Configure the phone proxy instance.

a. Create the CTL file instance:

hostname(config)# phone-proxy phone_proxy_name

b. Configure the media-termination address used by the phone-proxy for SRTP and RTP by entering the following command:

hostname(config-phone-proxy)# media-termination address ip_address

---

Note•For the media termination address, you must select a publicly routable IP address that is an unused IP address on an attached outside network to the security appliance interface that will never be used by another device in your network.

•Specifically, the media termination address cannot be the same as any security appliance interface IP address, cannot overlap with existing static NAT rules, and cannot be the same as the Cisco UCM or TFTP server IP address.

•For IP phones behind a router or gateway, add routes to the media termination address on the router or gateway so that the phone can reach the media termination address.

---

c. Create the TFTP server using the actual internal address and specify the interface on which the TFTP server resides by entering the following command:

hostname(config-phone-proxy)# tftp-server address ip_address interface interface

d. Configure the TLS proxy instance created in Step 3 by entering the following command:

hostame(config-phone-proxy)# tls-proxy proxy_name

e. Configure the CTL file instance created in Step 2 by entering the following command:

hostname(config-phone-proxy)# ctl-file ctl_name

f. (Optional) If the operational environment has an external HTTP proxy to which the IP phones direct all HTTP request, enter the following command to configure a proxy server on the security appliance:

hostname(config-phone-proxy)# proxy-server address ip_address [listen_port] interface 
ifc

You can configure only one proxy server while the phone proxy is in use; however, if the IP phones have already downloaded their configuration files after you have configured the proxy server, you must restart the IP phones so that they get the configuration file with the proxy server address in the file.

By default, the Phone URL Parameters configured under the Enterprise Parameters use an FQDN in the URLs. The parameters might need to be changed to use an IP address if the DNS lookup for the HTTP proxy does not resolve the FQDNs.

g. (Optional) To force Cisco IP Communicator (CIPC) softphones to operate in authenticated mode when CIPC softphones are deployed in a voice and data VLAN scenario, enter the following command:

hostname(config-phone-proxy)# cipc security-mode authenticated

See Phone Proxy Configuration for Cisco IP Communicator for all requirements for using the phone proxy with CIPC.

h. (Optional) To preserve the settings configured on the Cisco UCM for each IP phone configured, enter the following command:

hostname(config-phone-proxy)# no disable service-settings

By default, the following settings are disabled on the IP phones:

–PC Port

–Gratuitous ARP

–Voice VLAN access

–Web Access

–Span to PC Port

Step 5 Enable the phone proxy with SIP and Skinny inspection.

a. Configure the secure Skinny class of traffic to inspect by entering the following commands:

hostname(config)# class-map class_map_name

hostname(config-cmap)# match port tcp eq 2443

Where class_map_name is the name of the Skinny class map.

b. Configure the secure SIP class of traffic to inspect by entering the following commands:

hostname(config)# class-map class_map_name

hostname(config-cmap)# match port tcp eq 5061

Where class_map_name is the name of the SIP class map.

c. Configure the policy map and attach the action to the class of traffic by entering the following commands:

hostname(config)# policy-map name

hostname(config-pmap)# class classmap-name

hostname(config-pmap-c)# inspect skinny phone-proxy pp_name

hostnae(config-pmap)# class classmap-name

hostname(config-pmap-c)# inspect sip phone-proxy pp_name

Where classmap_name is the name of the Skinny class map and the name for the SIP class map.

d. Enable the policy on the outside interface by entering the following command:

hostname(config)# service-policy policymap_name interface intf

---

Importing Certificates from the Cisco UCM

For the TLS proxy used by the phone proxy to complete the TLS handshake successfully, it needs to verify the certificates from the IP phone (and the Cisco UCM if doing TLS with Cisco UCM). To validate the IP phone certificate, we need the CA Manufacturer certificate which is stored on the Cisco UCM. Follow these steps to import the CA Manufacturer certificate to the security appliance.

---

Step 1 Go to the Cisco UCM Operating System Administration web page.

Step 2 Choose Security > Certificate Management.

---

Note Earlier versions of Cisco UCM have a different UI and way to locate the certificates. For example, in Cisco UCM version 4.x, certificates are located in the directory C:\Program Files\Cisco\Certificates. See your Cisco Unified Communications Manager (CallManager) documentation for information about locating certificates.

---

Step 3 Click Find and it will display all the certificates.

Step 4 Find the filename Cisco_Manufacturing_CA. This is the certificate need to verify the IP phone certificate. Click the .PEM file Cisco_Manufacturing_CA.pem. This will show you the certificate information and a dialog box that has the option to download the certificate.

---

Note If the certificate list contains more than one certificate with the filename Cisco_Manufacturing_CA, make you select the certificate Cisco_Manufacturing_CA.pem—the one with the .pem file extension.

---

Step 5 Click Download and save the file as a text file.

Step 6 On the security appliance, create a trustpoint for the Cisco Manufacturing CA and enroll via terminal by entering the following commands. Enroll via terminal because you will paste the certificate you downloaded in Step 4.

hostname(config)# crypto ca trustpoint trustpoint_name

hostname(config-ca-trustpoint)# enrollment terminal

Step 7 Authenticate the trustpoint by entering the following command:

hostname(config)# crypto ca authenticate trustpoint

Step 8 You are prompted to "Enter the base 64 encoded CA Certificate." Copy the .PEM file you downloaded in Step 4 and paste it at the command line. The file is already in base-64 encoding so no conversion is required. If the certificate is OK, you are prompted to accept it: "Do you accept this certificate? [yes/no]." Enter yes.

---

Note When you copy the certificate, make sure that you also copy also the lines with BEGIN and END.

---

---

Tip If the certificate is not ok, use the debug crypto ca command to show debug messages for PKI activity (used with CAs).

---

Step 9 Repeat the Step 1 through Step 8 for the next certificate. Table 26-5 shows the certificates that are required by the security appliance.

Table 26-5 Certificates Required by the Security Appliance for the Phone Proxy

Certificate Name	Required for...
CallManager	Authenticating the Cisco UCM during TLS handshake; only required for mixed-mode clusters.
Cisco_Manufacturing_CA	Authenticating IP phones with a Manufacturer Installed Certificate (MIC).
CAP-RTP-001	Authenticating IP phones with a MIC.
CAP-RTP-002	Authenticating IP phones with a MIC.
CAPF	Authenticating IP phones with an LSC.

---

Configuring the Phone Proxy in a Mixed-mode Cisco UCM Cluster

When the phone proxy is being configured to run in mixed-mode clusters, you have the following options:

•If the cluster is in mixed mode, the user has the option to use the existing CTL file to install the trustpoints.

•If a CTL file exists for the cluster, copy the CTL file to Flash memory and configure the security appliance to read from that CTL file. When you copy the CTL file to Flash memory, do not name the file CTLFile.tlv.

---

Step 1 Use an existing CTL file to install the trustpoints for each entity in the network (Cisco UCM, Cisco UCM and TFTP, TFTP server, CAPF) that the IP phones must trust. If you have an existing CTL file that contains the correct IP addresses of the entities (namely, the IP address that the IP phones use for the Cisco UCM or TFTP servers), you can be use it to create a new CTL file. Store a copy of the existing CTL file to Flash memory and rename it something other than CTLFile.tlv and continue to Step 2.

Or

Create trustpoints and generate certificates for each entity in the network (Cisco UCM, Cisco UCM and TFTP, TFTP server, CAPF) that the IP phones must trust by performing the following substeps:

a. Create the trustpoints for each Cisco UCM (primary and secondary) by entering the following commands:

hostname(config)# crypto ca generate rsa label keyname modulus 1024

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# keypair keyname

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca enroll trustpoint

Entering these commands generates a self-signed certificate and specifies the keypair whose public key is being certified. This is the keypair created in substep a. Entering the crypto ca enroll command requests the certificate from the CA server and causes the security appliance to generate the certificate.

b. Create the trustpoint for the TFTP server by entering the following commands:

hostname(config)# crypto ca trustpoint trustpoint_name

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# keypair keyname

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca enroll trustpoint

---

Note You are only required to perform this step when the TFTP server resides on a different server from the Cisco UCM. See Example 3: Mixed-mode Cisco UCM cluster, Cisco UCM and TFTP Server on Different Servers for an example of this configuration.

---

c. When prompted to include the device serial number in the subject name, type Y to include the serial number or type N to exclude it.

d. When prompted to generate the self-signed certificate, type Y.

e. Import the following certificates which are stored on the Cisco UCM. These certificates are required by the security appliance for the phone proxy.

•CallManager

•Cisco_Manufacturing_CA

•CAP-RTP-001

•CAP-RTP-002

See Importing Certificates from the Cisco UCM. For example, the CA Manufacturer certificate is required by the phone proxy to validate the IP phone certificate.

f. (Optional) If LSC provisioning is required or you have LSC enabled IP phones, you must import the CAPF certificate from the Cisco UCM. See Importing Certificates from the Cisco UCM.

---

Note If the Cisco UCM has more than one CAPF certificate, you must import all of them to the security appliance.

---

Step 2 Create the CTL file that will be presented to the phones during the TFTP. The address here must be the translated or global address of the TFTP server or Cisco UCM if NAT is configured.

a. If you are using domain names for your Cisco UCM and TFTP server, you must configure DNS lookup on the security appliance. Add an entry for each of the outside interfaces on the security appliance into your DNS server, if such entries are not already present. Each security appliance outside IP address should have a DNS entry associated with it for lookups. These DNS entries must also be enabled for Reverse Lookup. Enable DNS lookups on your security appliance with the command dns domain-lookup interface_name (where the interface_name specifies the interface that has a route to y