Cisco ASA 5500 Series Configuration Guide using ASDM, 6.3
Configuring the Cisco Phone Proxy Feature
Downloads: This chapterpdf (PDF - 538.0KB) The complete bookPDF (PDF - 22.37MB) | Feedback

Configuring the Cisco Phone Proxy

Table Of Contents

Configuring the Cisco Phone Proxy

Information About the Cisco Phone Proxy

Phone Proxy Functionality

Supported Cisco UCM and IP Phones for the Phone Proxy

Licensing Requirements for the Phone Proxy

Prerequisites for the Phone Proxy

Media Termination Instance Prerequisites

Certificates from the Cisco UCM

DNS Lookup Prerequisites

Cisco Unified Communications Manager Prerequisites

Access List Rules

NAT and PAT Prerequisites

Prerequisites for IP Phones on Multiple Interfaces

7960 and 7940 IP Phones Support

Cisco IP Communicator Prerequisites

Prerequisites for Rate Limiting TFTP Requests

Rate Limiting Configuration Example

End-User Phone Provisioning

Ways to Deploy IP Phones to End Users

Phone Proxy Guidelines and Limitations

General Guidelines and Limitations

Media Termination Address Guidelines and Limitations

Configuring the Phone Proxy

Task Flow for Configuring the Phone Proxy

Creating the CTL File

Adding or Editing a Record Entry in a CTL File

Creating the Media Termination Instance

Creating the Phone Proxy Instance

Adding or Editing the TFTP Server for a Phone Proxy

Configuring Linksys Routers with UDP Port Forwarding for the Phone Proxy

Configuring Your Router

Feature History for the Phone Proxy


Configuring the Cisco Phone Proxy


This chapter describes how to configure the adaptive security appliance for Cisco Phone Proxy feature.

This chapter includes the following sections:

Information About the Cisco Phone Proxy

Licensing Requirements for the Phone Proxy

Prerequisites for the Phone Proxy

Phone Proxy Guidelines and Limitations

Configuring the Phone Proxy

Feature History for the Phone Proxy

Information About the Cisco Phone Proxy

The Cisco Phone Proxy on the adaptive 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.

Phone Proxy Functionality

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 44-1.

Figure 44-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 adaptive security appliance. The adaptive 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 adaptive 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 adaptive 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.


Note As an alternative to authenticating remote IP phones through the TLS handshake, you can configure authentication via LSC provisioning. With LSC provisioning you create a password for each remote IP phone user and each user enters the password on the remote IP phones to retrieve the LSC.

Because using LSC provisioning to authenticate remote IP phones requires the IP phones first register in nonsecure mode, Cisco recommends LSC provisioning be done inside the corporate network before giving the IP phones to end-users. Otherwise, having the IP phones register in nonsecure mode requires the Administrator to open the nonsecure signaling port for SIP and SCCP on the adaptive security appliance.

See also the Cisco Unified Communications Manager Security Guide for information on Using the Certificate Authority Proxy Function (CAPF) to install a locally significant certificate (LSC).


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.0

Cisco Unified CallManager Version 5.1

Cisco Unified Communications Manager 6.1

Cisco Unified Communications Manager 7.0

Cisco Unified IP Phones

The phone proxy supports these IP phone features:

Enterprise features like conference calls on remote phones connected through the phone proxy

XML services


Note The phone proxy supports only the features described in the list above. All other IP phone features not described by this list are unsupported by the phone proxy.


The phone proxy does not support displaying the lock icon on IP phone screens. IP phones display the lock icon on the phone screen during encrypted calls. Even though the lock icon is not displayed on the screen, the IP phone call is still encrypted because the phone proxy encrypts calls by default.

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

Cisco Unified Wireless IP Phone 7925


Note To support Cisco Unified Wireless IP Phone 7925, you must also configure MIC or LSC on the IP phone so that it properly works with the phone proxy.


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.



Note The adaptive security appliance supports inspection of traffic from Cisco IP Phones running SCCP protocol version 19 and earlier.


Licensing Requirements for the Phone Proxy

The Cisco Phone Proxy feature supported by the adaptive security appliance require a Unified Communications Proxy license.

The following table shows the Unified Communications Proxy license details by platform:

Model
License Requirement

ASA 5505

Base License and Security Plus License: 2 sessions1 .

Optional license: 24 sessions.

ASA 5510

Base License and Security Plus License: 2 sessions1.

Optional licenses: 24, 50, or 100 sessions.

ASA 5520

Base License: 2 sessions1.

Optional licenses: 24, 50, 100, 250, 500, 750, or 1000 sessions.

ASA 5540

Base License: 2 sessions1.

Optional licenses: 24, 50, 100, 250, 500, 750, 1000, or 2000 sessions.

ASA 5550

Base License: 2 sessions1.

Optional licenses: 24, 50, 100, 250, 500, 750, 1000, 2000, or 3000 sessions.

