Expressway TLS, DNS, and Firewall Failures Across MRA, B2B, and Calendar
A university has 18,000 users and runs Expressway-C in an internal DMZ and Expressway-E in an external DMZ with dual NIC and static NAT. MRA serves Jabber and Webex App; B2B calls go to a partner university; Hybrid Calendar uses the same Expressway pair. Expressway-E has a public CA certificate with CN exp.univ.edu and SANs exp.univ.edu and mra.univ.edu. Internal DNS SRV _cisco-uds._tcp.univ.edu points to the CUCM publisher; external DNS has no SRV record. Firewall inbound allows TCP 443, 5060, 5061, and 8443; no UDP. Symptoms: external Jabber users authenticate but calls fail; B2B calls return 503; Calendar Connector logs “cannot connect to Webex”; Expressway-E logs TLS handshake failures from the Webex cloud.
1. Identify the most likely certificate, DNS, and firewall issues and prioritize them.
Read the worked answer
Prioritize certificate trust first because it affects all three services. The Expressway-E certificate covers exp.univ.edu and mra.univ.edu, but Hybrid Services and cloud connectivity may require the collaboration domain or the Webex-facing name in the SAN. A TLS handshake failure from the Webex cloud is consistent with a name mismatch or an incomplete chain. Verify the full chain, the SAN list, and that Expressway-C trusts the issuing CA. Next, external DNS: internal SRV pointing to CUCM is correct for on-premises discovery, but external Jabber needs an external _cisco-uds._tcp SRV record pointing to Expressway-E. Without it, external discovery is broken even if authentication appears to work through a manual server setting.
Firewall is the third priority but explains the media and B2B symptoms. TCP 5061 and 8443 allow signaling and registration, but no UDP means TURN and media cannot traverse. B2B 503 responses can also result from SIP/TLS trust or routing, but media failure is expected with the current rules. Fix certificates and external SRV first, then open UDP 3478 and the Expressway media range, then retest each service separately.
2. Explain the traffic flow and required ports for MRA, B2B, and Hybrid Calendar through the Expressway pair.
Read the worked answer
For MRA, Jabber or Webex App discovers Expressway-E externally, connects inbound on TCP 443/8443 for registration and call signaling, and Expressway-C forwards to CUCM. SIP traversal uses TCP 5061, and media uses TURN on UDP 3478 plus the Expressway media port range. For B2B, the partner connects to Expressway-E on SIP TCP 5060 or 5061; Expressway-C routes inward to CUCM. If the B2B partner uses TLS, certificate trust and SIP domain routing must match on both sides. For Hybrid Calendar, the Calendar Connector registers to Expressway-C and reaches Webex through the Expressway tunnel, with outbound TCP 443 to Webex and return traffic through Expressway-E.
The key judgement is that allowing only 443, 5060, 5061, and 8443 supports registration and signaling but not media. MRA calls may connect and then fail, B2B may return errors when media negotiation fails, and Calendar can fail independently because of certificate trust. Test each flow with the firewall counters and Expressway logs rather than assuming one fix covers all three.
3. What remediation sequence would you follow to restore all three services without breaking internal MRA?
Read the worked answer
Back up the Expressway configuration and certificate/private key first. Reissue the Expressway-E certificate with the correct SANs for the Expressway-E FQDN, MRA name, and collaboration domain, install the full chain, and restart the Expressway services in a maintenance window. Confirm Expressway-C trusts the CA and that the cluster is healthy. Then add the external _cisco-uds._tcp SRV record pointing to Expressway-E and verify resolution from an external network. Open UDP 3478 and the Expressway media range in the firewall, preserving the existing TCP rules.
Validate in order: internal MRA first, then external MRA registration and a test call with audio both ways; then B2B signaling and media with the partner; then Hybrid Calendar connector registration. If Calendar still fails after certificate and firewall fixes, check the connector's Webex registration and proxy settings separately. Do not change CUCM or DNS internally during the same window, so a regression can be isolated to the edge changes.