Introduction
This document describes the configurational steps for ASA Firewall in an Expressway deployment with enabled dual NIC for WebRTC flow.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
- Knowledge of Cisco ASA (Cisco Adaptive Security Appliance) firewalls
- Administrative knowledge of Expressway servers
- Administrative knowledge of CMS (Cisco Meeting Server)
- Understanding of the Cisco CMS WebRTC application
- Network Address Translation (NAT)
- Traversal Using Relays around NAT (TURN)
Components Used
This document is not restricted to specific software and hardware versions, however the minimum software version requirements must be met.
- Expressway server
- CMS Server
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.
Background Information
WebRTC proxy support has been added to Expressway from version X8.9.2, which enables off-premises users to browse to a Cisco Meeting Server Web Bridge.
External clients and Guests can manage or join CMS coSpaces without the need of any software other than a supported web browser. List of supported browsers can be found here.
The Expressway-E server can be configured with either single, or dual network interfaces (therefore having a pair of internally and externally-facing NICs). In the earlier Expressway versions, having a dual NIC with static NAT was not a mandatory requirement. When the WebRTC feature over Expressway was raised, it started to require a static NAT to be configured, even in the scenario of enabled dual NIC on the Expressway-E server. Expressway software version X12.5.3 is planned to contain a rework of the code's logic, which removes this requirement in almost all configurational scenarios. Refer to enhancement request CSCve37570 for more information.
Note: When Expressway-E in dual NIC configuration with static NAT is used as TURN server for the WebRTC traffic, and the only working media path is the relay candidate on both CMS and the WebRTC Client, the TURN server is sending RTP packets physically out to his own static NAT IP address. That is why NAT reflection must be configured on the external Firewall.
Caution: Deployment of Expressway-E cluster with multiple TURN servers activated behind the same NAT continues to require NAT reflection to be configured.
Tech note
If you would like to learn more about the ICE, TURN and STUN processes, please watch the Cisco Life presentation ICE / TURN / STUN Tutorial - BRKCOL-2986
This session provides technical background and insights on Traversal Using Relay NAT (TURN) and Interactive Connectivity Establishment (ICE). It explains how these are used in the Collaboration Portfolio with some extra attention on the use case in Mobile and Remote Access (MRA). Participants in this session learned why TURN is needed and how ICE finds the optimal media path. Troubleshooting guidance was discussed, and the serviceability tools available together with best practices were demonstrated.
Configure
This chapter outlines the required steps to configure NAT reflection on the ASA firewall in the scenario of Expressway-E server with enabled dual NIC. Return traffic coming back from the firewall to the Expressway (after reflection) has as source address the public IP address of the server, where the request came from (to match the TURN permissions).
Note: Firewalls typically mistrust packets that have the same source and destination IP address. You must configure your external firewall to allow NAT reflection for the Expressway-E's public IP address.
Network Diagram
This image provides an example of a general WebRTC flow, in Expressway scenario with enabled dual NIC:
This image provides an example of connections flow and the required ports for it Web Proxy for CMS WebRTC:
This reference is taken from the Cisco Expressway IP Port Usage Guide for Expressway version X12.5.
Configurational steps for the Cisco ASA Firewall
These steps provide the required configurational steps on Cisco ASA Firewall, for version 8.3 and higher.
Step 1. Create two objects - the first one is for the Expressway-E's private IP address, and the second one is for the Expressway-E's public IP address. Run the commands:
ASA(config)#object network expressway-private
ASA(config-network-object)# host x.x.x.x
ASA(config)#object network expressway-public
ASA(config-network-object)# host y.y.y.y
Step 2. Identify the name of the interface which the Expressway-E is connected to - for example, DMZ-expressway.
Step 3. Configure a manual static NAT whose purpose is to translate the Expressway traffic from its private IP address to its public IP address and then to send it back to the Expressway-E again (after it is translated). Run the command and replace the actual values of your deployment:
ASA(config)# nat (DMZ-expressway, DMZ-expressway)source static expressway-private expressway-public destination static expressway-public expressway private
Step 4. Permit the traffic to return by adding an access-list (or by adding a line to an already configured access-list) on the interface, which is connected to the Expressway-E:
access-list access-list-name-on-DMZ-expressway line 1 permit IP any expressway-private
Verify
After the configuration is completed, it can be tested directly with a call attempt, or test using the packet-tracer command.
Example usage of the packet-tracer command:
packet-tracer input interface-name tcp expressway-private-ip 1234 expressway-public-ip destination-port
Replace the highlighted parameters with appropriate information from your deployment. If the configurtion is successfull, the packet-tracer command returns this output:
input-interface: DMZ-expressway
input-status: up
input-line-status: up
output-interface: DMZ-expressway
output-status: up
output-line-status: up
Action: allow
Troubleshoot
There is currently no specifictroubleshootinginformation available for this configuration.
Related Information