ASA 5580 and 5585-X

Base License: 2 sessions1.

Optional licenses: 24, 50, 100, 250, 500, 750, 1000, 2000, 3000, 5000, or 10,000 sessions.2

1 The following applications use TLS proxy sessions for their connections. Each TLS proxy session used by these applications (and only these applications) is counted against the UC license limit:
- Phone Proxy
- Presence Federation Proxy
- Encrypted Voice Inspection

Other applications that use TLS proxy sessions do not count towards the UC limit, for example, Mobility Advantage Proxy (which does not require a license) and IME (which requires a separate IME license).

Some UC applications might use multiple sessions for a connection. For example, if you configure a phone with a primary and backup Cisco Unified Communications Manager, there are 2 TLS proxy connections, so 2 UC Proxy sessions are used.

You independently set the TLS proxy limit using the Configuration > Firewall > Unified Communications > TLS Proxy pane. When you apply a UC license that is higher than the default TLS proxy limit, the adaptive security appliance automatically sets the TLS proxy limit to match the UC limit. The TLS proxy limit takes precedence over the UC license limit; if you set the TLS proxy limit to be less than the UC license, then you cannot use all of the sessions in your UC license.

Note: For license part numbers ending in "K8" (for example, licenses under 250 users), TLS proxy sessions are limited to 1000. For license part numbers ending in "K9" (for example, licenses 250 users or larger), the TLS proxy limit depends on the configuration, up to the model limit. K8 and K9 refer to whether the license is restricted for export: K8 is unrestricted, and K9 is restricted.

Note: If you clear the configuration, then the TLS proxy limit is set to the default for your model; if this default is lower than the UC license limit, then you see an error message to use the to raise the limit again (in ASDM, use the TLS Proxy pane). If you use failover and use File > Save Running Configuration to Standby Unit on the primary unit to force a configuration synchronization, the clear configure all command is generated on the secondary unit automatically, so you may see the warning message on the secondary unit. Because the configuration synchronization restores the TLS proxy limit set on the primary unit, you can ignore the warning.

You might also use SRTP encryption sessions for your connections:
- For K8 licenses, SRTP sessions are limited to 250.
- For K9 licenses, there is not limit.

Note: Only calls that require encryption/decryption for media are counted towards the SRTP limit; if passthrough is set for the call, even if both legs are SRTP, they do not count towards the limit.

2 With the 10,000-session license, the total combined sessions can be 10,000, but the maximum number of Phone Proxy sessions is 5000.


For more information about licensing, see Chapter 4 "Managing Feature Licenses."

Prerequisites for the Phone Proxy

This section contains the following topics:

Media Termination Instance Prerequisites

Certificates from the Cisco UCM

DNS Lookup Prerequisites

Cisco Unified Communications Manager Prerequisites

Access List Rules

NAT and PAT Prerequisites

Prerequisites for IP Phones on Multiple Interfaces

7960 and 7940 IP Phones Support

Cisco IP Communicator Prerequisites

Prerequisites for Rate Limiting TFTP Requests

End-User Phone Provisioning

Media Termination Instance Prerequisites

The adaptive security appliance must have a media termination instance that meets the following criteria:

You must configure one media termination for each phone proxy on the adaptive security appliance. Multiple media termination instances on the adaptive security appliance are not supported.

For the media termination instance, you can configure a global media-termination address for all interfaces or configure a media-termination address for different interfaces. However, you cannot use a global media-termination address and media-termination addresses configured for each interface at the same time.

If you configure a media termination address for multiple interfaces, you must configure an address on each interface that the adaptive security appliance uses when communicating with IP phones.

For example, if you had three interfaces on the adaptive security appliance (one internal interface and two external interfaces) and only one of the external interfaces were used to communicate with IP phones, you would configure two media termination addresses: one on the internal interface and one on the external interface that communicated with the IP phones.

Only one media-termination address can be configured per interface.

The IP addresses are publicly routable addresses that are unused IP addresses within the address range on that interface.

The IP address on an interface cannot be the same address as that interface on the adaptive security appliance.

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

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

For IP phones behind a router or gateway, you must also meet this prerequisite. On the router or gateway, add routes to the media termination address on the adaptive security appliance interface that the IP phones communicate with so that the phone can reach the media termination address.

Certificates from the Cisco UCM

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

Cisco_Manufacturing_CA

CAP-RTP-001

CAP-RTP-002

CAPF certificate (Optional)

If LSC provisioning is required or you have LSC enabled IP phones, you must import the CAPF certificate from the Cisco UCM. If the Cisco UCM has more than one CAPF certificate, you must import all of them to the adaptive security appliance.


Note You can configure LSC provisioning for additional end-user authentication. See the Cisco Unified Communications Manager configuration guide for information.


For example, the CA Manufacturer certificate is required by the phone proxy to validate the IP phone certificate.

