Cisco Expressway provides a way for organisations running Cisco Unified Communications Manager to extend collaboration services to users outside the corporate network.
For Mobile and Remote Access (MRA), the deployment normally consists of an Expressway-C on the internal network and an Expressway-E in a DMZ or equivalent perimeter network. The Expressway pair provides the secure boundary between remote clients and the internal Unified Communications environment.
This article is a deployment reference rather than a walkthrough from a specific installation. It brings the important parts of an MRA deployment together, but it does not claim to be a record of a particular production deployment. Where the exact procedure depends on the Expressway release, I have linked Cisco’s documentation so you can check the version-specific requirements before making changes.
Cisco’s current documentation set is in the X15.x release family. At the time of writing, Cisco’s Expressway configuration guides index lists the following as the most recent published guides:
| Guide | Release |
|---|---|
| Cluster Creation and Maintenance Deployment Guide | X15.4 |
| Mobile and Remote Access Through Cisco Expressway Deployment Guide | X15.2 |
| Certificate Creation and Use Deployment Guide | X15.0 |
| IP Port Usage Configuration Guide | Covers X14.3 and X15.0 |
Check that index before starting, because the guide releases do not track the software release numbers and a newer document may have been published since.
Expressway-C and Expressway-E architecture
The two Expressway servers have different jobs.
Expressway-C sits on the internal network and communicates with the internal Unified Communications environment:
- Cisco Unified Communications Manager
- IM and Presence Service
- Cisco Unity Connection, where required
- Internal DNS and other enterprise services required by the deployment
Expressway-E sits at the network edge. It is the system that remote clients discover and connect to from the internet.
A simplified deployment looks like this:
Remote Jabber / MRA client
|
Internet
|
Expressway-E
DMZ
|
UC traversal
|
Expressway-C
Internal LAN
|
+------+------+
| | |
CUCM IM&P Unity
The important security boundary is that the internal Unified Communications servers and Expressway-C should not be exposed directly to the internet. The external client connection terminates at Expressway-E.
Cisco describes MRA as part of its Collaboration Edge architecture, with Expressway providing the secure firewall traversal and support for Unified CM registrations from endpoints outside the enterprise network. Cisco’s Understand Mobile and Remote Access technote covers the traffic flows and certificate exchange in more detail than the deployment guide does.
What you need before installing Expressway
The Expressway installation itself is not usually the difficult part. Most MRA problems are caused by something around the Expressway.
Before deploying the VMs, have these things defined:
- Expressway-C hostname and FQDN
- Expressway-E hostname and FQDN
- Internal DNS
- External DNS
- The domain users will use for service discovery
- Internal IP addressing and routing
- DMZ addressing and firewall rules
- NAT design
- NTP
- Certificate authority
- Unified CM details
- IM and Presence details, if required
- Unity Connection details, if required
- Required Expressway licensing
Do not start configuring the traversal zone until DNS, time synchronisation and certificates have been considered.
One requirement worth stating explicitly: Expressway-C and Expressway-E need separate IP addresses. A shared address doesn’t work, because the firewall can’t distinguish between the two elements.
Cisco also recommends a single domain with a split DNS configuration as the ideal MRA scenario. Other arrangements are supported, but they add complexity to both the DNS and certificate design.
Deploying the Expressway virtual machines
Cisco supplies Expressway as a virtual appliance. The exact OVA and supported virtualisation requirements depend on the Expressway release.
The deployment process is straightforward:
- Download the OVA for the Expressway release being deployed.
- Verify the downloaded software against Cisco’s published information.
- Deploy the OVA through vCenter.
- Select the appropriate Expressway capacity point.
- Map the network interfaces to the correct networks.
- Configure the initial network settings.
- Power on the appliance.
- Complete the initial Expressway setup.
There is little value in reproducing every VMware wizard screen here. Cisco already documents that process, and the screens and supported options change between releases.
Check Cisco’s current virtualisation documentation for the supported ESXi versions and the CPU, memory and disk requirements for the Small, Medium and Large Expressway configurations before deploying.
Two things worth knowing that aren’t obvious from the wizard:
Don’t casually modify the virtual hardware after deployment. The OVA is built around the required deployment configuration, and changing it can affect supportability.
Don’t change the VM’s MAC address. The Expressway serial number is derived from it, which means licensing depends on it.
Configure Expressway-C first
Once the two appliances are available, configure Expressway-C before building the external side.
The configuration sequence is broadly:
- Configure the system hostname and domain.
- Configure DNS.
- Configure NTP and timezone.
- Configure the Unified Communications domains.
- Enable Mobile and Remote Access.
- Add Unified CM.
- Add IM and Presence if required.
- Add Unity Connection if required.
- Install the required certificates.
- Configure the secure traversal zone to Expressway-E.
The exact menu names can change between Expressway releases, so use the menus displayed by the version you have installed rather than following screenshots from an old release.
Cisco’s Mobile and Remote Access Through Cisco Expressway Deployment Guide provides the detailed configuration task flow, including server addressing, SIP, automated intrusion protection, MRA, domains, Unified Communications servers, access control, OAuth and the secure traversal zone. It’s linked from the configuration guides index under the X15.x heading.
Enable Mobile and Remote Access
On Expressway-C:
Configuration > Unified Communications > Configuration
Set:
Unified Communications mode: Mobile and Remote Access
Save the configuration.
Repeat the configuration on Expressway-E.
MRA mode needs to be enabled on both Expressways before continuing with the rest of the MRA configuration.
Configure the MRA domain
Go to:
Configuration > Domains
Add the domain that users will use for MRA service discovery.
For example:
example.com
Do not use an arbitrary internal domain simply because it happens to be the Active Directory domain.
The domain matters because remote clients use it when performing the _collab-edge._tls service discovery lookup.
The internal Unified CM domain and external service-discovery domain can be different, depending on the design. If they are different, make sure the Expressway configuration, DNS records and certificates all reflect that design.
Add Unified CM
On Expressway-C:
Configuration > Unified Communications > Unified CM Servers
Add the Unified CM publisher or appropriate Unified CM cluster information.
Expressway-C needs to communicate with Unified CM over the required internal ports, and the Unified CM environment must meet the requirements for MRA.
Do not simply disable TLS verification because it makes an initial connection work. If certificate verification fails, investigate the certificate and trust configuration.
Configure IM and Presence and Unity Connection
These components are optional depending on what you want MRA to provide.
If IM and Presence is being used, configure the IM and Presence Service nodes through Expressway-C.
If remote users need voicemail services through MRA, configure the required Unity Connection access through Expressway-C.
Configure the services the deployment actually requires rather than copying every possible Unified Communications integration into the configuration.
Certificates are one of the important parts
Certificates deserve more attention than most Expressway guides give them.
Expressway-C and Expressway-E need certificates that satisfy the requirements of the services they provide. The Expressway pair also needs to trust the certificates presented by the other side.
The Expressway-E server certificate needs the relevant Unified CM registration and service-discovery domains in its Subject Alternative Name list. Expressway validates against the SAN rather than relying on the Common Name alone.
That means a certificate such as:
CN = expresswaye.example.com
is not automatically sufficient simply because the hostname is correct.
The SANs need to match the names used by the deployment.
For example, if the external service-discovery domain is:
example.com
and the Expressway-E is:
expresswaye.example.com
the certificate needs to be designed around the actual Cisco requirements for that deployment.
This is one of the first places to look when a traversal zone refuses to establish or remote clients fail during TLS negotiation.
For the current requirements, use Cisco’s Certificate Creation and Use Deployment Guide from the configuration guides index.
SHA-1 certificates are a specific upgrade concern
This is one area where using an old Expressway guide can actively cause problems.
SHA-1 signed certificates have been deprecated across the X15 releases, and newer Expressway builds can refuse to accept them. On some releases, an upgrade will stop if an existing SHA-1 certificate is detected on the system.
Check the release notes for the exact release you are moving to, and check the certificates already installed on an older Expressway before starting an upgrade rather than discovering the problem partway through.
This is a good example of why a 12.5-era Expressway article shouldn’t simply be updated by changing the version number.
Public CA or internal CA?
Both approaches can be used, but the certificate chain must be trusted by the clients that need to connect.
This becomes more significant if the environment is moving from Cisco Jabber to Webex App for Unified CM calling, where the client trust requirements and certificate revocation handling differ.
If the deployment is expected to remain in place for several years, treat certificate design as part of the architecture rather than something to sort out after installation.
Configure Expressway-E
Expressway-E is the internet-facing component, so its configuration should be kept deliberately separate from the internal Expressway-C.
Configure:
- Hostname
- Domain
- DNS
- NTP
- Network interfaces
- Default gateway
- NAT
- MRA mode
- Server certificate
- Trusted CA certificates
- Traversal zone
If using the dual-network-interface design, make sure the internal and external interfaces are mapped to the intended networks and that the NAT design matches the requirements for the Expressway release.
Do not assume that because the Expressway-E web interface is reachable from the internet, MRA is working. The web interface, TLS service discovery, traversal connection and media path are separate things to test.
Configure the Unified Communications traversal zone
The traversal zone is the connection between Expressway-C and Expressway-E.
Create a zone of type:
Unified Communications traversal
This is an encrypted connection between the two Expressways, using SIP TLS with certificate verification.
The Expressway-C side needs the FQDN of Expressway-E.
For example:
expresswaye.example.com
Do not use an IP address unless there is a specific reason to do so. If an IP address is used, it needs to satisfy the certificate requirements for the deployment.
For a dual-NIC Expressway-E, also make sure Expressway-C resolves the appropriate FQDN to the intended internal interface.
The traversal zone should eventually show an Active status.
That status is important, but it does not prove that MRA works end to end. A healthy traversal zone only tells you that the Expressway pair has established its relationship.
DNS is where many MRA deployments go wrong
MRA service discovery depends heavily on DNS.
For external clients, the important record is:
_collab-edge._tls.example.com
That record should point to the Expressway-E service.
Internal service discovery uses records such as:
_cisco-uds._tcp.example.com
_cuplogin._tcp.example.com
The exact records required depend on the client and Unified Communications deployment.
The principle is simple:
Internal clients must discover the internal UC services, while external clients must discover Expressway-E.
Test the records from both sides
From an internal Windows machine:
Resolve-DnsName -Type SRV _cisco-uds._tcp.example.com
Then:
Resolve-DnsName -Type SRV _cuplogin._tcp.example.com
From a system using the external DNS service:
Resolve-DnsName -Type SRV _collab-edge._tls.example.com
You want to see the expected target and port.
If the external lookup does not return Expressway-E, MRA service discovery cannot work.
If the SRV record returns an unexpected hostname, check the certificate as well. The SRV target, Expressway-E hostname and certificate identity need to agree with each other.
Check the firewall before blaming Expressway
An MRA deployment crosses several security boundaries.
At a high level:
Internet
|
v
Firewall / NAT
|
v
Expressway-E
|
| UC traversal
v
Expressway-C
|
v
Unified CM / IM&P / Unity
Do not simply allow everything between the DMZ and internal network.
Build the firewall policy around the ports required by the specific Expressway release and services being used. Cisco maintains a dedicated Expressway IP Port Usage Configuration Guide that describes the ports between Expressway-C, Expressway-E and the public internet. It’s published alongside the other guides on the configuration guides index.
It’s worth resisting the temptation to open a wide range “to be safe”. The port list looks long at first glance, but the set actually required from the internet to Expressway-E is considerably narrower than the full table suggests, and the deployment guide’s diagram makes the direction of each flow clear.
Also check whether the firewall is performing:
- SIP inspection
- TLS inspection
- SIP ALG
- aggressive NAT rewriting
- application-layer filtering
Those features can interfere with a deployment that otherwise looks correct.
Test MRA in a logical order
Do not start by opening Jabber on a laptop and repeatedly trying to log in.
Test from the bottom up.
1. DNS
Verify:
_collab-edge._tls.example.com
from an external network.
2. Expressway-E reachability
Confirm that the external client can reach the required Expressway-E service through the firewall and NAT.
3. Certificate
Check:
- Certificate validity
- SANs
- Certificate chain
- Trusted CA
- Hostname matching
- Expiration
- Certificate purpose and EKU where applicable
4. Traversal zone
Check the UC traversal zone on both Expressways.
If it is not Active, investigate this before troubleshooting Jabber.
5. Expressway-C to Unified CM
Verify that Expressway-C can communicate with Unified CM and that the Unified CM connection is healthy.
6. External client
Only after the infrastructure checks pass should you test the client.
This makes troubleshooting much faster because you are testing one dependency at a time.
Common MRA failures
The traversal zone is not Active
Start with:
- DNS between Expressway-C and Expressway-E
- Certificate trust
- Certificate SANs
- TLS verification
- Firewall rules
- NAT
- Correct peer FQDN
- Time synchronisation
If the traversal connection cannot establish, there is little point troubleshooting the Jabber client yet.
External DNS works but Jabber still cannot connect
Check the entire service-discovery chain.
The _collab-edge._tls record might be correct while the target hostname resolves incorrectly, the certificate does not contain the required name, or the firewall is not forwarding the required service.
DNS success by itself does not prove that Expressway-E is usable.
Traversal is Active but MRA login fails
This is an important distinction.
If traversal is Active, move further through the chain:
Client
|
DNS
|
Expressway-E
|
Traversal
|
Expressway-C
|
Unified CM
Check each stage rather than repeatedly changing the traversal configuration.
Internal login works but external login fails
This shifts the investigation towards:
- External DNS
- Expressway-E
- Firewall and NAT
- Certificate
- Service discovery
It is less likely to be a basic Unified CM authentication problem if the same user can successfully register internally.
Calls connect but media does not work
Separate signalling from media.
A successful login or call setup does not prove that the media path is correct.
Check the Expressway-E network design, NAT, firewall policy and media-related configuration for the deployment.
This is where packet captures and Expressway diagnostics become more useful than repeatedly changing DNS or certificates.
Expressway versions matter
An old Expressway guide can still be useful for understanding the architecture, but it should not be treated as current configuration documentation.
Before deploying or upgrading, check:
- Current Expressway release
- Supported VMware version
- Current MRA deployment guide
- Current certificate guide
- Current port usage guide
- Current release notes
- Compatibility with the Unified CM version
- Compatibility with the client being used
Cisco’s Expressway configuration guides index is the best starting point, because Cisco maintains the version-specific documentation in one place and the index shows the publication date of each guide.
A practical MRA deployment checklist
- Expressway-C deployed on the internal network
- Expressway-E deployed in the DMZ or perimeter network
- Separate IP addresses for Expressway-C and Expressway-E
- Supported VMware platform used
- Hostnames and domains configured
- Internal DNS working
- External DNS working
- NTP synchronised
- MRA enabled on both Expressways
- MRA domain configured
- Unified CM configured on Expressway-C
- IM and Presence configured if required
- Unity Connection configured if required
- Correct server certificates installed
- Required CA certificates trusted
- Certificate SANs checked
- SHA-1 certificates replaced where applicable
- UC traversal zone configured
- Traversal zone Active
- Firewall rules tested
- NAT tested
- External
_collab-edge._tlslookup tested - Internal
_cisco-uds._tcplookup tested - External client login tested
- Internal client login tested
- Calling tested
- Media tested
- Expressway alarms and logs reviewed
The useful part of an Expressway deployment
The VMware installation is relatively routine. The difficult part is getting all of the dependencies to agree with each other.
DNS tells the client where to go.
The certificate tells the client and Expressway whether they can trust what they reached.
The firewall and NAT determine whether the traffic can actually get there.
The traversal zone connects Expressway-E to Expressway-C.
Expressway-C connects that external session back into Unified CM.
When those pieces are treated as one system rather than five separate configuration tasks, MRA becomes much easier to troubleshoot.
For current deployments, use Cisco’s documentation for the exact version-specific menus, ports and supported virtual hardware rather than treating this article as a replacement for Cisco’s installation guide.
The value of this guide is in understanding what needs to be true, what to check, and where to look when it isn’t.
Cisco references
- Cisco Expressway Series configuration guides – the index for the MRA deployment guide, certificate guide, cluster guide and IP port usage guide
- Understand Mobile and Remote Access – traffic flows, certificate exchange and the trust requirements between Expressway-C and Unified CM
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.