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.

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.

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.

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.

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.

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.

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:

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

Figure 27-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.

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

Phone Proxy Limitations and Restrictions

The phone proxy has the following limitations and restrictions:

•Only one phone proxy instance can be configured on the security appliance by using the phone-proxy command. See the Cisco Security Appliance Command Reference for information about the phone-proxy command.

•The phone proxy is not supported when the 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 ..."

•The phone proxy does not support inspection of packets from phones connecting to the phone proxy over a VPN tunnel. Therefore, sending phone proxy traffic through a VPN tunnel is not supported. Configuring the phone proxy feature on the security appliance allows IP phones to connect to the corporate network without requiring that the traffic go through VPN tunnels.

•The phone proxy does not support recording calls when the recording traffic must traverse the security appliance to get to the recording device. For example, the Unified Communication Manager versions 6.x and 7.x supports using a third-party recording device with the forking feature. When the recording feature is used with the phone proxy, the feature creates a second RTP media stream that is a copy of the original RTP media stream. The existence of two RTP media streams from the outside IP phone to the recording device on behind the security device disrupts the IP phone audio.

•The security appliance supports stateful failover for the phone proxy in the following way. When the active unit goes down, any calls from IP phones going through the phone proxy fail, media stops flowing, and the IP phones should unregister from the failed unit and reregister with the active unit. Then, the calls must be re-established."

•The phone proxy does not support communication with internal IP phones that natively use the Secure Real-Time Protocol (SRTP).

•When used with CIPC, the phone proxy does not support end-users resetting their device name in CIPC (Prefences > Network tab > Use this Device Name field) or Administrators resetting the devide 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 security appliance.

•The phone proxy and CIPC are not supported when CIPC is installed on computers in remote locations, such that the calls from those computers traverse the Internet, terminating at the security appliance, to reach IP phones residing on the network behind the adaptive security appliance. The computers where CIPC is installed must be on the network to reach the IP phones behind the 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.

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 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 27-4 lists the access-list rule that must be configured for TFTP on the security appliance:

Table 27-4 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.

•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 27-5 lists the ports that are required to be configured on the existing firewall:

Table 27-5 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:

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

The phone proxy and CIPC are not supported when CIPC is installed on computers in remote locations, such that the calls from those computers traverse the Internet, terminating at the security appliance, to reach IP phones residing on the network behind the adaptive security appliance. The computers where CIPC is installed must be on the network to reach the IP phones behind the security appliance.

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.

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

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:

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

hostname(config)# crypto ca trustpointtrustpoint_name

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# keypairkeyname

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca enrolltrustpoint

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:

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

Note Only one phone proxy instance can be configured on the security appliance by using the phone-proxy command. See the Cisco Security Appliance Command Reference for information about the phone-proxy command.

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

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

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

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

hostname(config-phone-proxy)# ctl-filectl_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:

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:

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-mapclass_map_name

hostname(config-cmap)# match port tcpeq2443

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-mapclass_map_name

hostname(config-cmap)# match port tcpeq5061

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-mapname

hostname(config-pmap)# classclassmap-name

hostname(config-pmap-c)# inspect skinny phone-proxypp_name

hostnae(config-pmap)# classclassmap-name

hostname(config-pmap-c)# inspect sip phone-proxypp_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-policypolicymap_nameinterfaceintf

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 trustpointtrustpoint_name

hostname(config-ca-trustpoint)# enrollment terminal

Step 7 Authenticate the trustpoint by entering the following command:

hostname(config)# crypto caauthenticatetrustpoint

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 27-6 shows the certificates that are required by the security appliance.

Table 27-6 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.

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.

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

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 key generate rsa label keyname modulus 1024

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# keypairkeyname

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca enrolltrustpoint

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:

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 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-filectl_name

c. If you are using an existing CTL file, use the trustpoints that are already in existing CTL file stored in Flash memory by entering the following command:

hostname(config-ctl-file)# cluster-ctl-filefilename_path

Where the existing CTL file was saved to Flash memory with a filename other than CTLFile.tlv; for example, old_ctlfile.tlv.

Note Complete the remaining items in this step if you are creating a new CTL file instance or you want to add more entries to an existing CTL file.

d. Create the record entry for the TFTP server by entering the following command:

For mixed mode clusters, there might be IP phones that are already configured as encrypted so it requires TLS to the Cisco UCM. You must configure the LDC issuer for the TLS proxy. For more information about any of the following steps, see TLS Proxy for Encrypted Voice Inspection.

a. Create the necessary RSA key pairs by entering the following commands:

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

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

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

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

hostname(config-phone-proxy)# ctl-filectl_name

f. Configure the mode of the cluster to be mixed mode because the default is nonsecure.

hostname(config-phone-proxy)# cluster-mode mixed