DNS Lookup Prerequisites

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 adaptive security appliance.

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

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

Cisco Unified Communications Manager Prerequisites

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

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 adaptive security appliance to a public routable address.

If NAT is required for Cisco UCM, it must be configured on the adaptive security appliance, not on the existing firewall.

Access List Rules

If the phone proxy is deployed behind an existing firewall, access-list rules to permit signaling, TFTP requests, and media traffic to the phone proxy must be configured.

If NAT is configured for the TFTP server or Cisco UCMs, the translated "global" address must be used in the access lists.

Table 44-1 lists the ports that are required to be configured on the existing firewall:

Table 44-1 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. For example, 3804 is the default port for the CAPF Service. This default value should be modified if it is modified on the Cisco UCM.


NAT and PAT Prerequisites

NAT Prerequisites

If NAT is configured for the TFTP server, the NAT configuration must be configured prior to configuring the TFTP Server for the phone proxy.

If NAT is configured for the TFTP server or Cisco UCMs, the translated "global" address must be used in the access lists.

PAT Prerequisites

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.


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.

Prerequisites 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:

object network obj-10.0.0.5-01
host 10.0.0.5
nat (inside,outside) static 209.165.202.129
object network obj-10.0.0.5-02
host 10.0.0.5
nat (inside,dmz) static 198.168.1.2
 
   

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

record-entry cucm trustpoint cucm_in_to_out address 209.165.202.129
record-entry cucm trustpoint cucm_in_to_dmz address 192.168.1.2
 
   

7960 and 7940 IP Phones Support

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.



Note You can configure LSC provisioning for additional end-user authentication. See the Cisco Unified Communications Manager configuration guide for information.


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

The CTL file created on the adaptive 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.

Cisco IP Communicator Prerequisites

To configure Cisco IP Communicator (CIPC) with the phone proxy, you must meet the following prerequisites:

Go to Configuration > Firewall > Unified Communications > Phone Proxy and select the "Enable CICP security mode authentication" check box under the Call Manager and Phone Settings area.

Create an ACL to allow CIPC to register with the Cisco UCM in nonsecure mode.

Configure null-sha1 as one of the SSL encryption ciphers.

Current versions of Cisco IP Communicator (CIPC) support authenticated mode and perform TLS signaling but not voice encryption.

Because CIPC requires an LSC to perform the TLS handshake, CIPC needs to register with the Cisco UCM in nonsecure mode using cleartext signaling. To allow the CIPC to register, create an ACL that allows the CIPC to connect to the Cisco UCM on the nonsecure SIP/SCCP signalling ports (5060/2000).


Note You can configure LSC provisioning for additional end-user authentication. See the Cisco Unified Communications Manager configuration guide for information.


CIPC uses a different cipher when doing the TLS handshake and requires the null-sha1 cipher and SSL encryption be configured. To add the null-shal cipher, use the show run all ssl command to see the output for the ssl encryption command and add null-shal to the end of the SSL encryption list.


Note When used with CIPC, the phone proxy does not support end-users resetting their device name in CIPC (Preferences > Network tab > Use this Device Name field) or Administrators resetting the device name in Cisco Unified CM Administration console (Device menu > Phone Configuration > Device Name field). To function with the phone proxy, the CIPC configuration file must be in the format: SEP<mac_address>.cnf.xml. If the device name does not follow this format (SEP<mac_address>), CIPC cannot retrieve its configuration file from Cisco UMC via the phone proxy and CIPC will not function.


Prerequisites for Rate Limiting TFTP Requests

In a remote access scenario, we recommend that you configure rate limiting of TFTP requests because any IP phone connecting through the Internet is allowed to send TFTP requests to the TFTP server.

To configure rate limiting of TFTP requests, configure the police command in the Modular Policy Framework. See the Cisco ASA 5500 Series Command Reference for information about using the police command.

Policing is a way of ensuring that no traffic exceeds the maximum rate (in bits/second) that you configure, thus ensuring that no one traffic flow can take over the entire resource. When traffic exceeds the maximum rate, the adaptive security appliance drops the excess traffic. Policing also sets the largest single burst of traffic allowed.

Rate Limiting Configuration Example

The following example describes how you configure rate limiting for TFTP requests by using the police command and the Modular Policy Framework.

Begin by determining the conformance rate that is required for the phone proxy. To determine the conformance rate, use the following formula:

X * Y * 8
 
   

Where

X = requests per second

Y = size of each packet, which includes the L2, L3, and L4 plus the payload

Therefore, if a rate of 300 TFTP requests/second is required, then the conformance rate would be calculated as follows:

300 requests/second * 80 bytes * 8 = 192000
 
   

To control which hosts can ping the media termination address, create an ICMP rule. Go to Configuration > Device Management > Management Access > ICMP and click the Add button.

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 IP phones need 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 IP phones.

