This document describes how to troubleshoot phone services failure over MRA caused by source IP translation over NAT reflection, with Expressway-E single-NIC with Static NAT configuration.
Cisco recommends that you have knowledge of these topics:
NAT (Network Address Translation)
SIP (Session Initiation Protocol)
Cisco Video Communication Server (VCS) or Expressway basic configuration
Mobile and Remote Access (MRA) over Expressway or VCS
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Note: Through the entire document, Expressway devices are referred as Expressway-E and Expressway-C. However, the same configuration applies to Video Communication Server (VCS) Expressway and VCS Control devices.
This document covers a schenario in which Mobile and Remote Access has been deployed on Expressway with Expressway-E using a single NIC and Static NAT address (described as 3-port Firewall DMZ Using Single Expressway-E LAN Interface, as described in the Expressway Basic Configuration Guide). MRA users are able to log in successfully, but do not have access to phone services.
The SIP REGISTER message from external client is received by Expressway-E successfully on port 5061. Expressway-E then creates a SIP SERVICE message towards Expressway-C. This request results in a 408 Request Timeout.
Phone services fail because the SIP REGISTER message does not go through to the Cisco Unified Communications Manager (CUCM or Call Manager). Expressway-E and Expressway-C are not able to exchange their certificates properly using the SIP SERVICE message exchange. The SIP SERVICE messages only get a 408 Request Timeout as response from the Expressway-C. As the SIP SERVICE message is not successful, the Expressway-E does not forward the SIP REGISTER message to the Expressway-C. This is caused by the fact that the firewall between Expressway-C and Expressway-E does source IP (and port) translation for messages from the Expressway-C to the Expressway-E. This results in the Expressway-C routing those SIP SERVICE messages incorrectly towards that translated address, instead of its own local address. In a successful scenario, the Expressway-C processes the SIP SERVICE message itself. (The SIP SERVICE message between Expressway-E and Expressway-C is used to check certificates and therefore only seen at the beginning of a traversal zone setup, or upon first registration over MRA.)
The following image provides an example of a network diagram, which is used as a reference throughout this document:
From the Expressway-C packet captures, you can see that the Expressway-C (10.0.30.2) connects successfully to the Expressway-E static NAT public IP address (184.108.40.206) on port 7003. (Notice that the source port is 27901 on the Expressway-C):
In packet captures of the Expressway-E you can see that the connection comes from 220.127.116.11 on port 4401 (which is its own static NAT public IP address) with destination 10.0.10.2 and port 7003:
These are the perspectives of the connection between Expressway-C and E:
This indicates that the firewall between Expressway-C and Expressway-E is doing source IP and port translation on those messages. If you have a look at the flow of SIP communication on Expressway-E, you can see it gets the SIP REGISTER from the MRA client device, then Expressway-E generates a SIP SERVICE message to exchange its certificates with the Expressway-C, but this results in a 408 Request Timeout.
Evidence in Diagnostic Logs
Notice that the Route header of this SIP SERVICE message (sent from Expressway-E to Expressway-C) contains the IP and port of the NAT address (18.104.22.168:4401). When this message arrives at the Expressway-C, Expressway-C tries to route the message based on that Route header, towards 22.214.171.124:4401. This fails as it is not able to make a connection to this address, as this address is on the Expressway-E server side. Even if Expressway-C is able to connect to this address, it is not correct as the SIP SERVICE message is intended for Expressway-C to receive and process.
There are two possible solutions to this condition.
Disable the source IP port translation on the firewall
If you disable the source IP/port translation on the firewall, Expressway-E server views Expressway-C traffic as arriving from 10.0.30.2:27901 (actual IP and port on the Expressway-C) instead of 126.96.36.199:4401 (NAT address). In this way, the Route header on the SIP SERVICE message contains 10.0.30.2:27901 value and on receipt of this message, the Expressway-C will route it to itself and do some processing on it resulting in a 200 OK to be sent back to the Expressway-E (if all goes fine) which will then proxy through the SIP REGISTER message to continue the registration process.
Move to a dual NIC configuration
With a dual NIC configuration on Expressway-E, NAT reflection need not be performed and the issue is avoided. However, ensure that the internal firewall between Expressway-E and Expressway-C (if present) is not doing source IP/port translation from traffic from Expressway-C to Expressway-E (which would result in similar issues).