g. (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:

proxy-serveraddressip_address [listen_port] interfaceifc

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.

h. (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:

i. (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-mapclass_map_name

hostname(config-cmap)# match port tcpeq2443

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

hostname(config)# class-mapclass_map_name

hostname(config-cmap)# match port tcpeq5061

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

hostname(config)# policy-mapname

hostname(config-pmap)# classclassmap-name

hostname(config-pmap-c)# inspect skinny phone-proxypp_name

hostnae(config-pmap)# classclassmap-name

hostname(config-pmap-c)# inspect sip phone-proxypp_name

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

hostname(config)# service-policypolicymap_nameinterfaceintf

Phone Proxy Configuration for Cisco IP Communicator

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

•Include the cipc security-mode authenticated command under the phone-proxy command.

•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. Therefore, you must include the following command when configuring the phone proxy instance:

cipc security-mode authenticated

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

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 (Prefences > Network tab > Use this Device Name field) or Administrators resetting the devide 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 and CIPC are not supported when CIPC is installed on computers in remote locations, such that the calls from those computers traverse the Internet, terminating at the adsecurity appliance to reach IP phones residing on the network behind the adaptive security appliance. The computers where CIPC is installed must be on the network to reach the IP phones behind the security appliance.

Configuring Linksys Routers for UDP Port Forwarding

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 3 Locate the table containing the port forwarding data and add an entry containing the following values:

Table 27-7 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.

About 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 Security Appliance 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 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

The example configuration below shows how the calculated conformance rate is used with the police command:

access-list tftp extended permit udp any host 192.168.0.1 eq tftp

class-map tftpclass

match access-list tftp

policy-map tftpmap

class tftpclass

police output 192000

service-policy tftpmap interface inside

About ICMP Traffic Destined for the Media Termination Address

To control which hosts can ping the media termination address, use the icmp command and apply the access rule to the outside interface on the security appliance.

Any rules for ICMP access applied to the outside interface apply to traffic destined for the media termination address.

For example, use the following command to deny ICMP pings from any host destined for the media termination address:

Debugging Information from the Security Appliance

This section describes how to use the debug, capture, and show commands to obtain debugging information for the phone proxy. See the Cisco Security Appliance Command Reference for detailed information about the syntax for these commands.

Table 27-8 Security Appliance Debug Commands to Use with the Phone Proxy

To

Use the Command

Notes

To show error and event messages for TLS proxy inspection.

debug inspect tls-proxy [events | errors]

Use this command when your IP phone has successfully downloaded all TFTP files but is failing to complete the TLS handshake with the TLS proxy configured for the phone proxy.

To show error and event messages of media sessions for SIP and Skinny inspections related to the phone proxy.

debug phone-proxy media [events | errors]

Use this command in conjunction with the debug sip command and the debug skinny commandif your IP phone is experiencing call failures or audio problems.

To show error and event messages of signaling sessions for SIP and Skinny inspections related to the phone proxy.

debug phone-proxy signaling [events | errors]

Use this command in conjunction with the debug sip command and the debug skinny command if your IP phone is failing to register with the Cisco UCM or if you are experiencing call failure.

To show error and event messages of TFTP inspection, including creation of the CTL file and configuration file parsing.

debug phone-proxy tftp [events | errors]

To show debug messages for SIP application inspection.

debug sip

Use this command when your IP phones are experiencing connection problems; for example, you can connect within the network but cannot make calls off the network. In the output, check for 4XX or 5XX messages.

To show debug messages for SCCP (Skinny) application inspection.

debug skinny

Use this command when your IP phones are experiencing connection problems; for example, you can connect within the network but cannot make calls off the network. In the output, check for 4XX or 5XX messages.

Table 27-9 lists the capture commands to use with the phone proxy. Use the capture command on the appropriate interfaces (IP phones and Cisco UCM) to enable packet capture capabilities for packet sniffing and network fault isolation.

Table 27-9 Security Appliance Capture Commands to Use with the Phone Proxy

To

Use the Command

Notes

To capture packets on the security appliance interfaces.

capturecapture_nameinterfaceinterface_name

Use this command if you are experiencing any problems that might require looking into the packets.

For example, if there is a TFTP failure and the output from the debug command does not indicate the problem clearly, run the capture command on the interface on which the IP phone resides and the interface on which the TFTP server resides to see the transaction and where the problem could be.

To capture data from the TLS proxy when there is a non-secure IP phone connecting to the phone proxy on the inside interface.

capturecapture_namepacket-lengthbytesinterfaceinsidebuffer buf_size

To capture encrypted data from the TLS proxy when there are secure IP phones connecting to the phone proxy on the inside interface.

If signaling fails, you might require capturing decrypted packets to see the contents of the SIP and SCCP signaling message. Use the type tls-proxy option in the capture command.

Table 27-10 Security Appliance Show Commands to Use with the Phone Proxy

To

Use the Command

Notes

To show the packets or connections dropped by the accelerated security path.

show asp drop

Use this command to troubleshoot audio quality issues with the IP phones or other traffic issues with the phone proxy. In addition to running this command, get call status from the phone to check for any dropped packets or jitter. See Debugging Information from IP Phones.

To show the classifier contents of the accelerated security path for the specific classifier domain.

show asp table classify domaindomain_name

If the IP phones are not downloading TFTP files, use this command to check that the classification rule for the domain inspect-phone-proxy is set for hosts to the configured TFTP server under the phone proxy instance.

If the IP phones are failing to register, use this command to make sure there is a classification rule for the domain app-redirect set for the IP phones that cannot register.

To show the connections that are to the security appliance or from the security appliance, in addition to through-traffic connections.

show conn all

If you are experiencing problems with audio, use this command to make sure that there are connections opened from the IP phone to the media termination address.

Note Use the show conn command with following options to display TFTP connections that have replicated (unused) connections:

hostname# show conn |
include p

The output for the TFTP connections should have a "p" flag at the end:

Using this command shows that the phone proxy has connections that are going through "inspect-phone-proxy", which inspects TFTP connections. Using this command verifies that the TFTP requests are being inspected because the p flag is there.

To show the logs in the buffer and logging settings.

show logging

Before entering the show logging command, enable the logging buffered command so that the show logging command displays the current message buffer and the current settings.

Use this command to determine if the phone proxy and IP phones are successfully completing the TLS handshake.

Note Using the show logging command is useful for troubleshooting many problems where packets might be denied or there are translation failures.

To show the corresponding media sessions stored by the phone proxy.

show phone-proxy media-sessions

Use this command to display output from successful calls. Additionally, use this command to troubleshoot problems with IP phone audio, such as one-way audio.

To show the IP phones capable of Secure mode stored in the database.

show phone-proxy secure-phones

For any problems, make sure there is an entry for the IP phone in this output and that the port for this IP phone is non-zero, which indicates that it has successfully registered with the Cisco UCM.

To show the corresponding signaling sessions stored by the phone proxy.

show phone-proxy signaling-sessions

Use this command to troubleshoot media or signaling failure.

To show the configured service policies.

show service-policy

Use this command to show statistics for the service policy.

To show active TLS proxy sessions related to the phone proxy.

show tls-proxy sessions

If the IP phone has failed to register, use this command to see if the IP phone has successfully completed the handshake with the TLS proxy configured for the phone proxy.

Debugging Information from IP Phones

•Check the Status messages on the IP phone by selecting the Settings button > Status > Status Messages and selecting the status item that you want to view.

•Collect the call-statistics data from the IP phone by selecting the Settings button > Status > Call Statistic. Data like the following displays:

RxType: G.729 TxType: G.729

RxSize: 20 ms TxSize: 20 ms

RxCnt: 0 TxCnt: 014174

AvgJtr: 10 MaxJtr: 59

RxDisc: 0000 RxLost: 014001

•Check the Security settings on the IP phone by selecting the Settings button > Security Configuration. Settings for web access, Security mode, MIC, LSC, CTL file, trust list, and CAPF appear. Under Security mode, make sure the IP phone is set to Encrypted.

•Check the IP phone to determine which certificates are installed on the phone by selecting the Settings button > Security Configuration > Trust List. In the trustlist, verify the following:

–Make sure that there is an entry for each entity that the IP phone will need to contact. If there is a primary and backup Cisco UCM, the trustlist should contain entries for each Cisco UCM.

–If the IP phone needs an LSC, the record entry should contain a CAPF entry.

–Make sure that the IP addresses listed for each entry are the mapped IP addresses of the entities that the IP phone can reach.

•Open a web browser and access the IP phone console logs at the URL http://IP_phone_IP address. The device information appears in the page. In the Device Logs section in the left pane, click Console Logs.

IP Phone Registration Failure

The following errors can make IP phones unable to register with the phone proxy:

TFTP Auth Error Displays on IP Phone Console

Solution This Status message can indicate a problem with the IP phone CTL file.

To correct problems with the IP phone CTL file, perform the following:

Step 1 From the IP phone, select the Setting button > Security Configuration > Trust List. Verify that each entity in the network—Primary Cisco UCM, Secondary Cisco UCM, TFTP server—has its own entry in the trustlist and that each entity IP address is reachable by the IP phone.

Step 2 From the security appliance, verify that the CTL file for the phone proxy contains one record entry for each entity in the network—Primary Cisco UCM, Secondary Cisco UCM, TFTP server—by entering the following command:

hostname# show running-config all ctl-file [ctl_name]

Each of these record entries creates one entry on the IP phone trustlist. The phone proxy creates one entry internally with the function CUCM+TFTP.

Configuration File Parsing Error

Problem When the security appliance receives the configuration file from the Cisco UCM and tries to parse it, the following error appears in the debug output (debug phone-proxy tftp errors):

PP: 192.168.10.5/49357 requesting SEP00010002003.cnf.xml.sgn

PP: opened 0x193166

.......

PP: Beginning of element tag is missing, got !

PP: error parsing config file

PP: Error modifying config file, dropping packet

Solution Perform the following actions to troubleshoot this problem:

Step 1 Enter the following URL in a web browser to obtain the IP phone configuration file from the Cisco Unified CM Administration console:

http://<cucm_ip>:6970/<config_file_name>

For example, if the Cisco UCM IP address is 128.106.254.2 and the IP phone configuration file name is SEP000100020003.cnf.xml, enter:

http://128.106.254.2:6970/SEP000100020003.cnf.xml

Step 2 Save this file, open a case with TAC and send them this file and the output from running the debug phone-proxy tftp command on the security appliance.

Configuration File Parsing Error: Unable to Get DNS Response

Problem When the security appliance receives the configuration file from the Cisco UCM and tries to parse it, the following error appears in the debug output (debug phone-proxy tftp errors):

PP: 192.168.10.5/49357 requesting SEP00010002003.cnf.xml.sgn

PP: opened 0x193166

.......

PP: Callback required for parsing config file

PP: Unable to get dns response for id 7

PP: Callback, error modifying config file

The error indicates that the Cisco UCM is configured as an FQDN and the phone proxy is trying to do a DNS lookup but failed to get a response.

Solution

Step 1 Verify that DNS lookup is configured on the security appliance.

Step 2 If DNS lookup is configured, determine whether you can ping the FQDN for the Cisco UCM from the security appliance.

Step 3 If security appliance cannot ping the Cisco UCM FQDN, check to see if there is a problem with the DNS server.

Step 4 Additionally, use the name command to associate a name with an IP address with the FQDN. See the Cisco Security Appliance Command Reference for information about using the name command.

Non-configuration File Parsing Error

Problem The security appliance receives a file other than an IP phone configuration file from the Cisco UCM and attempts to parse it. The following error appears in the debug output (debug phone-proxy tftp):

Solution The phone proxy should parse only the IP phone configuration file. When the phone proxy TFTP state gets out of state, the phone proxy cannot detect when it is attempting to parse a file other than the IP phone configuration file and the error above appears in the security appliance output from the debug phone-proxy tftp command.

Perform the following actions to troubleshoot this problem:

Step 1 Reboot the IP phone.

Step 2 On the security appliance, enter the following command to obtain the error information from the first TFTP request to the point where the first error occurred.

Step 4 Save this troubleshooting data, open a case with TAC and give them this information.

Cisco UCM Does Not Respond to TFTP Request for Configuration File

Problem When the security appliance forwards the TFTP request to the Cisco UCM for the IP phone configuration file, the Cisco UCM does not respond and the following errors appear in the debug output (debug phone-proxy tftp):

Step 1 Determine why the Cisco UCM is not responding to the TFTP request by performing the following troubleshooting actions:

•Use the Cisco UCM to ping the security appliance inside interface when PAT is configured for the outside interface so that the IP phone IP address is uses NAT for the security appliance inside interface IP address.

•Use the Cisco UCM to ping the IP phone IP address when NAT and PAT are not configured.

IP Phone Requesting Unsigned File Error

Problem The IP phone should always request a signed file. Therefore, the TFTP file being requested always has the .SGN extension.

When the IP phone does not request a signed file, the following error appears in the debug output (debug phone-proxy tftp errors):

Error: phone requesting for unsigned config file

Solution Most likely, this error occurs because the IP phone has not successfully installed the CTL file from the security appliance.

Determine whether the IP phone has successfully downloaded and installed the CTL file from the security appliance by checking the Status messages on the IP phone. See Debugging Information from IP Phones for information.

IP Phone Unable to Download CTL File

Solution If the IP phone did not have an existing CTL file, check the Status messages by selecting the Settings button > Status > Status Messages. If the list contains a Status message indicating the IP phone encountered a CTL File Auth error, obtain the IP phone console logs, open a TAC case, and send them the logs.

Solution This error can appear in the IP phone Status messages when the IP phone already has an existing CTL file.

Step 1 Check the IP phone to see if a CTL file already exists on it. This can occur if the IP phone previously registered with a mixed mode cluster Cisco UCM. On the IP phone, select the Settings button > Security Configuration > CTL file.

Solution Problems downloading the CTL file might be caused by issues with media termination. Enter the following command to determine if the media-termination address in the phone proxy configuration is set correctly:

hostname(config)# show running-config all phone-proxy

!

phone-proxy mypp

media-termination address 10.10.0.25

cipc security-mode authenticated

cluster-mode mixed

disable service-settings

timeout secure-phones 0:05:00

hostname(config)#

Make sure that the media-termination address is set correctly. 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 on an attached outside network to the security appliance interface that will never be used by another device in your network.

•The IP address cannot be the same as any of the security appliance interface IP addresses.

•The IP address cannot overlap with existing static 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.

IP Phone Registration Failure from Signaling Connections

Problem The IP phone is unable to complete the TLS handshake with the phone proxy and download its files using TFTP.

Solution

Step 1 Determine if the TLS handshake is occurring between the phone proxy and the IP phone, perform the following:

a. Enable logging with the following command:

hostname(config)# logging buffered debugging

b. To check the output from the syslogs captured by the logging buffered command, enter the following command:

hostname# show logging

The syslogs will contain information showing when the IP phone is attempting the TLS handshake, which happens after the IP phone downloads its configuration file.

Step 2 Determine if the TLS proxy is configured correctly for the phone proxy:

a. Display all currently running TLS proxy configurations by entering the following command:

hostname# show running-config tls-proxy

tls-proxy proxy

server trust-point _internal_PP_<ctl_file_instance_name>

client ldc issuer ldc_signer

client ldc key-pair phone_common

no client cipher-suite

hostname#

b. Verify that the output contains the server trust-point command under the tls-proxy command (as shown in substep a.).

If you are missing the server trust-point command, modify the TLS proxy in the phone proxy configuration.

Having this command missing from the TLS proxy configuration for the phone proxy will cause TLS handshake failure.

Step 3 Verify that all required certificates are imported into the security appliance so that the TLS handshake will succeed.

a. Determine which certificates are installed on the security appliance by entering the following command:

hostname# show running-config crypto

Additionally, determine which certificates are installed on the IP phones. See Debugging Information from IP Phones for information about checking the IP phone to determine if it has MIC installed on it.

b. Verify that the list of installed certificates contains all required certificates for the phone proxy.

%ASA-3-717027: Certificate chain failed validation. No suitable trustpoint was found to
validate chain.

Solution

Verify that all required certificates are imported into the security appliance so that the TLS handshake will succeed.

Step 1 Determine which certificates are installed on the security appliance by entering the following command:

hostname# show running-config crypto

Additionally, determine which certificates are installed on the IP phones. See Debugging Information from IP Phones for information about checking the IP phone to determine if it has MIC installed on it.

Step 2 Verify that the list of installed certificates contains all required certificates for the phone proxy.

In order for the phone proxy to authenticate the MIC provided by the IP phone, it needs the Cisco Manufacturing CA (MIC) certificate imported into the security appliance.

Verify that all required certificates are imported into the security appliance so that the TLS handshake will succeed.

Step 1 Determine which certificates are installed on the security appliance by entering the following command:

hostname# show running-config crypto

Additionally, determine which certificates are installed on the IP phones. The certificate information is shown under the Security Configuration menu. See Debugging Information from IP Phones for information about checking the IP phone to determine if it has the MIC installed on it.

Step 2 Verify that the list of installed certificates contains all required certificates for the phone proxy.

Media Termination Address Errors

Problem Entering the media-termination address command displays the following errors:

hostname(config-phone-proxy)# media-termination addressip_address

ERROR: Failed to apply IP address to interface Virtual254, as the network overlaps with
interface GigabitEthernet0/0. Two interfaces cannot be in the same subnet.

ERROR: Failed to set IP address for the Virtual interface

ERROR: Could not bring up Phone proxy media termination interface

ERROR: Failed to find the HWIDB for the Virtual interface

Solution Enter the following command to determine if the media-termination address in the phone proxy configuration is set correctly:

hostname(config)# show running-config all phone-proxy

asa2(config)# show running-config all phone-proxy

!

phone-proxy mypp

media-termination address 10.10.0.25

cipc security-mode authenticated

cluster-mode mixed

disable service-settings

timeout secure-phones 0:05:00

hostname(config)#

Make sure that the media-termination address is set correctly. 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 on an attached outside network to the security appliance interface that will never be used by another device in your network.

•The IP address cannot be the same as any of the security appliance interface IP addresses.

•The IP address cannot overlap with existing static 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.

Audio Problems with IP Phones

The following audio errors can occur when the IP phones connecting through the phone proxy.

Media Failure for a Voice Call

Problem The call signaling completes but there is one way audio or no audio.

Solution

•Problems with one way or no audio might be caused by issues with media termination. Enter the following command to determine if the media-termination address in the phone proxy configuration is set correctly:

hostname(config)# show running-config all phone-proxy

asa2(config)# show running-config all phone-proxy

!

phone-proxy mypp

media-termination address 10.10.0.25

cipc security-mode authenticated

cluster-mode mixed

disable service-settings

timeout secure-phones 0:05:00

hostname(config)#

Make sure that the media-termination address is set correctly. 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 on an attached outside network to the security appliance interface that will never be used by another device in your network.

–The IP address cannot be the same as any of the security appliance interface IP addresses.

–The IP address cannot overlap with existing static 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.

•If the media-termination address meets the requirements, determine whether the IP address is reachable by all IP phones.

•If the IP address is set correctly and it is reachable by all IP phones, check the call statistics on an IP phone (see Debugging Information from IP Phones) and determine if there are Rcvr packets and Sender packets on the IP phone, or if there are any Rcvr Lost or Discarded packets.

Saving SAST Keys

Site Administrator Security Token (SAST) keys on the security appliance can be saved in the event a recovery is required due to hardware failure and a replacement is required. The following steps shows how to recover the SAST keys and use them on the new hardware.

The SAST keys can be seen via the show crypto key mypubkey rsa command. The SAST keys are associated with a trustpoint that is labeled _internal_ctl-file_name_SAST_X where ctl-file-name is the name of the CTL file instance that was configured, and X is an integer from 0 to N-1 where N is the number of SASTs configured for the CTL file (the default is 2).

Step 1 On the security appliance, export all the SAST keys in PKCS-12 format by using the crypto ca export command:

Where trustpoint is _internal_ctl-file_name_SAST_X and ctl-file-name is the name of the CTL file instance that was configured, and X is an integer from 0 to 4 depending on what you exported from the security appliance.

b. Using the PKCS-12 output you saved in Step 1, enter the following command and paste the output when prompted:

Step 3 Create the CTL file instance on the new security appliance using the same name as the one used in the SAST trustpoints created in Step 2 by entering the following commands. Create trustpoints for each Cisco UMC (primary and secondary).

TLS Proxy for Encrypted Voice Inspection

Overview

With encrypted voice inspection, the security appliance decrypts, inspects and modifies (as needed, for example, performing NAT fixup), and re-encrypts voice signaling traffic while all of the existing VoIP inspection functions for Skinny and SIP protocols are preserved. Once voice signaling is decrypted, the plaintext signaling message is passed to the existing inspection engines.

The security appliance acts as a TLS proxy between the Cisco IP Phone and Cisco Unified CallManager. The proxy is transparent for the voice calls between the phone and the Cisco Unified CallManager. Cisco IP Phones download a Certificate Trust List from the Cisco Unified CallManager before registration which contains identities (certificates) of the devices that the phone should trust, such as TFTP servers and Cisco Unified CallManager servers. To support server proxy, the CTL file must contain the certificate that the security appliance creates for the Cisco Unified CallManagers. To proxy calls on behalf of the Cisco IP Phone, the security appliance presents a certificate that the Cisco Unified CallManager can verify, which is a Local Dynamic Certificate for the phone, issued by the certificate authority on the security appliance.

TLS proxy is supported by the Cisco Unified CallManager Release 5.1 and later. You should be familiar with the security features of the Cisco Unified CallManager. For background and detailed description of Cisco Unified CallManager security, see the Cisco Unified CallManager document.

TLS proxy applies to the encryption layer and must be configured with an application layer protocol inspection. You should be familiar with the inspection features on the ASA security appliance, especially Skinny and SIP inspection. For more information on deployment topologies and configuration, refer to the Cisco Security Appliance Command Line Configuration Guide.

Configuring TLS Proxy

The security appliance in Figure 27-2 serves as a proxy for both client and server, with Cisco IP Phone and Cisco Unified CallManager interaction.

Figure 27-2

TLS Proxy Flow

Before configuring TLS proxy, the following prerequisites are required:

•You must set clock on the security appliance before configuring TLS proxy. To set the clock manually and display clock, use the clock set and show clock commands. We recommend that the security appliance use the same NTP server as the Cisco Unified CallManager cluster. TLS handshake may fail due to certificate validation failure if clock is out of sync between the security appliance and the Cisco Unified CallManager server.

•3DES-AES license is needed to interoperate with the Cisco Unified CallManager. AES is the default cipher used by the Cisco Unified CallManager and Cisco IP Phone.

To configure the security appliance for TLS proxy, perform the following steps:

Step 1 (Optional) Set the maximum number of TLS proxy sessions to be supported by the security appliance using the following command, for example:

hostname(config)# tls-proxy maximum-sessions 1200

Note The tls-proxy maximum-sessions command controls the memory size reserved for cryptographic applications such as TLS proxy. Crypto memory is reserved at the time of system boot. You may need to reboot the security appliance for the configuration to take effect if the configured maximum sessions number is greater than the currently reserved.

Step 2 Import the following certificates which are stored on the Cisco UCM. These certificates are required by the security appliance for the phone proxy. For example, the CA Manufacturer certificate is required by the phone proxy to validate the IP phone certificate. See Importing Certificates from the Cisco UCM.

•CallManager

•Cisco_Manufacturing_CA

•CAP-RTP-001

•CAP-RTP-002

•(Optional) CAPF—import the CAPF certificate when LSC provisioning is required or you have LSC enabled IP phones

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

Step 3 Create necessary RSA key pairs using the following commands, for example:

Step 4 Create the proxy certificate for the Cisco Unified CallManager cluster using the following commands, for example:

hostname(config)# ! for self-signed CCM proxy certificate

hostname(config)# crypto ca trustpoint ccm_proxy

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# fqdn none

hostname(config-ca-trustpoint)# subject-name cn=EJW-SV-1-Proxy

hostname(config-ca-trustpoint)# keypair ccm_proxy_key

hostname(config)# crypto ca enroll ccm_proxy

The Cisco Unified CallManager proxy certificate could be self-signed or issued by a third-party CA. The certificate is exported to the CTL client.

Note Cisco IP Phones require certain fields from the X.509v3 certificate to be present to validate the certificate via consulting the CTL file. Consequently, the subject-name entry must be configured for a proxy certificate trustpoint. The subject name must be composed of the ordered concatenation of the CN, OU and O fields. The CN field is mandatory; the others are optional.

Each of the concatenated fields (when present) are separated by a semicolon, yielding one of the following forms:

CN=xxx;OU=yyy;O=zzzCN=xxx;OU=yyyCN=xxx;O=zzzCN=xxx

Step 5 Create an internal local CA to sign the LDC for Cisco IP Phones using the following commands, for example:

The username and password must match the username and password for Cisco Unified CallManager administration. The trustpoint name in the export command is the proxy certificate for the Cisco Unified CallManager server.

The default port number listened by the CTL Provider is TCP 2444, which is the default CTL port on the Cisco Unified CallManager. Use the service port command to change the port number if a different port is used by the Cisco Unified CallManager cluster.

Step 7 Create a TLS proxy instance using the following commands, for example:

hostname(config)# tls-proxy my_proxy

hostname(config-tlsp)# server trust-point ccm_proxy

hostname(config-tlsp)# client ldc issuer ldc_server

hostname(config-tlsp)# client ldc key-pair phone_common

hostname(config-tlsp)# client cipher-suite aes128-sha1 aes256-sha1

The server commands configure the proxy parameters for the original TLS server. In other words, the parameters for the security appliance to act as the server during a TLS handshake, or facing the original TLS client. The client commands configure the proxy parameters for the original TLS client. In other words, the parameters for the security appliance to act as the client during a TLS handshake, or facing the original TLS server.

Step 8 Enable TLS proxy for the Cisco IP Phones and Cisco Unified CallManagers in Skinny or SIP inspection using the following commands, for example:

Step 10 Run the CTL Client application to add the server proxy certificate (ccm_proxy) to the CTL file and install the CTL file on the security appliance. See the Cisco Unified CallManager document for information on how to configure and use CTL Client:

Note You will need the CTL Client that is released with Cisco Unified CallManager Release 5.1 to interoperate with the security appliance. See the "CTL Client" section for more information regarding TLS proxy support.

Debugging TLS Proxy

You may enable TLS proxy debug flags along with SSL syslogs to debug TLS proxy connection problems. For example, using the following commands to enable TLS proxy-related debug and syslog output only:

hostname(config)# debug inspect tls-proxy events

hostname(config)# debug inspect tls-proxy errors

hostname(config)# logging enable

hostname(config)# logging timestamp

hostname(config)# logging list loglist message 711001

hostname(config)# logging list loglist message 725001-725014

hostname(config)# logging list loglist message 717001-717038

hostname(config)# logging buffer-size 1000000

hostname(config)# logging buffered loglist

hostname(config)# logging debug-trace

The following is sample output reflecting a successful TLS proxy session setup for a SIP phone:

Figure 27-4 shows support for entering the security appliance IP address or domain name in the CTL Client.

Figure 27-5 CTL Client TLS Proxy Features — CTL Entry for ASA

Figure 27-5 shows that the CTL entry for the security appliance as the TLS proxy has been added. The CTL entry is added after the CTL Client connects to the CTL Provider service on the security appliance and retrieves the proxy certificate.

Cisco Unified Mobility and MMP Inspection Engine

Mobility Proxy Overview

To support Cisco UMA for the Cisco Unified Mobility solution, the mobility proxy (implemented as a TLS proxy) includes the following functionality:

•The ability to allow no client authentication during the handshake with clients.

•Allowing an imported PKCS-12 certificate to server as a proxy certificate.

The security appliance includes an inspection engine to validate the Cisco UMA Mobile Multiplexing Protocol (MMP).

MMP is a data transport protocol for transmitting data entities between Cisco UMA clients and servers. As shown in Figure 27-7, MMP must be run on top of a connection-oriented protocol (the underlying transport) and is intended to be run on top of a secure transport protocol such as TLS. The Orative Markup Language (OML) protocol is intended to be run on top of MMP for the purposes of data synchronization, as well as the HTTP protocol for uploading and downloading large files.

Figure 27-7 MMP Stack

The TCP/TLS default port is 5443. There are no embedded NAT or secondary connections.

Cisco UMA client and server communications can be proxied via TLS, which decrypts the data, passes it to the inspect MMP module, and re-encrypt the data before forwarding it to the endpoint. The inspect MMP module verifies the integrity of the MMP headers and passes the OML/HTTP to an appropriate handler. The security appliance takes the following actions on the MMP headers and data:

•Verifies that client MMP headers are well-formed. Upon detection of a malformed header, the TCP session is terminated.

•Verifies that client to server MMP header lengths are not exceeded. If an MMP header length is exceeded (4096), then the TCP session is terminated.

•Verifies that client to server MMP content lengths are not exceeded. If an entity content length is exceeded (4096), the TCP session is terminated.

Note 4096 is the value currently used in MMP implementations.

Because MMP headers and entities can be split across packets, the security appliance buffers data to ensure consistent inspection. The SAPI (stream API) handles data buffering for pending inspection opportunities. MMP header text is treated as case insensitive and a space is present between header text and values. Reclaiming of MMP state is performed by monitoring the state of the TCP connection.

Mobility Proxy Deployment Scenarios

Figure 27-8 and Figure 27-9 show the two deployment scenarios for the TLS proxy used by the Cisco Unified Mobility solution. In scenario 1 (the recommended deployment architecture), the security appliance functions as both the firewall and TLS proxy. In scenario 2, the security appliance functions as the TLS proxy only and works with an existing firewall. In both scenarios, the clients connect from the Internet.

In the scenario 1 deployment, the security appliance is between a Cisco UMA client and a Cisco UMA server. The Cisco UMA client is an executable that is downloaded to each smartphone. The Cisco UMA client applications establishes a data connection, which is a TLS connection, to the corporate Cisco UMA server. The security appliance intercepts the connections and inspects the data that the client sends to the Cisco UMA server.

Note The TLS proxy for the Cisco Unified Mobility solution does not support client authentication because the Cisco UMA client cannot present a certificate. The following commands can be used to disable authentication during the TLS handshake.hostname(config)# tls-proxy my_proxyhostname(config-tlsp)# no server authenticate-client

Figure 27-9 shows deployment scenario 2, where the security appliance functions as the TLS proxy only and does not function as the corporate firewall. In this scenario, the security appliance and the corporate firewall are performing NAT. The corporate firewall will not be able to predict which client from the Internet needs to connect to the corporate Cisco UMA server. Therefore, to support this deployment, you can take the following actions:

•Set up a NAT rule for inbound traffic that translates the destination IP address 192.0.2.41 to 172.16.27.41.

•Set up an interface PAT rule for inbound traffic translating the source IP address of every packet so that the corporate firewall does not need to open up a wildcard pinhole. The Cisco UMA server receives packets with the source IP address 192.0.12.183.

Note This interface PAT rule converges the Cisco UMA client IP addresses on the outside interface of the security appliance into a single IP address on the inside interface by using different source ports. Performing this action is often referred as "outside PAT". "Outside PAT" is not recommended when TLS proxy for Cisco Unified Mobility is enabled on the same interface of the security appliance with phone proxy, Cisco Unified Presence, or any other features involving application inspection. "Outside PAT" is not supported completely by application inspection when embedded address translation is needed.

Establishing Trust Relationships for Cisco UMA Deployments

To establish a trust relationship between the Cisco UMC client and the security appliance, the security appliance uses the Cisco UMA server certificate and keypair or the security appliance obtains a certificate with the Cisco UMA server FQDN (certificate impersonation). Between the security appliance and the Cisco UMA server, the security appliance and Cisco UMA server use self-signed certificates or certificates issued by a local certificate authority.

Figure 27-10 shows how you can import the Cisco UMA server certificate onto the security appliance. When the Cisco UMA server has already enrolled with a third-party CA, you can import the certificate with the private key onto the security appliance. Then, the security appliance has the full credentials of the Cisco UMA server. When a Cisco UMA client connects to the Cisco UMA server, the security appliance intercepts the handshake and uses the Cisco UMA server certificate to perform the handshake with the client. The security appliance also performs a handshake with the server.

Figure 27-11 shows another way to establish the trust relationship. Figure 27-11 shows a green field deployment, because each component of the deployment has been newly installed. The security appliance enrolls with the third-party CA by using the Cisco UMA server FQDN as if the security appliance is the Cisco UMA server. When the Cisco UMA client connects to the security appliance, the security appliance presents the certificate that has the Cisco UMA server FQDN. The Cisco UMA client believes it is communicating to with the Cisco UMA server.

A trusted relationship between the security appliance and the Cisco UMA server can be established with self-signed certificates. The security appliance's identity certificate is exported, and then uploaded on the Cisco UMA server truststore. The Cisco UMA server certificate is downloaded, and then uploaded on the security appliance truststore by creating a trustpoint and using the crypto ca authenticate command.

Configuring the Security Appliance for Cisco Unified Mobility

To configure for the security appliance to perform TLS proxy and MMP inspection as shown in Figure 27-8 and Figure 27-9, perform the following steps. It is assumed that self-signed certificates are used between the security appliance and the Cisco UMA server.

Step 1 Create the static NAT for the Cisco UMA server by entering the following command:

Step 2 Export the Cisco UMA server certificate and keypair in PKCS-12 format. Import it onto the security appliance. The certificate will be used during the handshake with the Cisco UMA clients.

hostname(config)# cryptocaimporttrustpointpkcs12passphrase

[paste base 64 encoded pkcs12]

hostname(config)# quit

Step 3 Install the Cisco UMA server self-signed certificate in the security appliance truststore. This step is necessary for the security appliance to authenticate the Cisco UMA server during the handshake between the security appliance proxy and Cisco UMA server.

hostname(config)# crypto ca trustpointtrustpoint_name

hostname(config-ca-trustpoint)# enrollment terminal

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca authenticatetrustpoint

hostname(config)# Enter the base 64 encoded CA certificate.

hostname(config)# End with a blank line or the word "quit" on a line by itself

Architecture for Cisco Unified Presence

Figure 27-12 depicts a Cisco Unified Presence/LCS Federation scenario with the security appliance as the presence federation proxy (implemented as a TLS proxy). The two entities with a TLS connection are the "Routing Proxy" (a dedicated Cisco UP) in Enterprise X and the Microsoft Access Proxy in Enterprise Y. However, the deployment is not limited to this scenario. Any Cisco UP or Cisco UP cluster could be deployed on the left side of the security appliance; the remote entity could be any server (an LCS, an OCS, or another Cisco UP).

The following architecture is generic for two servers using SIP (or other security appliance inspected protocols) with a TLS connection.

In the above architecture, the security appliance functions as a firewall, NAT, and TLS proxy, which is the recommended architecture. However, the security appliance can also function as NAT and the TLS proxy alone, working with an existing firewall.

Either server can initiate the TLS handshake (unlike IP Telephony or Cisco Unified Mobility, where only the clients initiate the TLS handshake). There are by-directional TLS proxy rules and configuration. Each enterprise can have an security appliance as the TLS proxy.

In Figure 27-12, NAT or PAT can be used to hide the private address of Entity X. In this situation, static NAT or PAT must be configured for foreign server (Entity Y) initiated connections or the TLS handshake (inbound). Typically, the public port should be 5061. The following static PAT command is required for the Cisco UP that accepts inbound connections:

Figure 27-13 illustrates an abstracted scenario with Entity X connected to Entity Y through the presence federation proxy on the security appliance. The proxy is in the same administrative domain as Entity X. Entity Y could have another security appliance as the proxy but this is omitted for simplicity.

For the Entity X domain name to be resolved correctly when the security appliance holds its credential, the security appliance could be configured to perform NAT for Entity X, and the domain name is resolved as the Entity X public address for which the security appliance provides proxy service.

Establishing a Trust Relationship in the Presence Federation

Within an enterprise, setting up a trust relationship is achievable by using self-signed certificates or you can set it up on an internal CA.

Establishing a trust relationship cross enterprises or across administrative domains is key for federation. Cross enterprises you must use a trusted third-party CA (such as, VeriSign). The security appliance obtains a certificate with the FQDN of the Cisco UP (certificate impersonation).

For the TLS handshake, the two entities could validate the peer certificate via a certificate chain to trusted third-party certificate authorities. Both entities enroll with the CAs. The security appliance as the TLS proxy must be trusted by both entities. The security appliance is always associated with one of the enterprises. Within that enterprise (Enterprise X in Figure 27-12), the entity and the security appliance could authenticate each other via a local CA, or by using self-signed certificates.

To establish a trusted relationship between the security appliance and the remote entity (Entity Y), the security appliance can enroll with the CA on behalf of Entity X (Cisco UP). In the enrollment request, the Entity X identity (domain name) is used.

Figure 27-14 shows the way to establish the trust relationship. The security appliance enrolls with the third party CA by using the Cisco UP FQDN as if the security appliance is the Cisco UP.

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

You need to generate the keypair for the certificate (such as cup_proxy_key) used by the security appliance, and configure a trustpoint to identify the self-signed certificate sent by the security appliance to Cisco UP (such as cup_proxy) in the TLS handshake.

For the security appliance to trust the Cisco UP certificate, you need to create a trustpoint to identify the certificate from the Cisco UP (such as cert_from_cup), and specify the enrollment type as terminal to indicate that you will paste the certificate received from the Cisco UP into the terminal.

Configuring the Presence Federation Proxy for Cisco Unified Presence

To configure a Cisco Unified Presence/LCS Federation scenario with the security appliance as the TLS proxy where there is a single Cisco UP that is in the local domain and self-signed certificates are used between the Cisco UP and the security appliance (like the scenario shown in Figure 27-12), perform the following steps.

Step 1 Create the following static NAT for the local domain containing the Cisco UP.

For the inbound connection to the local domain containing the Cisco UP, create static PAT by entering the following command:

The keypair is used by the self-signed certificate presented to the local domain containing the Cisco UP (proxy for the remote entity).

Step 3 Create a proxy certificate, which is a self-signed certificate, for the remote entity by entering the following commands:

hostname(config)# crypto ca trustpointtrustpoint_name

hostname(config-ca-trustpoint)# enrollment self

hostname(config-ca-trustpoint)# fqdn none

hostname(config-ca-trustpoint)# subject-nameX.500_name

hostname(config-ca-trustpoint)# keypairkeyname

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca enrolltrustpoint

You will install the certificate on the local entity truststore. You could also enroll the certificate with a local CA trusted by the local entity.

Step 4 Export the self-signed certificate for the security appliance created in Step 3 and install it as a trusted certificate on the local entity. This step is necessary for local entity to authenticate the security appliance.

Export the security appliance self-signed (identity) certificate by entering the following command:

hostname(config)# crypto ca exporttrustpointidentity-certificate

Step 5 Export the local entity certificate and install it on the security appliance by entering the following commands. This step is needed for the security appliance to authenticate the local entity during the handshake. If the local entity uses a self-signed certificate, the self-signed certificate must be installed; if the local entity uses a CA-issued certificate, the CA certificate needs to be installed. The following configuration shows the commands for using a self-signed certificate.

hostname(config)# crypto ca trustpointtrustpoint_name

hostname(config-ca-trustpoint)# enrollment terminal

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca authenticatetrustpoint

hostname(config)# Enter the base 64 encoded CA certificate.

hostname(config)# End with a blank line or the word "quit" on a line by itself

[ certificate data omitted ]

hostname(config)# quit

Step 6 To create a proxy certificate on the security appliance that is trusted by the remote entity, obtain a certificate from a trusted CA. For information about obtaining a certificate from a trusted CA, see Certificate Configuration.

Step 7 Install the CA certificate that signs the remote entity certificate on the security appliance by entering the following commands. This step is necessary for the security appliance to authenticate the remote entity.

hostname(config)# crypto ca trustpointtrustpoint_name

hostname(config-ca-trustpoint)# enrollment terminal

hostname(config-ca-trustpoint)# exit

hostname(config)# crypto ca authenticatetrustpoint

hostname(config)# Enter the base 64 encoded CA certificate.

hostname(config)# End with a blank line or the word "quit" on a line by itself

[ certificate data omitted ]

hostname(config)# quit

Step 8 Create TLS proxy instances for the local and remote entity initiated connections respectively. The entity that initiates the TLS connection is in the role of "TLS client". Because the TLS proxy has a strict definition of "client" and "server" proxy, two TLS proxy instances must be defined if either of the entities could initiate the connection.

! Local entity to remote entity

hostname(config)# tls-proxyproxy_name

hostname(config-tlsp)# server trust-pointproxy_name

hostname(config-tlsp)# client trust-pointproxy_trustpoint

hostname(config-tlsp)# client cipher-suitecipher_suite

Where the proxy_name for the server trust-point command is the remote entity proxy name and the proxy_trustpoint for the client trust-point command is the local entity proxy.

! Remote entity to local entity

hostname(config)# tls-proxyproxy_name

hostname(config-tlsp)# server trust-pointproxy_name

hostname(config-tlsp)# client trust-pointproxy_trustpoint

hostname(config-tlsp)# client cipher-suitecipher_suite

Where the proxy_name for the server trust-point command is the local entity proxy name and the proxy_trustpoint for the client trust-point command is the remote entity proxy.

Step 9 Enable the TLS proxy for SIP inspection and define policies for both entities that could initiate the connection by entering the following commands:

Figure 27-18 shows an example of the configuration for a mixed-mode Cisco UCM cluster using the following topology where the TFTP server resides on a different server from the primary and secondary Cisco UCMs.

In this sample, the static interface PAT for the TFTP server is configured to appear like the security appliance's outside interface IP address.

Figure 27-19 shows an example of the configuration for a mixed-mode Cisco UCM cluster where LSC provisioning is required using the following topology.

Note Doing LSC provisioning for remote IP phones is not recommended because it requires that the IP phones first register and they have to register in nonsecure mode. Having the IP phones register in nonsecure mode requires the Administrator to open the nonsecure signaling port for SIP and SCCP on the security appliance. If possible, LSC provisioning should be done inside the corporate network before giving the IP phones to the end-users.

In this sample, you create an access list to allow the IP phones to contact the TFTP server and to allow the IP phones to register in nonsecure mode by opening the nonsecure port for SIP and SCCP as well as the CAPF port for LSC provisioning.

Additionally, you create the CAPF trustpoint by copying and pasting the CAPF certificate from the Cisco UCM Certificate Management software.

Example 6: VLAN Transversal

Figure 27-20 shows an example of the configuration to force Cisco IP Communicator (CIPC) softphones to operate in authenticated mode when CIPC softphones are deployed in a voice and data VLAN scenario. VLAN transversal is required between CIPC softphones on the data VLAN and hard phones on the voice VLAN.

In this sample, the Cisco UCM cluster mode is nonsecure.

In this sample, you create an access list to allow the IP phones to contact the TFTP server and to allow the IP phones to register in nonsecure mode by opening the nonsecure port for SIP and SCCP as well as the CAPF port for LSC provisioning.

In this sample, you configure NAT for the CIPC by using PAT so that each CIPC is mapped to an IP address space in the Voice VLAN.

Additionally, you create the CAPF trustpoint by copying and pasting the CAPF certificate from the Cisco UCM Certificate Management software.

Note Cisco IP Communicator supports authenticated mode only and does not support encrypted mode; therefore, there is no encrypted voice traffic (SRTP) flowing from the CIPC softphones.

The phone proxy and CIPC are not supported when CIPC is installed on computers in remote locations, such that the calls from those computers traverse the Internet, terminating at the security appliance, to reach IP phones residing on the network behind the adaptive security appliance. The computers where CIPC is installed must be on the network to reach the IP phones behind the security appliance.

Figure 27-20 VLAN Transversal Between CIPC Softphones on the Data VLAN and Hard Phones on the Voice VLAN

This section describes sample configurations that apply to two deployment scenarios for the TLS proxy used by the Cisco Unified Mobility solution—scenario 1 where the security appliance functions as both the firewall and TLS proxy and scenario 2 where the security appliance functions as the TLS proxy only. In both scenarios, the clients connect from the Internet.

In the samples, you export the Cisco UMA server certificate and key-pair in PKCS-12 format and import it to the security appliance. The certificate will be used during handshake with the Cisco UMA clients.

Installing the Cisco UMA server self-signed certificate in the security appliance truststore is necessary for the security appliance to authenticate the Cisco UMA server during handshake between the security appliance proxy and Cisco UMA server. You create a TLS proxy instance for the Cisco UMA clients connecting to the Cisco UMA server. Lastly, you must enable TLS proxy for MMP inspection.

As shown in Figure 27-21 (scenario 1—the recommended architecture), the security appliance functions as both the firewall and TLS proxy. In the scenario 1 deployment, the security appliance is between a Cisco UMA client and a Cisco UMA server. In this scenario, the security appliance performs static NAT by translating the Cisco UMA server 10.1.1.2 IP address to 192.0.2.140.

As shown in Figure 27-22 (scenario 2), the security appliance functions as the TLS proxy only and works with an existing firewall. The security appliance and the corporate firewall are performing NAT. The corporate firewall will not be able to predict which client from the Internet needs to connect to the corporate Cisco UMA server. Therefore, to support this deployment, you can take the following actions:

•Set up a NAT rule for inbound traffic that translates the destination IP address 192.0.2.41 to 172.16.27.41.

•Set up an interface PAT rule for inbound traffic translating the source IP address of every packet so that the corporate firewall does not need to open up a wildcard pinhole. The Cisco UMA server receives packets with the source IP address 67.11.12.183.

Cisco Unified Presence Sample Configuration

The following sample illustrates the necessary configuration for the security appliance to perform TLS proxy for Cisco Unified Presence as shown in Figure 27-23. It is assumed that a single Cisco UP (Entity X) is in the local domain and self-signed certificates are used between Entity X and the ASA.

For each Cisco UP that could initiate a connection (by sending SIP SUBSCRIBE) to the foreign server, you must also configure static PAT and if you have another Cisco UP with the address (10.0.0.3 in this sample), it must use a different set of PAT ports (such as 45062 or 45070). Dynamic NAT or PAT can be used for outbound connections or TLS handshake. The security appliance SIP inspection engine takes care of the necessary translation (fixup).

When you create the necessary RSA key pairs, a key pair is used by the self-signed certificate presented to Entity X (proxy for Entity Y). When you create a proxy certificate for Entity Y, the certificate is installed on the Entity X truststore. It could also be enrolled with a local CA trusted by Entity X.

Exporting the security appliance self-signed certificate (ent_y_proxy) and installing it as a trusted certificate on Entity X is necessary for Entity X to authenticate the security appliance. Exporting the Entity X certificate and installing it on the security appliance is needed for the security appliance to authenticate Entity X during handshake with X. If Entity X uses a self-signed certificate, the self-signed certificate must be installed; if Entity X uses a CA issued the certificate, the CA's certificated needs to be installed.

Installing the CA certificate that signs the Entity Y certificate on the security appliance is necessary for the security appliance to authenticate Entity Y.

When creating TLS proxy instances for Entity X and Entity Y, the entity that initiates the TLS connection is in the role of "TLS client". Because the TLS proxy has strict definition of "client" and "server" proxy, two TLS proxy instances must be defined if either of the entities could initiate the connection.

When enabling the TLS proxy for SIP inspection, policies must be defined for both entities that could initiate the connection.