Ways to Deploy IP Phones to End Users

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

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 IP phone to the end user. When using option 2, the user must be provided instructions to change the settings on phones with the appropriate Cisco UCM and TFTP server IP address.


Note As an alternative to authenticating remote IP phones through the TLS handshake, you can configure authentication via LSC provisioning. With LSC provisioning you create a password for each remote IP phone user and each user enters the password on the remote IP phones to retrieve the LSC.

Because using LSC provisioning to authenticate remote IP phones requires the IP phones first register in nonsecure mode, Cisco recommends LSC provisioning be done inside the corporate network before giving the IP phones to end-users. Otherwise, having the IP phones register in nonsecure mode requires the Administrator to open the nonsecure signaling port for SIP and SCCP on the adaptive security appliance.

See also the Cisco Unified Communications Manager Security Guide for information on Using the Certificate Authority Proxy Function (CAPF) to install a locally significant certificate (LSC).


Phone Proxy Guidelines and Limitations

This section includes the following topics:

General Guidelines and Limitations

Media Termination Address Guidelines and Limitations

General Guidelines and Limitations

The phone proxy has the following general limitations:

Only one phone proxy instance can be configured on the adaptive security appliance by using the phone-proxy command. See the Cisco ASA 5500 Series Command Reference for information about the phone-proxy command. See also Creating the Phone Proxy Instance.

The phone proxy only supports one Cisco UCM cluster. See Creating the CTL File for the steps to configure the Cisco UCM cluster for the phone proxy.

The phone proxy is not supported when the adaptive security appliance is running in transparent mode or multiple context mode.

When a remote IP phone calls an invalid internal or external extension, the phone proxy does not support playing the annunciator message from the Cisco UCM. Instead, the remote IP phone plays a fast busy signal instead of the annunciator message "Your call cannot be completed ..." However, when an internal IP phone dials in invalid extension, the annunciator messages plays "Your call cannot be completed ..."

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

The phone proxy does not support IP phones sending Real-Time Control Protocol (RTCP) packets through the adaptive 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.

When used with CIPC, the phone proxy does not support end-users resetting their device name in CIPC (Preferences > Network tab > Use this Device Name field) or Administrators resetting the device name in Cisco Unified CM Administration console (Device menu > Phone Configuration > Device Name field). To function with the phone proxy, the CIPC configuration file must be in the format: SEP<mac_address>.cnf.xml. If the device name does not follow this format (SEP<mac_address>), CIPC cannot retrieve its configuration file from Cisco UMC via the phone proxy and CIPC will not function.

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.

For mixed-mode clusters, the phone proxy does not support the Cisco Unified Call Manager using TFTP to send encrypted configuration files to IP phones through the adaptive security appliance.

Multiple IP phones behind one NAT device must be configured to use the same security mode.

When the phone proxy is configured for a mixed-mode cluster and multiple IP phones are behind one NAT device and registering through the phone proxy, all the SIP and SCCP IP phones must be configured as authenticated or encrypted, or all as non-secure on the Unified Call Manager.

For example, if there are four IP phones behind one NAT device where two IP phones are configured using SIP and two IP phones are configured using SCCP, the following configurations on the Unified Call Manager are acceptable:

Two SIP IP phones: one IP phone in authenticated mode and one in encrypted mode, both in authenticated mode, or both in encrypted mode

Two SCCP IP phones: one IP phone in authenticated mode and one in encrypted mode, both in authenticated mode, or both in encrypted mode

Two SIP IP phones: both in non-secure mode

Two SCCP IP phones: one IP phone in authenticated mode and one in encrypted mode, both in authenticated mode, both in encrypted mode

Two SIP IP phones: one IP phone in authenticated mode and one in encrypted mode, both in authenticated mode, both in encrypted mode

Two SCCP IP phones: both in non-secure mode

This limitation results from the way the application-redirect rules (rules that convert TLS to TCP) are created for the IP phones.

The phone proxy does not support displaying the lock icon on IP phone screens. IP phones display the lock icon on the phone screen during encrypted calls. Even though the lock icon is not displayed on the screen, the IP phone call is still encrypted because the phone proxy encrypts calls by default.

Media Termination Address Guidelines and Limitations

The phone proxy has the following limitations relating to configuring the media-termination address:

When configuring the media-termination address, the phone proxy does not support having internal IP phones (IP phones on the inside network) being on a different network interface from the Cisco UCM unless the IP phones are forced to use the non-secure Security mode.

When internal IP phones are on a different network interface than the Cisco UCM, the IP phones signalling sessions still go through adaptive security appliance; however, the IP phone traffic does not go through the phone proxy. Therefore, Cisco recommends that you deploy internal IP phones on the same network interface as the Cisco UMC.

If the Cisco UMC and the internal IP phones must be on different network interfaces, you must add routes for the internal IP phones to access the network interface of the media-termination address where Cisco UMC resides.

