51-15
Cisco ASA 5500 Series Configuration Guide using the CLI
Chapter51 Configuring Cisco Unified Presence
Configuration Example for Cisco Unified Presence
•Example Access List Configuration for XMPP Federation, page51-17
•Example NAT Configuration for XMPP Federation, page51-18
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 on
page 41-9.
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.