NAT Traversal Demystified With Cisco Expressway using Wireshark

We already know that Cisco Expressway series provides two important features: Firewall Traversal and NAT Traversal. NAT concept is commonly used to translate Private IP address to Public IP address for internet access and works at layer 3 header. In VOIP environment, SIP signaling protocol cannot deal with NAT and cannot coexist with NAT. The reason is that the SIP signaling protocol carries IP addresses inside the message body SDP (Session Description Protocol) of the SIP INVITE Packets. In other words, at Layer 7. The IP addresses inside the SIP INVITE packets are used by the endpoint to establish a point to point media RTP connection, if the CUCM include the Private IP address of the endpoint initiating the call, this IP remains unchanged and calls through internet cannot be established. Cisco Expressway NAT Traversal provides atypical solution to overcome the NAT issues in a voip environment by doing a static NAT but at Layer 7, or inside the message body. . To understand the NAT issue that causes the call to break down and how Cisco Expressway solves this problem by providing NAT Traversal. The best way is to use wireshark.

To understand the NAT issue that causes the call to break down, let’s take a scenario with Cisco Expressway and let’s analyze the SIP messages.

The US Phone is configured with an IP address

The Remote Cisco Jabber client is configured with an IP address

The HQ-CUCM has an IP address

The Cisco Expressway-C with IP address

The Cisco Expressway-E with IP address

ASA-E is configured with static NAT for the Cisco Expressway-E with a a publicly routable IP address

Assume that US Phone places a SIP call towards Cisco Jabber. A SIP Invite is sent by the US Phone to CUCM with the Source IP and Destination IP as the L3 packet header, the SIP payload contains reference to the US Phone, Connection Information (c): IN IP4 The IP address embedded in the SDP Session Description Protocol. The IP address inside the SDP is used in SIP to negociate the IP addresses and Port numbers the endpoints will use to build the RTP flow.

The SIP Invite arrives at the Cisco Expressway-C, It sends the SIP Invite to the Cisco Expressway-E with Source IP and Destination IP as the L3 packet header. This SIP Invite is sent through the Traversal Zone between the Cisco Expressway-C and Cisco Expressway-E as confirmed by the L4 Source port 2500 and the L4 Destination port 7001, port number 7001 is the SIP listening port on the Cisco Expressway-E traversal server zone. The Cisco Expressway-C uses the port number in the range 25000-29999 to initiate a firewall traversal connection.

The Cisco Expressway-E sends a SIP Invite through TLS with Source IP and Destination IP as the L3 packet header. The Cisco Expressway-E uses the SIP signaling (TLS) 5061 for Mobile and Remote Access MRA connection. The SIP payload contains reference to the Cisco Expressway-E, Connection Information (c): IN IP4 This IP address inside SDP will be used by Cisco Jabber to build RTP connection.

Note : since the SIP signaling uses TLS we cannot see the Message Body SDP.

Upon receiving the SIP Invite encrypted with TLS (source port 5061) from Cisco Expressway-E, the ASA-E rewrites or translate the source IP in the L3 header to the Public IP address of Cisco Expressway-E

The Cisco Jabber will see that the SIP Invite is received from IP address, therefore it knows where to send the reply for the SIP Invite packet.

But the key point at this step is the Connection Information (c): IN IP4, which means that the Cisco Jabber will try to send RTP media to the IP address as the L3 destination IP which is not routable on the real internet.

The RTP stream displayed below in the remote Cisco Jabber, shown the Source IP is which is itself and initiated an Media RTP connection to the Destination IP is which is the Cisco Expressway-E.

The SIP media port used by the Cisco Expressway-E is 36002 in the range 36000-59999 and UDP as the layer 4 protocol.

In the real environment, The result is that the US Phone will never receive media sent by Cisco Jabber because the IP address is not routable.

This is the issue that NAT causes for VOIP call so a bidirectional RTP between the two endpoints will never be established.

The solution is to tell to the Cisco Expressway-E to modify the IP address in the Connection Information (c) inside the SIP paylod or the SDP message body, in other words replace the private IP address ‘s Cisco Expressway-E with its routable public IP address

This can be achieved by enabling the Static NAT Mode feature in the LAN interface of the Cisco Expressway-E by configuring the public IP address so that the Cisco Expressway-E will apply static NAT for all outbound SIP for this interface. In other words the Cisco Expressway-E will translate the IP address embedded in the SIP payload, like a NAT at the application Layer.

On Cisco Expressway-E, navigate to System > Network interfaces > IP, select ON for IPv4 Static NAT Mode, and configure the IP address

Click Save. Restart the Cisco Expressway-E.

Let’s verify the traffic capture on the remote Cisco Jabber, now the RTP stream has the destination IP, instead of

This is what we call NAT Traversal.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s