When the phone proxy is configured to use a global media-termination address, all IP phones see the same global address, which is a public routable address.

If you decide to configure a media-termination address on interfaces (rather than using a global interface), you must configure a media-termination address on at least two interfaces (the inside and an outside interface) before applying the phone-proxy service policy. Otherwise, you will receive an error message when enabling the Phone Proxy with SIP and Skinny Inspection.

The phone proxy can use only one type of media termination instance at a time; for example, you can configure a global media-termination address for all interfaces or configure a media-termination address for different interfaces. However, you cannot use a global media-termination address and media-termination addresses configured for each interface at the same time.

Configuring the Phone Proxy

This section includes the following topics:

Task Flow for Configuring the Phone Proxy

Creating the CTL File

Adding or Editing a Record Entry in a CTL File

Creating the Media Termination Instance

Creating the Phone Proxy Instance

Adding or Editing the TFTP Server for a Phone Proxy

Configuring Linksys Routers with UDP Port Forwarding for the Phone Proxy

Task Flow for Configuring the Phone Proxy


Note This feature is not supported for the Adaptive Security Appliance version 8.1.2.


Configuring the Phone Proxy requires the following steps:

Step 1: Create the CTL file. See Creating the CTL File.

Step 2: Create the TLS Proxy instance to handle the encrypted signaling. See Adding a TLS Proxy Instance.

Step 3: Create the Phone Proxy instance. See the "Creating the Phone Proxy Instance" section.

Step 4: Configure the media termination address for the Phone Proxy. See Creating the Media Termination Instance.


Note Before you enable SIP and Skinny inspection for the Phone Proxy (which is done by applying the Phone Proxy to a service policy rule), the Phone Proxy must have an MTA instance, TLS Proxy, and CTL file assigned to it before the Phone Proxy can be applied to a service policy. Additionally, once a Phone Proxy is applied to a service policy rule, the Phone Proxy cannot be changed or removed.


Step 5: Enable the Phone Proxy with SIP and Skinny inspection. See SIP Inspection and Skinny (SCCP) Inspection.

Creating the CTL File

Create a Certificate Trust List (CTL) file that is required by the Phone Proxy. Specify the certificates needed by creating a new CTL file or by specifying the path of an exiting CTL file to parse from Flash memory.

Create trustpoints and generate certificates for each entity in the network (CUCM, CUCM and TFTP, TFTP server, CAPF) that the IP phones must trust. The certificates are used in creating the CTL file. You need to create trustpoints for each CUCM (primary and secondary if a secondary CUCM is used) and TFTP server in the network. The trustpoints need to be in the CTL file for the phones to trust the CUCM.

Create the CTL File that will be presented to the IP phones during the TFTP. The address must be the translated or global address of the TFTP server or CUCM if NAT is configured.

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.


Note When a CTL file instance is assigned to the Phone Proxy, you cannot modify it in the CTL File pane and the pane is disabled. To modify a CTL File that is assigned to the Phone Proxy, go to the Phone Proxy pane (Configuration > Firewall > Unified Communications > Phone Proxy), and deselect the Use the Certificate Trust List File generated by the CTL instance check box.


Use the Create a Certificate Trust List (CTL) File pane to create a CTL file for the Phone Proxy. This pane creates the CTL file that is presented to the IP phones during the TFTP handshake with the adaptive security appliance. For a detailed overview of the CTL file used by the Phone Proxy, see the "Creating the CTL File" section.

The Create a Certificate Trust List (CTL) File pane is used to configure the attributes for generating the CTL file. The name of the CTL file instance is generated by the ASDM. When the user tries to edit the CTL file instance configuration, the ASDM automatically generates the shutdown CLI command first and the no shutdown CLI command as the last command.

This pane is available from the Configuration > Firewall > Unified Communications > CTL File pane.


Step 1 Open the Configuration > Firewall > Unified Communications > CTL File pane.

Step 2 Check the Enable Certificate Trust List File check box to enable the feature.

Step 3 To specify the CTL file to use for the Phone Proxy, perform one of the following:

If there is an existing CTL file available, download the CTL file to Flash memory by using the File Management Tool in the ASDM Tools menu. Select the Use certificates present in the CTL stored in flash radio button and specify the CTL file name and path in the text box.

