The purpose of this article is to provide the best explanation about Firewall and NAT Traversals with Cisco Expressway Series.
Cisco Expressway Core and Edge are already configured for MRA Mobile Remote Access.
Cisco Expressway Core is integrated with Cisco UCM.
On the External-PC, open the Cisco Jabber application and login as rmeddane@lab.public.
Enter the username rmeddane and password Cisco123.
The Cisco Jabber is now registered to the HQ-CUCM, to confirm, navigate to Menu > Help > Connection Status and check the Softphone connection status.
We can see the message "CCMCIP-Expressway", which means that Cisco Jabber is registered to the HQ-CUCM.
To test call, ensure that the internal US Phone is registered with DN 11004.
On the HQ-CUCM, from the Phone page, verify that the Cisco Jabber is registered through the Cisco Expressway-C with IP address 10.1.5.20.
From the Cisco Jabber, call the US Phone 11004.
Verify that the US Phone rings and answer the call.
Now the external user is connected to the internal US Phone.
On both Cisco Expressway verify that the call is traversing both systems.
Firewall Traversal Concept
How the Firewall Traversal Concept works, and how it is possible to bypass the stateful function of ASA firewall to initiate inbound calls, in other words, connection initiated from lower security level to higher security with the integration of the Cisco Expressway series, using wireshark to show how the SIP invite are proxied through the Cisco Expressway Core and Edge, and very important the correspondance between the Firewall Traversal Connection established between the Cisco Expressway-C and Cisco Expressway-E, and the connection table of the ASA Firewall (we can display it using the show conn command).
How the magic happens in real scenario, how a call initiated from outside to inside appears for the ASA as a PSEUDO return traffic for a connection initiated from inside (which is the Firewall Traversal Connection that corresponds to the entry in the connection table's ASA).
By default, the firewall ASA allows connection initiated from higher security level to lower security level, the return traffic is allowed based on the connection table built from the first request. But the traffic initiated from a lower security level to higher security leve is blocked because it is initiated from an untrusted network or zone. This connection table can be displayed using the show conn command. The connection table is the basis of the Stateful Firewall.
In this scenario, if a call is initiated from the outside zone, in other words a lower security level 0 to DMZ with a higher security level 50, the call is blocked at the ASA-E ‘s perspective.
The Expressway series will allow the call through the Expressway-E located in the DMZ which is reachable through Internet using a static NAT configured on ASA-E.
Once the call arrives at the Expressway-E’s perspective, there is a problematic, as mentioned previously, when a call is initiated from a lower security level (in this case DMZ 50) to higher security level (in this case INSIDE 100), the call cannot be routed out to Inside zone.
The solution of this problematic for IP telephony is the firewall traversal feature or function between Expressway-C and Expressway-E, the firewall traversal connection is permanently established and maintained using keeplive between Expressway-C and Expressway-E.
Cisco Expressway-E acts as a firewall traversal server while the Cisco Expressway-C acts as a firewall traversal client.
Once a traversal zone is configured between Cisco Expressway-C and Cisco Expressway-E. The firewall traversal connection is established through TLS, the Expressway-C as a client located in the Inside zone initiates the firewall traversal connection to the Expressway-E located in the DMZ zone, since this connection is coming from a higher security level to a lower security level, the ASA-C upon receiving this connection build an entry in the connection table.
Below we can see that the status of the Firewall traversal connection is Active on Cisco Expressway-C 10.1.5.20, this connection is established with the Cisco Expressway-E 172.16.1.21 with TCP port 7001, this is the destination port of the Cisco Expressway-E.
Below the Cisco Expressway-E shown the status of the firewall traversal connection with the status Active with Cisco Expressway-C 10.1.5.20 and the destination port 25006.
To understand the concept of the firewall traversal concept, let’s verify the firewall ASA-C, in other words let’s display the connection table using the show conn command. As expected, an entry is added from Inside zone to DMZ zone, the source IP is 10.1.5.20 (Cisco Expressway-C) and the source port is 25006. The destination IP is 172.16.1.21 (Cisco Expressway-E) and the destination port is 7001, this means that if an inbound connection with source IP : port=172.16.1.21 : 7001 and destination : port = 10.1.5.20 : 25006 is received from DMZ to Inside (from lower security level to higher security level), the firewall, this connection is allowed. This is the idea behind the firewall traversal concept.
Let’s do in depth analysis using wireshark, the Cisco Jabber is already registered using the MRA feature into CUCM through the Cisco Expressway series.
The Cisco Jabber client initiates a call to the US Phone located in the corporate network, it sends a SIP invite, the SIP invite reaches the Cisco Expressway-E which is reachable with a public IP address.
The Cisco Expressway-E receives the SIP invite and generate a new SIP invite with the source IP : port=172.16.1.21 : 7001 and destination : port = 10.1.5.20 : 25006, it sends the SIP invite to ASA-C, the ASA-C checks its connection table if there is an entry that matches this connection, and of course the magic happens, this connection is already there, for the ASA-C’s perspective, this is a legitimate return traffic for a pseudo connection initiated from inside, even if the SIP invite is initiated from the Cisco Jabber, in other words from the outside, the Cisco Expressway-E modifies the L3/L4 headers to match the firewall traversal connection, in other words the entry of the connection table of the ASA.
The Cisco Expressway-C receives the SIP invite from Cisco Expressway-E and generates another SIP invite with the source IP : port=10.1.5.20 : 25002 and destination : port = 10.1.5.15 : 5060.
For CUCM’s perspective the SIP invite is originated from the Cisco Expressway-C, in other words Expressway-C is the calling, because simply, when Cisco Jabber registered into the CUCM using the Mobility and Remote Access MRA feature, the IP address of the CSF phone is 10.1.5.20, the IP address of Cisco Expressway-C as shown in the phone page of CUCM.
To confirm, expand the Session Initiation Protocol, in the Message Body, the Connection Information (C) send to establish an RTP media connection is 10.1.5.20 the Cisco Expressway-C.
The CUCM 10.1.5.15 sends a SIP Invite to the US Phone 10.1.5.101 and the US Phone sends a 180 Ringing message as shown below.
NAT Traversal Concept
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 10.1.6.113 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.
Now the Cisco Jabber can establish an RTP conection with the US Phone with the public IP address which is routable in Internet.
This is what we call NAT Traversal.