- About This Guide
- Index
- Glossary
-
- Configuring IPSec and ISAKMP
- Configuring L2TP over IPSec
- Setting General VPN Parameters
- Configuring Tunnel Groups, Group Policies, and Users
- Configuring IP Addresses for VPN
- Configuring Remote Access VPNs
- Configuring Network Admission Control
- Configuring Easy VPN on the ASA 5505
- Configuring the PPPoE Client
- Configuring LAN-to-LAN VPNs
- Configuring Clientless SSL VPN
- Configuring AnyConnect VPN Client Connections
- Configuring AnyConnect Host Scan
Configuring Cisco Unified Presence
This chapter describes how to configure the adaptive security appliance for Cisco Unified Presence.
Information About Cisco Unified Presence
This section includes the following topics:
- Architecture for Cisco Unified Presence for SIP Federation Deployments
- Trust Relationship in the Presence Federation
- Security Certificate Exchange Between Cisco UP and the Security Appliance
- XMPP Federation Deployments
- Configuration Requirements for XMPP Federation
Architecture for Cisco Unified Presence for SIP Federation Deployments
Figure 51-1 depicts a Cisco Unified Presence/LCS Federation scenario with the ASA 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 ASA; 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 ASA inspected protocols) with a TLS connection.
Entity X: Cisco UP/Routing Proxy in Enterprise X
Entity Y: Microsoft Access Proxy/Edge server for LCS/OCS in Enterprise Y
Figure 51-1 Typical Cisco Unified Presence/LCS Federation Scenario
In the above architecture, the ASA functions as a firewall, NAT, and TLS proxy, which is the recommended architecture. However, the ASA 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 ASA as the TLS proxy.
In Figure 51-1, 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:
The following static PAT must be configured for each Cisco UP that could initiate a connection (by sending SIP SUBSCRIBE) to the foreign server.
For Cisco UP with the address 10.0.0.2, enter the following command:
For another Cisco UP with the address 10.0.0.3, you must use a different set of PAT ports, such as 45062 or 45070:
Dynamic NAT or PAT can be used for the rest of the outbound connections or the TLS handshake. The ASA SIP inspection engine takes care of the necessary translation (fixup).
Figure 51-2 illustrates an abstracted scenario with Entity X connected to Entity Y through the presence federation proxy on the ASA. The proxy is in the same administrative domain as Entity X. Entity Y could have another ASA as the proxy but this is omitted for simplicity.
Figure 51-2 Abstracted Presence Federation Proxy Scenario between Two Server Entities
For the Entity X domain name to be resolved correctly when the ASA holds its credential, the ASA could be configured to perform NAT for Entity X, and the domain name is resolved as the Entity X public address for which the ASA provides proxy service.
For further information about configuring Cisco Unified Presence Federation for SIP Federation, see the Integration Guide for Configuring Cisco Unified Presence for Interdomain Federation.:
http://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html
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 ASA 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 ASA as the TLS proxy must be trusted by both entities. The ASA is always associated with one of the enterprises. Within that enterprise (Enterprise X in Figure 51-1), the entity and the ASA could authenticate each other via a local CA, or by using self-signed certificates.
To establish a trusted relationship between the ASA and the remote entity (Entity Y), the ASA 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 51-3 shows the way to establish the trust relationship. The ASA enrolls with the third party CA by using the Cisco UP FQDN as if the ASA is the Cisco UP.
Figure 51-3 How the Security Appliance Represents Cisco Unified Presence – Certificate Impersonate
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 ASA, and configure a trustpoint to identify the self-signed certificate sent by the ASA to Cisco UP (such as cup_proxy
) in the TLS handshake.
For the ASA 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.
XMPP Federation Deployments
Figure 51-4 provides an example of an XMPP federated network between Cisco Unified Presence enterprise deployment and an IBM Sametime enterprise deployment. TLS is optional for XMPP federation. ASA acts only as a firewall for XMPP federation; it does not provide TLS proxy functionality or PAT for XMPP federation.
Figure 51-4 Basic XMPP Federated Network between Cisco Unified Presence and IBM Sametime
There are two DNS servers within the internal Cisco Unified Presence enterprise deployment. One DNS server hosts the Cisco Unified Presence private address. The other DNS server hosts the Cisco Unified Presence public address and a DNS SRV records for SIP federation (_sipfederationtle), and XMPP federation (_xmpp-server) with Cisco Unified Presence. The DNS server that hosts the Cisco Unified Presence public address is located in the local DMZ.
For further information about configuring Cisco Unified Presence Federation for XMPP Federation, see the Integration Guide for Configuring Cisco Unified Presence Release 8.0 for Interdomain Federation :
http://www.cisco.com/en/US/products/ps6837/products_installation_and_configuration_guides_list.html
Configuration Requirements for XMPP Federation
For XMPP Federation, ASA acts as a firewall only. You must open port 5269 for both incoming and outgoing XMPP federated traffic on ASA.
These are sample access lists to open port 5269 on ASA.
Allow traffic from any address to any address on port 5269:
access-list ALLOW-ALL extended permit tcp any any eq 5269
Allow traffic from any address to any single node on port 5269:
access-list ALLOW-ALL extended permit tcp any host <private cup IP address> eq 5269
If you do not configure the access list above, and you publish additional XMPP federation nodes in DNS, you must configure access to each of these nodes, for example:
Configure the following NAT commands:
If you publish a single public IP address in DNS, and use arbitrary ports, configure the following:
(This example is for two additional XMPP federation nodes)
If you publish multiple public IP addresses in DNS all using port 5269, configure the following:
(This example is for two additional XMPP federation nodes)
Licensing for Cisco Unified Presence
The Cisco Unified Presence feature supported by the ASA require a Unified Communications Proxy license.
The following table shows the Unified Communications Proxy license details by platform:
Note This feature is not available on No Payload Encryption models.
|
|
---|---|
Optional licenses: 24, 50, 100, 250, 500, 750, or 1000 sessions. |
|
Optional licenses: 24, 50, 100, 250, 500, 750, 1000, or 2000 sessions. |
|
Optional licenses: 24, 50, 100, 250, 500, 750, 1000, 2000, or 3000 sessions. |
|
Optional licenses: 24, 50, 100, 250, 500, 750, 1000, 2000, 3000, 5000, or 10,000 sessions.2 |
|
Optional licenses: 24, 50, 100, 250, 500, 750, or 1000 sessions. |
|
Optional licenses: 24, 50, 100, 250, 500, 750, 1000, or 2000 sessions. |
|
Optional licenses: 24, 50, 100, 250, 500, 750, 1000, 2000, or 3000 sessions. |
|
Optional licenses: 24, 50, 100, 250, 500, 750, 1000, 2000, or 3000 sessions. |
|
Optional licenses: 24, 50, 100, 250, 500, 750, 1000, 2000, 3000, 5000, or 10,000 sessions. 2 |
For more information about licensing, see Chapter4, “Managing Feature Licenses”
Configuring Cisco Unified Presence Proxy for SIP Federation
This section contains the following topics:
- Task Flow for Configuring Cisco Unified Presence Federation Proxy for SIP Federation
- Creating Trustpoints and Generating Certificates
- Installing Certificates
- Creating the TLS Proxy Instance
- Enabling the TLS Proxy for SIP Inspection
Task Flow for Configuring Cisco Unified Presence Federation Proxy for SIP Federation
To configure a Cisco Unified Presence/LCS Federation scenario with the ASA 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 ASA (like the scenario shown in Figure 51-1), perform the following tasks.
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:
Note For each Cisco UP that could initiate a connection (by sending SIP SUBSCRIBE) to the foreign server, you must also configure static PAT by using a different set of PAT ports.
For outbound connections or the TLS handshake, use dynamic NAT or PAT. The ASA SIP inspection engine takes care of the necessary translation (fixup).
For information about configuring NAT and PAT for the Cisco Presence Federation proxy, see Chapter 30, “Configuring Network Object NAT” and Chapter 31, “Configuring Twice NAT”.
Step 2 Create the necessary RSA keypairs and proxy certificate, which is a self-signed certificate, for the remote entity. See Creating Trustpoints and Generating Certificates.
Step 3 Install the certificates. See Installing Certificates.
Step 4 Create the TLS proxy instance for the Cisco UP clients connecting to the Cisco UP server. See Creating the TLS Proxy Instance.
Step 5 Enable the TLS proxy for SIP inspection. See Enabling the TLS Proxy for SIP Inspection.
Creating Trustpoints and Generating Certificates
You need to generate the keypair for the certificate (such as cup_proxy_key
) used by the ASA, and configure a trustpoint to identify the self-signed certificate sent by the ASA to Cisco UP (such as cup_proxy
) in the TLS handshake.
Install the certificate on the local entity truststore. You could also enroll the certificate with a local CA trusted by the local entity. See the “Installing Certificates” section.
Installing Certificates
Export the self-signed certificate for the ASA created in the “Creating Trustpoints and Generating Certificates” section and install it as a trusted certificate on the local entity. This task is necessary for local entity to authenticate the ASA.
To create a proxy certificate on the ASA 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 the “Configuring Digital Certificates” section.
Once you have created the trustpoints and installed the certificates for the local and remote entities on the ASA, create the TLS proxy instance. See Creating the TLS Proxy Instance.
Creating the TLS Proxy Instance
Because either server can initiate the TLS handshake (unlike IP Telephony or Cisco Unified Mobility, where only the clients initiate the TLS handshake), you must configure by-directional TLS proxy rules. Each enterprise can have an ASA as the TLS proxy.
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.
Once you have created the TLS proxy instance, enable it for SIP inspection. See Enabling the TLS Proxy for SIP Inspection.
Enabling the TLS Proxy for SIP Inspection
Enable the TLS proxy for SIP inspection and define policies for both entities that could initiate the connection.
Monitoring Cisco Unified Presence
Debugging is similar to debugging TLS proxy for IP Telephony. You can enable TLS proxy debug flags along with SSL syslogs to debug TLS proxy connection problems.
For example, use the following commands to enable TLS proxy-related debug and syslog output only:
For information about TLS proxy debugging techniques and sample output, see Monitoring the TLS Proxy.
Enable the debug sip command for SIP inspection engine debugging. See the command reference.
Additionally, you can capture the raw and decrypted data by the TLS proxy by entering the following commands:
Configuration Example for Cisco Unified Presence
This section contains the following topics:
- Example Configuration for SIP Federation Deployments
- Example Access List Configuration for XMPP Federation
- Example NAT Configuration for XMPP Federation
Example Configuration for SIP Federation Deployments
The following sample illustrates the necessary configuration for the ASA to perform TLS proxy for Cisco Unified Presence as shown in Figure 51-5. 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 ASA 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 ASA self-signed certificate (ent_y_proxy) and installing it as a trusted certificate on Entity X is necessary for Entity X to authenticate the ASA. Exporting the Entity X certificate and installing it on the ASA is needed for the ASA 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.
For about obtaining a certificate from a trusted CA, see the “Configuring Digital Certificates” section.
Installing the CA certificate that signs the Entity Y certificate on the ASA is necessary for the ASA 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.
Figure 51-5 Typical Cisco Unified Presence/LCS Federation Scenario
Example Access List Configuration for XMPP Federation
Example 1: This example access list configuration allows from any address to any address on port 5269:
Example 2: This example access list configuration allows from any address to any single XMPP federation node on port 5269. The following values are used in this example:
- Private XMPP federation Cisco Unified Presence Release 8.0 IP address = 1.1.1.1
- XMPP federation listening port = 5269
Example 3: This example access list configuration allows from any address to specific XMPP federation nodes published in DNS.
Note The public addresses are published in DNS, but the private addresses are configured in the access-list command.
The following values are used in this sample configuration:
• Private XMPP federation Cisco Unified Presence Release 8.0 IP address = 1.1.1.1
• Private second Cisco Unified Presence Release 8.0 IP address= 2.2.2.2
• Private third Cisco Unified Presence Release 7.x IP address = 3.3.3.3
• XMPP federation listening port = 5269
Example 4: This example access list configuration allows only from a specific federated domain interface to specific XMPP federation nodes published in DNS.
Note The public addresses are published in DNS, but the private addresses are configured in the access-list command.
The following values are used in this sample configuration:
- Private XMPP federation Cisco Unified Presence Release 8.0 IP address = 1.1.1.1
- Private second Cisco Unified Presence Release 8.0 IP address = 2.2.2.2
- Private third Cisco Unified Presence Release 7.x IP address = 3.3.3.3
- XMPP federation listening port = 5269
- External interface of the foreign XMPP enterprise = 100.100.100.100
Example NAT Configuration for XMPP Federation
Example 1 : Single node with XMPP federation enabled
The following values are used in this sample configuration:
- Public Cisco Unified Presence IP address = 10.10.10.10
- Private XMPP federation Cisco Unified Presence Release 8.0 IP address = 1.1.1.1
- XMPP federation listening port = 5269
Example 2 : Multiple nodes with XMPP federation, each with a public IP address in DNS
The following values are used in this sample configuration:
- Public Cisco Unified Presence IP addresses = 10.10.10.10, 20.20.20.20, 30.30.30.30
- Private XMPP federation Cisco Unified Presence Release 8.0 IP address = 1.1.1.1
- Private second Cisco Unified Presence Release 8.0 IP address = 2.2.2.2
- Private third Cisco Unified Presence Release 7.x IP address = 3.3.3.3
- XMPP federation listening port = 5269
Example 3: Multiple nodes with XMPP federation, but a single public IP address in DNS with arbitrary
The following values are used in this sample configuration:
- Public Cisco Unified Presence IP Address = 10.10.10.10
- Private XMPP federation Cisco Unified Presence Release 8.0 IP address = 1.1.1.1, port 5269
- Private second Cisco Unified Presence Release 8.0 IP address = 2.2.2.2, arbitrary port 25269
- Private third Cisco Unified Presence Release 7.x IP address = 3.3.3.3, arbitrary port 35269
Feature History for Cisco Unified Presence
Table 51-1 lists the release history for this feature.
|
|
|
---|---|---|
The Unified Communications Wizard was added to ASDM. By using the wizard, you can configure the Cisco Presence Federation Proxy. |