Use an existing CTL file to install the trustpoints for each entity in the network (CUCM, CUCM 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 CUCM 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

If there is no existing CTL file available, select Create new CTL file radio button.

Add Record entries for each entity in the network such as CUCM, TFTP, and CUCM-TFTP option by clicking Add. The Add Record Entry dialog box opens. See Adding or Editing a Record Entry in a CTL File.

Step 4 Specify the number SAST certificate tokens required. The default is 2. maximum allowed is 5.

Because the Phone Proxy generates the CTL file, it needs to create the System Administrator Security Token (SAST) key to sign the CTL file itself. This key can be generated on the adaptive security appliance. A SAST is created as a self-signed certificate. Typically, a CTL file contains more than one SAST. In case a SAST is not recoverable, the other one can be used to sign the file later.

Step 5 Click Apply to save the CTL file configuration settings.


Adding or Editing a Record Entry in a CTL File


Note This feature is not supported for the Adaptive Security Appliance version 8.1.2.


Use the Add/Edit Record Entry dialog box to specify the trustpoints to be used for the creation of the CTL file.

Add additional record-entry configurations for each entity that is required in the CTL file.


Step 1 Open the Configuration > Firewall > Unified Communications > CTL File pane.

Step 2 Check the Enable Certificate Trust List File check box to enable the feature.

Step 3 In the Type field, specify the type of trustpoint to create:

cucm: Specifies the role of this trustpoint to be CCM. Multiple CCM trustpoints can be configured.

cucm-tftp: Specifies the role of this trustpoint to be CCM+TFTP. Multiple CCM+TFTP trustpoints can be configured.

tftp: Specifies the role of this trustpoint to be TFTP. Multiple TFTP trustpoints can be configured.

capf: Specifies the role of this trustpoint to be CAPF. Only one CAPF trustpoint can be configured.

Step 4 In the Host field, specify the IP address of the trustpoint. The IP address you specify must be the global address of the TFTP server or CUCM if NAT is configured. The global IP address is the IP address as seen by the IP phones because it will be the IP address used for the CTL record for the trustpoint.

Step 5 In the Certificate field, specify the Identity Certificate for the record entry in the CTL file. You can create a new Identity Certificate by clicking Manage. The Manage Identify Certificates dialog box opens. See the "Configuring Identity Certificates Authentication" section.

You can add an Identity Certificate by generating a self-signed certificate, obtaining the certificate through SCEP enrollment, or by importing a certificate in PKCS-12 format. Choose the best option based on the requirements for configuring the CTL file.

Step 6 (Optional) In the Domain Name field, specify the domain name of the trustpoint used to create the DNS field for the trustpoint. This is appended to the Common Name field of the Subject DN to create the DNS Name. The domain name should be configured when the FQDN is not configured for the trustpoint. Only one domain-name can be specified.


Note If you are using domain names for your CUCM and TFTP server, you must configure DNS lookup on the adaptive security appliance. Add an entry for each of the outside interfaces on the adaptive security appliance into your DNS server, if such entries are not already present. Each adaptive 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. Additionally, define your DNS server IP address on the adaptive security appliance; for example: dns name-server 10.2.3.4 (IP address of your DNS server).


Creating the Media Termination Instance

Create the media termination instance that you will use in the phone proxy.

The media termination address you configure must meet the requirements as described in Media Termination Instance Prerequisites.


Note In versions before 8.2(1), you configured one media-termination address (MTA) on the outside interface of the adaptive security appliance where the remote Cisco IP phones were located. In Version 8.2(1) and later, you can configure a global media-termination address for all interfaces or configure a media-termination address for different interfaces.

As a result of this enhancement, the old configuration has been deprecated. You can continue to use the old configuration if desired. However, if you need to change the configuration at all, only the new configuration method is accepted; you cannot later restore the old configuration. If you need to maintain downgrade compatibility, you should keep the old configuration as is.



Step 1 Open the Configuration > Firewall > Unified Communications > Media Termination Address pane.

Step 2 Check the Enable Media Termination Address check box to enable the feature.

Step 3 In the Media Termination Address Settings area, specify whether to configure a media-termination address (MTA) per interface or to configure a global MTA. You can configure a global media-termination address for all interfaces or configure a media-termination address for different interfaces.

To configure an MTA per interface, click the Configure MTA per Interface radio button and click the Add button. In the dialog box that appears, specify the interface name and enter an IP address or hostname.

If you configure a media termination address for multiple interfaces, you must configure an address on each interface that the adaptive security appliance uses when communicating with IP phones. The IP addresses are publicly routable addresses that are unused IP addresses within the address range on that interface.

See Media Termination Instance Prerequisites for the complete list of requirements that you must follow when creating the media termination instance and configuring the media termination addresses.

To configure a global MTA, click the Configure global MTA on interface radio button and enter the IP address in the text box. See Media Termination Instance Prerequisites for the complete list of requirements that you must follow when configuring a global media termination address.

Step 4 Specify the minimum and maximum values for the RTP port range for the media termination instance. The minimum port and the maximum port can be a value from 1024 to 65535.

Step 5 Click Apply to save the media termination address configuration settings.


Creating the Phone Proxy Instance

Create the phone proxy instance. To have a fully functional phone proxy, you must also complete additional tasks, such as creating the MTA and enabling SIP and SCCP (Skinny) inspection. See Task Flow for Configuring the Phone Proxy for the complete list of tasks.

Prerequisites

You must have already created the CTL file and TLS proxy instance for the phone proxy.

See Creating the CTL File and Adding a TLS Proxy Instance.


Note This feature is not supported for the Adaptive Security Appliance version 8.1.2.


Use the Configure Phone Proxy pane to add a Phone Proxy.

This pane is available from the Configuration > Firewall > Unified Communications > Phone Proxy pane.


Step 1 Open the Configuration > Firewall > Unified Communications > Phone Proxy pane.

Step 2 Check the Enable Phone Proxy check box to enable the feature.

Step 3 Check the Apply MTA instance to Phone Proxy check box to add the media termination address to the Phone Proxy instance. You must have a media termination address instance configured. The configured address is added to the Phone Proxy instance.


Note To configure the media termination address, click the Configure MTA button. The Media Termination Address dialog box appears. Once you click the Add MTA instance to Phone Proxy check box, the media termination address instance cannot be modified and the button changes to View MTA Configuration. To change the media termination address, uncheck the Add MTA instance to Phone Proxy check box.


Step 4 If necessary, add a TFTP server for the Phone Proxy. To add a new TFTP server for the Phone Proxy, click Add. The Add TFTP Server dialog box opens. See Adding or Editing the TFTP Server for a Phone Proxy.


Note The TFTP server must reside on the same interface as the Cisco Unified Call Manager. Additionally, If NAT is configured for the TFTP server, the NAT configuration must be configured prior to configuring the specifying the TFTP server while creating the Phone Proxy instance.


Step 5 Specify the CTL File to use for the Phone Proxy by doing one of the following:

To use an existing CTL File, check the Use the Certificate Trust List File generated by the CTL instance check box.

To create a new CTL file for the Phone Proxy, click the link Generate Certificate Trust List File. The Create a Certificate Trust List (CTL) File pane opens. See "Creating the CTL File" section.

Step 6 To specify the security mode of the CUCM cluster, click one of the following options in the CUCM Cluster Mode field:

Non-secure—Specifies the cluster mode to be in nonsecure mode when configuring the Phone Proxy feature.

Mixed—Specifies the cluster mode to be in mixed mode when configuring the Phone Proxy feature.

Step 7 To configure the idle timeout after which the secure-phone entry is removed from the Phone Proxy database (the default is 5 minutes), enter a value in the format hh:mm:ss.

Since secure phones always request a CTL file upon bootup, the Phone Proxy creates a database that marks the phone as secure. The entries in the secure phone database are removed after a specified configured timeout. The entry timestamp is updated for each registration refresh the Phone Proxy receives for SIP phones and KeepAlives for SCCP phones.

Specify a value that is greater than the maximum timeout value for SCCP KeepAlives and SIP Register refresh. For example, if the SCCP KeepAlives are configured for 1 minute intervals and the SIP Register Refresh is configured for 3 minutes, configure this timeout value greater than 3 minutes.

Step 8 To preserve Call Manager configuration on the IP phones, check the Preserve the Call Manager's configuration on the phone... check box. When this check box is uncheck, the following service settings are disabled on the IP phones:

PC Port

Gratuitous ARP

Voice VLAN access

Web Access

Span to PC Port

Step 9 To force Cisco IP Communicator (CIPC) softphones to operate in authenticated mode when CIPC softphones are deployed in a voice and data VLAN scenario, check the Enable CIPC security mode authentication check box.

Because CIPC requires an LSC to perform the TLS handshake, CIPC needs to register with the CUCM in nonsecure mode using cleartext signaling. To allow the CIPC to register, create an ACL that allows the CIPC to connect to the CUCM on the nonsecure SIP/SCCP signalling ports (5060/2000).

CIPC uses a different cipher when doing the TLS handshake and requires the null-sha1 cipher and SSL encryption be configured. To add the null-shal cipher, go to Configuration > Device Management > Advanced > SSL Settings > Encryption section. Select the null-shal SSL encryption type and add it to the Available Algorithms.

Current versions of Cisco IP Communicator (CIPC) support authenticated mode and perform TLS signaling but not voice encryption.

Step 10 To configure an HTTP proxy for the Phone Proxy feature that is written into the IP phone's configuration file under the <proxyServerURL> tag, do the following:

a. Check the Configure a http-proxy which would be written into the phone's config file... check box.

b. In the IP Address field, type the IP address of the HTTP proxy and the listening port of the HTTP proxy.

The IP address you enter should be the global IP address based on where the IP phone and HTTP proxy server is located. You can enter a hostname in the IP Address field when that hostname can be resolved to an IP address by the adaptive security appliance (for example, DNS lookup is configured) because the adaptive security appliance will resolve the hostname to an IP address. If a port is not specified, the default will be 8080.

c. In the Interface field, select the interface on which the HTTP proxy resides on the adaptive security appliance.

Setting the proxy server configuration option for the Phone Proxy allows for an HTTP proxy on the DMZ or external network in which all the IP phone URLs are directed to the proxy server for services on the phones. This setting accommodates nonsecure HTTP traffic, which is not allowed back into the corporate network.

Step 11 Click Apply to save the Phone Proxy configuration settings.



Note After creating the Phone Proxy instance, you enable it with SIP and Skinny inspection. See SIP Inspection and Skinny (SCCP) Inspection.

However, before you enable SIP and Skinny inspection for the Phone Proxy (which is done by applying the Phone Proxy to a service policy rule), the Phone Proxy must have an MTA instance, TLS Proxy, and CTL file assigned to it before the Phone Proxy can be applied to a service policy. Additionally, once a Phone Proxy is applied to a service policy rule, the Phone Proxy cannot be changed or removed.


Adding or Editing the TFTP Server for a Phone Proxy


Note This feature is not supported for the Adaptive Security Appliance version 8.1.2.



Step 1 Open the Configuration > Firewall > Unified Communications > Phone Proxy pane.

Step 2 Check the Enable Phone Proxy check box to enable the feature.

Step 3 To add or edit the TFTP Server information for the phone proxy, click the Add or Edit button. The Add/Edit TFTP Server dialog box appears.

Use the Add/Edit TFTP Server dialog box to specify the IP address of the TFTP server and the interface on which the TFTP server resides.

The Phone Proxy must have at least one CUCM TFTP server configured. Up to five TFTP servers can be configured for the Phone Proxy.

The TFTP server is assumed to be behind the firewall on the trusted network; therefore, the Phone Proxy intercepts the requests between the IP phones and TFTP server.


Note If NAT is configured for the TFTP server, the NAT configuration must be configured prior to specifying the TFTP server while creating the Phone Proxy instance.


Step 4 In the TFTP Server IP Address field, specify the address of the TFTP server. Create the TFTP server using the actual internal IP address.

Step 5 (Optional) In the Port field, specify the port the TFTP server is listening in on for the TFTP requests. This should be configured if it is not the default TFTP port 69.

Step 6 In the Interface field, specify the interface on which the TFTP server resides. The TFTP server must reside on the same interface as the Cisco Unified Call Manager (CUCM).

Step 7 Click OK to apply the settings.

Configuring Linksys Routers with UDP Port Forwarding for the Phone Proxy

When IP phones are behind a NAT-capable router, the router can be configured to forward the UDP ports to the IP address of the IP phone. Specifically, configure the router for UDP port forwarding when an IP phone is failing during TFTP requests and the failure is due to the router dropping incoming TFTP data packets. Configure the router to enable UDP port forwarding on port 69 to the IP phone.

As an alternative of explicit UDP forwarding, some Cable/DSL routers require you to designate the IP phone as a DMZ host. For Cable/DSL routers, this host is a special host that receives all incoming connections from the public network.

When configuring the phone proxy, there is no functional difference between an IP phone that has UDP ports explicitly forwarded or an IP phone designated as a DMZ host. The choice is entirely dependent upon the capabilities and preference of the end user.

Configuring Your Router

Your firewall/router needs to be configured to forward a range of UDP ports to the IP phone. This will allow the IP phone to receive audio when you make/receive calls.


Note Different Cable/DSL routers have different procedures for this configuration. Furthermore most NAT-capable routers will only allow a given port range to be forwarded to a single IP address


The configuration of each brand/model of firewall/router is different, but the task is the same. For specific instructions for your brand and model of router, please contact the manufacturer's website.

Linksys Routers


Step 1 From your web browser, connect to the router administrative web page. For Linksys, this is typically something like http://192.168.1.1.

Step 2 Click Applications & Gaming or the Port Forwarding tab (whichever is present on your router).

Step 3 Locate the table containing the port forwarding data and add an entry containing the following values:

Table 44-2 Port Forwarding Values to Add to Router

Application
Start
End
Protocol
IP Address
Enabled

IP phone

1024

65535

UDP

Phone IP address

Checked

TFTP

69

69

UDP

Phone IP address

Checked


Step 4 Click Save Settings. Port forwarding is configured.


Feature History for the Phone Proxy

Table 44-3 lists the release history for this feature.

Table 44-3 Feature History for Cisco Phone Proxy 

Feature Name
Releases
Feature Information

Cisco Phone Proxy

8.0(4)

The phone proxy feature was introduced. The Phone Proxy feature was accessible in ASDM by choosing the following options:

Configuration > Firewall > Advanced > Encrypted Traffic Inspection > Phone Proxy pane

NAT for the media termination address

8.1(2)

The Media Termination fields were removed from the Phone Proxy pane and added to the Media Termination pane:

Configuration > Firewall > Advanced > Encrypted Traffic Inspection > Media Termination Address pane