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 10.1.5.101.

The Remote Cisco Jabber client is configured with an IP address 10.1.6.113.

The HQ-CUCM has an IP address 10.1.5.15.

The Cisco Expressway-C with IP address 10.1.5.20.

The Cisco Expressway-E with IP address 172.16.1.21.

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

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 10.1.5.101 and Destination IP 10.1.5.15 as the L3 packet header, the SIP payload contains reference to the US Phone 10.1.5.101, Connection Information (c): IN IP4 10.1.5.101. The IP address 10.1.5.101 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 10.1.5.20 and Destination IP 172.16.1.21 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 172.16.1.21 and Destination IP 10.1.6.113 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 172.16.1.21, Connection Information (c): IN IP4 172.16.1.21. This IP address inside SDP will be used by Cisco Jabber 10.1.6.113 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 172.16.1.21 to the Public IP address of Cisco Expressway-E 41.1.1.21.

The Cisco Jabber will see that the SIP Invite is received from IP address 41.1.1.21, 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 172.16.1.21, which means that the Cisco Jabber will try to send RTP media to the IP address 172.16.1.21 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 10.1.6.113 which is itself and initiated an Media RTP connection to the Destination IP is 172.16.1.21 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 172.16.1.21 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 172.16.1.21 ‘s Cisco Expressway-E with its routable public IP address 41.1.1.21.

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 41.1.1.21 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 172.16.1.21 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 41.1.1.21.

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 41.1.1.21, instead of 172.16.1.21.

This is what we call NAT Traversal.