Configure NAT Reflection On The ASA For The VCS Expressway TelePresence Devices

Introduction

This document describes how to implement a Network Address Translation (NAT) reflection configuration on the Cisco Adaptive Security Appliances for special Cisco TelePresence scenarios which require this kind of NAT configuration on the Firewall. 

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Cisco ASA (Adaptive Security Appliance) basic NAT configuration.

• Cisco TelePresence Video Communication Server (VCS) Control and VCS Expressway basic configuration.

Note: This document is intended to be used only when the recommended deployment method of a VCS-Expressway or Expressway-Edge with both NIC interfaces in different DMZ's cannot be used. For further information on the recommended deployment using dual NICs please check the following link at page 60: Cisco TelePresence Video Communication Server Basic Configuration (Control with Expressway) Deployment Guide

Components Used

The information in this document is based on these software and hardware versions:

• Cisco ASA 5500 and 5500-X Series appliances that run software Version 8.3 and later.

• Cisco VCS version X8.x and later.

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, make sure that you understand the potential impact of any command.

Note: Through the entire document, VCS devices are referred to as VCS Expressway and VCS Control. However, the same configuration applies to Expressway-E and Expressway-C devices. 

Background Information

As per the Cisco TelePresence documentation, there are two kinds of TelePresence scenarios where the NAT reflection configuration is required on the FWs in order to allow the VCS Control to communicate with the VCS Expressway via the VCS Expressway public IP address.

The first scenario involves a single subnet De-Militarized Zone (DMZ) that uses a single VCS Expressway LAN interface, and the second scenario involves a 3-port FW DMZ that uses a single VCS Expressway LAN interface.

Tip: In order to obtain more details about the TelePresence implementation, refer to the Cisco TelePresence Video Communication Server Basic Configuration (Control with Expressway) deployment guide.

Cisco Topologies Non-Recommended for the VCS C and E Implementation

It is important to note that the following topologies are NOT recommended by Cisco. The recommended deployment methodology for a VCS Expressway or Expressway edge is to use two different DMZ's with the Expressway having a NIC in each of the DMZ's. This guide is meant to be used in environments where the recommended deployment method cannot be used.

Single Subnet DMZ with Single VCS Expressway LAN Interface

In this scenario, FW A can route traffic to FW B (and vice versa). The VCS Expressway allows video traffic to be passed through FW B without a reduction in traffic flow on FW B from the outside to the inside interfaces. The VCS Expressway also handles FW traversal on its public side.

Here is an example of this scenario:

This deployment uses these components:

• A single subnet DMZ (10.0.10.0/24) that contains:
  
  • The internal interface of FW A (10.0.10.1)
  • The external interface of FW B (10.0.10.2)
  • The LAN1 interface of the VCS Expressway (10.0.10.3)
• A LAN subnet (10.0.30.0/24) that contains:
  
  • The internal interface of FW B (10.0.30.1)
  • The LAN1 interface of the VCS Control (10.0.30.2)
  • The network interface of the Cisco TelePresence Management Server (TMS) (10.0.30.3)

A static one-to-one NAT has been configured on FW A, which performs the NAT for the public address 64.100.0.10 to the LAN1 IP address of the VCS Expressway. The static NAT mode has been enabled for the LAN1 interface on the VCS Expressway, with a static NAT IP address of 64.100.0.10.

Note: You must enter the Fully Qualified Domain Name (FQDN) of the VCS Expressway on the VCS Control secure traversal client zone (peer address) as how it is seen from outside the network. The reason for this is that in static NAT mode, the VCS Expressway requests that inbound signaling and media traffic be sent to its external FQDN rather than its private name. This also means that the external FW must allow the traffic from the VCS Control to the VCS Expressway external FQDN. This is known as NAT reflection, and might not be supported by all types of FWs.

In this example, FW B must allow the NAT reflection of traffic that comes from the VCS Control that is destined for the external IP address (64.100.0.10) of the VCS Expressway. The traversal zone on the VCS Control must have 64.100.0.10 as the peer address (after FQDN to IP conversion).

The VCS Expressway should be configured with a default gateway of 10.0.10.1. Whether the static routes are required in this scenario depends on the capabilities and settings of FW A and FW B. The communication from the VCS Control to the VCS Expressway occurs via the 64.100.0.10 IP address of the VCS Expressway; and the return traffic from the VCS Expressway to the VCS Control might have to pass via the default gateway.

The VCS Expressway can be added to the Cisco TMS with the IP address 10.0.10.3 (or with IP address 64.100.0.10, if FW B allows this), since the Cisco TMS management communication is not affected by the static NAT mode settings on the VCS Expressway.

3-Port FW DMZ with Single VCS Expressway LAN Interface

Here is an example of this scenario:

In this deployment, a 3-port FW is used in order to create:

• A DMZ subnet (10.0.10.0/24) that contains:
  
  • The DMZ interface of FW A (10.0.10.1)
  • The LAN1 interface of the VCS Expressway (10.0.10.2)
• A LAN subnet (10.0.30.0/24) that contains:
  
  • The LAN interface of FW A (10.0.30.1)
  • The LAN1 interface of the VCS Control (10.0.30.2)
  • The network interface of the Cisco TMS (10.0.30.3)

A static one-to-one NAT has been configured on FW A, which performs the NAT of the public IP address 64.100.0.10 to the LAN1 IP address of the VCS Expressway. The static NAT mode has been enabled for the LAN1 interface on the VCS Expressway, with a static NAT IP address of 64.100.0.10.

The VCS Expressway should be configured with a default gateway of 10.0.10.1. Since this gateway must be used for all of the traffic that leaves the VCS Expressway, no static routes are required in this type of deployment.

The traversal client zone on the VCS Control must be configured with a peer address that matches the static NAT address of the VCS Expressway (64.100.0.10 in this example) for the same reasons as those described in the previous scenario.

Note: This means that FW A must allow traffic from the VCS Control with a destination IP address of 64.100.0.10. This is also known as NAT reflection, and it should be noted that this is not supported by all types of FWs.

The VCS Expressway can be added to the Cisco TMS with the IP address of 10.0.10.2 (or with IP address 64.100.0.10, if FW A allows this), since the Cisco TMS management communication is not affected by the static NAT mode settings on the VCS Expressway.

Configure

This section describes how to configure the NAT reflection in the ASA for the two different VCS C and E implementation scenarios.

Single Subnet DMZ with Single VCS Expressway LAN Interface

For the first scenario, you must apply this NAT reflection configuration on FW A in order to allow the communication from the VCS Control (10.0.30.2) that is destined to the external IP address (64.100.0.10) of the VCS Expressway:

In this example, the VCS Control IP address is 10.0.30.2/24, and the VCS Expressway IP address is 10.0.10.3/24.

If you suppose that the VCS Control IP address 10.0.30.2 remains when it moves from the inside to the outside interface of FW B when looking for the VCS Expressway with the destination IP address 64.100.0.10, then the NAT reflection configuration that you should implement on FW B is shown in these examples.

Example for ASA Versions 8.3 and later:

object network obj-10.0.30.2
 host 10.0.30.2

object network obj-10.0.10.3
 host 10.0.10.3

object network obj-64.100.0.10
 host 64.100.0.10

nat (inside,outside) source static obj-10.0.30.2 obj-10.0.30.2 destination static
 obj-64.100.0.10 obj-10.0.10.3

NOTE: After this NAT is applied in the ASA you will receive a warning message as the following:

WARNING: All traffic destined to the IP address of the outside interface is being redirected.
WARNING: Users may not be able to access any service enabled on the outside interface.

Example for ASA Versions 8.2 and earlier:

access-list IN-OUT-INTERFACE extended permit ip host 10.0.30.2 host 64.100.0.10
static (inside,outside) 10.0.30.2 access-list IN-OUT-INTERFACE

access-list OUT-IN-INTERFACE extended permit ip host 10.0.10.3 host 10.0.30.2
static (outside,inside) 64.100.0.10 access-list OUT-IN-INTERFACE

Note: The main objective of this NAT reflection configuration is to allow the VCS Control to be able to reach the VCS expressway, but using the VCS expressway public IP address instead of its private IP address. If the source IP address of the VCS Control is changed during this NAT translation with a twice NAT configuration instead of the suggested NAT configuration just shown, resulting in VCS Expressway seeing traffic from its own public IP address, then the phone services for the MRA devices will not come up. This is not a supported deployment as per section 3 on the recommendations section below.

3-Port FW DMZ with Single VCS Expressway LAN Interface

For the second scenario, you must apply this NAT reflection configuration on FW A in order to allow the NAT reflection of inbound traffic from the VCS Control 10.0.30.2 that is destined to the external IP address (64.100.0.10) of the VCS Expressway:

In this example, the VCS Control IP address is 10.0.30.2/24, and the VCS Expressway IP address is 10.0.10.2/24.

If you suppose that the VCS Control IP address 10.0.30.2 remains when it moves from the inside to the DMZ interface of FW A when looking for the VCS Expressway with the destination IP address 64.100.0.10, then the NAT reflection configuration that you should implement on FW A is shown in these examples.

Example for ASA Versions 8.3 and later:

object network obj-10.0.30.2
 host 10.0.30.2

object network obj-10.0.10.2
 host 10.0.10.2

object network obj-64.100.0.10
 host 64.100.0.10

nat (inside,DMZ) source static obj-10.0.30.2 obj-10.0.30.2 destination static
 obj-64.100.0.10 obj-10.0.10.2

NOTE: After this NAT is applied you will receive a warning message as the following:

WARNING: All traffic destined to the IP address of the DMZ interface is being redirected.
WARNING: Users may not be able to access any service enabled on the DMZ interface.

Example for ASA Versions 8.2 and earlier:

access-list IN-DMZ-INTERFACE extended permit ip host 10.0.30.2 host 64.100.0.10
static (inside,DMZ) 10.0.30.2 access-list IN-DMZ-INTERFACE

access-list DMZ-IN-INTERFACE extended permit ip host 10.0.10.2 host 10.0.30.2
static (DMZ,inside) 64.100.0.10 access-list DMZ-IN-INTERFACE

Note: The main objective of this NAT reflection configuration is to allow the VCS Control to be able to reach the VCS expressway, but with the VCS expressway public IP address instead of its private IP address. If the source IP address of the VCS Control is changed during this NAT translation with a twice NAT configuration instead of the suggested NAT configuration just shown, resulting in VCS Expressway seeing traffic from its own public IP address, then the phone services for the MRA devices will not come up. This is not a supported deployment as per section 3 in the recommendations section below.

Verify 

This section provides the packet tracer outputs that you can see in the ASA in order to confirm the NAT reflection configuration works as needed in both of the VCS C and E implementation scenarios.

Single Subnet DMZ with Single VCS Expressway LAN Interface

Here is the FW B packet tracer output for ASA Versions 8.3 and later:

FW-B# packet-tracer input inside tcp 10.0.30.2 1234 64.100.0.10 80 

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static obj-10.0.30.2 obj-10.0.30.2 destination
 static obj-64.100.0.10 obj-10.0.10.3
Additional Information:
NAT divert to egress interface outside
Untranslate 64.100.0.10/80 to 10.0.10.3/80

Phase: 2
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (inside,outside) source static obj-10.0.30.2 obj-10.0.30.2 destination
 static obj-64.100.0.10 obj-10.0.10.3
Additional Information:
Static translate 10.0.30.2/1234 to 10.0.30.2/1234

Phase: 4
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static obj-10.0.30.2 obj-10.0.30.2 destination
 static obj-64.100.0.10 obj-10.0.10.3
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 2, packet dispatched to next module
 
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Here is the FW B packet tracer output for ASA Versions 8.2 and earlier: 

FW-B# packet-tracer input inside tcp 10.0.30.2 1234 64.100.0.10 80 

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (outside,inside) 64.100.0.10 access-list OUT-IN-INTERFACE 
 match ip outside host 10.0.10.3 inside host 10.0.30.2
 static translation to 64.100.0.10
 translate_hits = 0, untranslate_hits = 2
Additional Information:
NAT divert to egress interface outside
Untranslate 64.100.0.10/0 to 10.0.10.3/0 using netmask 255.255.255.255

Phase: 2
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config: 
static (inside,outside) 10.0.30.2 access-list IN-OUT-INTERFACE 
 match ip inside host 10.0.30.2 outside host 64.100.0.10
 static translation to 10.0.30.2
 translate_hits = 1, untranslate_hits = 0
Additional Information:
Static translate 10.0.30.2/0 to 10.0.30.2/0 using netmask 255.255.255.255

Phase: 4
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) 10.0.30.2 access-list IN-OUT-INTERFACE 
 match ip inside host 10.0.30.2 outside host 64.100.0.10
 static translation to 10.0.30.2
 translate_hits = 1, untranslate_hits = 0
Additional Information:

Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (outside,inside) 64.100.0.10 access-list OUT-IN-INTERFACE 
 match ip outside host 10.0.10.3 inside host 10.0.30.2
 static translation to 64.100.0.10
 translate_hits = 0, untranslate_hits = 2
Additional Information:

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (outside,inside) 64.100.0.10 access-list OUT-IN-INTERFACE 
 match ip outside host 10.0.10.3 inside host 10.0.30.2
 static translation to 64.100.0.10
 translate_hits = 0, untranslate_hits = 2
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 8 
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 1166, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

3-Port FW DMZ with Single VCS Expressway LAN Interface

Here is the FW A packet tracer output for ASA Versions 8.3 and later:

FW-A# packet-tracer input inside tcp 10.0.30.2 1234 64.100.0.10 80

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,DMZ) source static obj-10.0.30.2 obj-10.0.30.2 destination
 static obj-64.100.0.10 obj-10.0.10.2
Additional Information:
NAT divert to egress interface DMZ
Untranslate 64.100.0.10/80 to 10.0.10.2/80

Phase: 2
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (inside,DMZ) source static obj-10.0.30.2 obj-10.0.30.2 destination
 static obj-64.100.0.10 obj-10.0.10.2
Additional Information:
Static translate 10.0.30.2/1234 to 10.0.30.2/1234

Phase: 4
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,DMZ) source static obj-10.0.30.2 obj-10.0.30.2 destination
 static obj-64.100.0.10 obj-10.0.10.2
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 7, packet dispatched to next module
 
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow

Here is the FW A packet tracer output for ASA Versions 8.2 and earlier: 

FW-A# packet-tracer input inside tcp 10.0.30.2 1234 64.100.0.10 80

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (DMZ,inside) 64.100.0.10 access-list OUT-IN-INTERFACE 
 match ip DMZ host 10.0.10.2 inside host 10.0.30.2
 static translation to 64.100.0.10
 translate_hits = 0, untranslate_hits = 2
Additional Information:
NAT divert to egress interface DMZ
Untranslate 64.100.0.10/0 to 10.0.10.2/0 using netmask 255.255.255.255

Phase: 2
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config: 
static (inside,DMZ) 10.0.30.2 access-list IN-OUT-INTERFACE 
 match ip inside host 10.0.30.2 DMZ host 64.100.0.10
 static translation to 10.0.30.2
 translate_hits = 1, untranslate_hits = 0
Additional Information:
Static translate 10.0.30.2/0 to 10.0.30.2/0 using netmask 255.255.255.255

Phase: 4
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,DMZ) 10.0.30.2 access-list IN-OUT-INTERFACE 
 match ip inside host 10.0.30.2 DMZ host 64.100.0.10
 static translation to 10.0.30.2
 translate_hits = 1, untranslate_hits = 0
Additional Information:

Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (DMZ,inside) 64.100.0.10 access-list OUT-IN-INTERFACE 
 match ip DMZ host 10.0.10.2 inside host 10.0.30.2
 static translation to 64.100.0.10
 translate_hits = 0, untranslate_hits = 2
Additional Information:

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (DMZ,inside) 64.100.0.10 access-list OUT-IN-INTERFACE 
 match ip DMZ host 10.0.10.2 inside host 10.0.30.2
 static translation to 64.100.0.10
 translate_hits = 0, untranslate_hits = 2
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 8 
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 1166, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow

Troubleshoot

You can configure packet captures on the ASA interfaces in order to confirm the NAT translation when the packets enter and leave the FW interfaces that are involved.

Packet Capture Applied for the "3-Port FW DMZ with Single VCS Expressway LAN Interface" Scenario

FW-A# sh cap
capture capin type raw-data interface inside [Capturing - 5735 bytes] 
  match ip host 10.0.30.2 host 64.100.0.10 
capture capdmz type raw-data interface DMZ [Capturing - 5735 bytes] 
  match ip host 10.0.10.2 host 10.0.30.2 
FW-A# sh cap capin

71 packets captured
   1: 22:21:37.095270 10.0.30.2 > 64.100.0.10: icmp: echo request 
   2: 22:21:37.100672 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   3: 22:21:37.101313 10.0.30.2 > 64.100.0.10: icmp: echo request 
   4: 22:21:37.114373 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   5: 22:21:37.157371 10.0.30.2 > 64.100.0.10: icmp: echo request 
   6: 22:21:37.174429 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   7: 22:21:39.234164 10.0.30.2 > 64.100.0.10: icmp: echo request 
   8: 22:21:39.238528 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   9: 22:21:39.261110 10.0.30.2 > 64.100.0.10: icmp: echo request 
  10: 22:21:39.270234 64.100.0.10 > 10.0.30.2: icmp: echo reply 
  11: 22:21:47.170614 10.0.30.2.38953 > 64.100.0.10.23: S 1841210281:1841210281(0) 
win 4128 <mss 536> 
  12: 22:21:47.198933 64.100.0.10.23 > 10.0.30.2.38953: S 3354834096:3354834096(0) 
ack 1841210282 win 4128 <mss 536> 
  13: 22:21:47.235186 10.0.30.2.38953 > 64.100.0.10.23: . ack 3354834097 
win 4128 
  14: 22:21:47.242815 64.100.0.10.23 > 10.0.30.2.38953: P 3354834097:3354834109(12) 
ack 1841210282 win 4128 
  15: 22:21:47.243014 10.0.30.2.38953 > 64.100.0.10.23: P 1841210282:1841210294(12) 
ack 3354834097 win 4128 
  16: 22:21:47.243258 10.0.30.2.38953 > 64.100.0.10.23: . ack 3354834097 
win 4128 
  17: 22:21:47.261094 64.100.0.10.23 > 10.0.30.2.38953: P 3354834109:3354834151(42) 
ack 1841210282 win 4128 
  18: 22:21:47.280411 64.100.0.10.23 > 10.0.30.2.38953: P 3354834151:3354834154(3) 
ack 1841210294 win 4116 
  19: 22:21:47.280625 64.100.0.10.23 > 10.0.30.2.38953: P 3354834154:3354834157(3) 
ack 1841210294 win 4116 
  20: 22:21:47.280838 64.100.0.10.23 > 10.0.30.2.38953: P 3354834157:3354834163(6) 
ack 1841210294 win 4116 
  21: 22:21:47.281082 10.0.30.2.38953 > 64.100.0.10.23: P 1841210294:1841210297(3) 
ack 3354834109 win 4116 
  22: 22:21:47.281296 10.0.30.2.38953 > 64.100.0.10.23: P 1841210297:1841210300(3) 
ack 3354834109 win 4116 

FW-A# sh cap capdmz

71 packets captured
   1: 22:21:37.095621 10.0.30.2 > 10.0.10.2: icmp: echo request 
   2: 22:21:37.100626 10.0.10.2 > 10.0.30.2: icmp: echo reply 
   3: 22:21:37.101343 10.0.30.2 > 10.0.10.2: icmp: echo request 
   4: 22:21:37.114297 10.0.10.2 > 10.0.30.2: icmp: echo reply 
   5: 22:21:37.157920 10.0.30.2 > 10.0.10.2: icmp: echo request 
   6: 22:21:37.174353 10.0.10.2 > 10.0.30.2: icmp: echo reply 
   7: 22:21:39.234713 10.0.30.2 > 10.0.10.2: icmp: echo request 
   8: 22:21:39.238452 10.0.10.2 > 10.0.30.2: icmp: echo reply 
   9: 22:21:39.261659 10.0.30.2 > 10.0.10.2: icmp: echo request 
  10: 22:21:39.270158 10.0.10.2 > 10.0.30.2: icmp: echo reply 
  11: 22:21:47.170950 10.0.30.2.38953 > 10.0.10.2.23: S 2196345248:2196345248(0) 
win 4128 <mss 536> 
  12: 22:21:47.198903 10.0.10.2.23 > 10.0.30.2.38953: S 1814294604:1814294604(0) 
ack 2196345249 win 4128 <mss 536> 
  13: 22:21:47.235263 10.0.30.2.38953 > 10.0.10.2.23: . ack 1814294605 win 4128 
  14: 22:21:47.242754 10.0.10.2.23 > 10.0.30.2.38953: P 1814294605:1814294617(12) 
ack 2196345249 win 4128 
  15: 22:21:47.243105 10.0.30.2.38953 > 10.0.10.2.23: P 2196345249:2196345261(12) 
ack 1814294605 win 4128 
  16: 22:21:47.243319 10.0.30.2.38953 > 10.0.10.2.23: . ack 1814294605 win 4128 
  17: 22:21:47.260988 10.0.10.2.23 > 10.0.30.2.38953: P 1814294617:1814294659(42) 
ack 2196345249 win 4128 
  18: 22:21:47.280335 10.0.10.2.23 > 10.0.30.2.38953: P 1814294659:1814294662(3) 
ack 2196345261 win 4116 
  19: 22:21:47.280564 10.0.10.2.23 > 10.0.30.2.38953: P 1814294662:1814294665(3) 
ack 2196345261 win 4116 
  20: 22:21:47.280777 10.0.10.2.23 > 10.0.30.2.38953: P 1814294665:1814294671(6) 
ack 2196345261 win 4116 
  21: 22:21:47.281143 10.0.30.2.38953 > 10.0.10.2.23: P 2196345261:2196345264(3) 
ack 1814294617 win 4116 
  22: 22:21:47.281357 10.0.30.2.38953 > 10.0.10.2.23: P 2196345264:2196345267(3) 
ack 1814294617 win 4116 

Packet Capture Applied for the "Single Subnet DMZ with Single VCS Expressway LAN Interface" Scenario

FW-B# sh cap
capture capin type raw-data interface inside [Capturing - 5815 bytes] 
  match ip host 10.0.30.2 host 64.100.0.10 
capture capout type raw-data interface outside [Capturing - 5815 bytes] 
  match ip host 10.0.10.3 host 10.0.30.2 

FW-B# sh cap capin

72 packets captured
   1: 22:30:06.783681 10.0.30.2 > 64.100.0.10: icmp: echo request 
   2: 22:30:06.847856 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   3: 22:30:06.877624 10.0.30.2 > 64.100.0.10: icmp: echo request 
   4: 22:30:06.900710 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   5: 22:30:06.971598 10.0.30.2 > 64.100.0.10: icmp: echo request 
   6: 22:30:06.999551 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   7: 22:30:07.075649 10.0.30.2 > 64.100.0.10: icmp: echo request 
   8: 22:30:07.134499 64.100.0.10 > 10.0.30.2: icmp: echo reply 
   9: 22:30:07.156409 10.0.30.2 > 64.100.0.10: icmp: echo request 
  10: 22:30:07.177496 64.100.0.10 > 10.0.30.2: icmp: echo reply 
  11: 22:30:13.802525 10.0.30.2.41596 > 64.100.0.10.23: S 1119515693:1119515693(0) 
win 4128 <mss 536> 
  12: 22:30:13.861100 64.100.0.10.23 > 10.0.30.2.41596: S 2006020203:2006020203(0) 
ack 1119515694 win 4128 <mss 536> 
  13: 22:30:13.935864 10.0.30.2.41596 > 64.100.0.10.23: . ack 2006020204 win 4128 
  14: 22:30:13.946804 10.0.30.2.41596 > 64.100.0.10.23: P 1119515694:1119515706(12) 
ack 2006020204 win 4128 
  15: 22:30:13.952679 10.0.30.2.41596 > 64.100.0.10.23: . ack 2006020204 win 4128 
  16: 22:30:14.013686 64.100.0.10.23 > 10.0.30.2.41596: P 2006020204:2006020216(12) 
ack 1119515706 win 4116 
  17: 22:30:14.035352 64.100.0.10.23 > 10.0.30.2.41596: P 2006020216:2006020256(40) 
ack 1119515706 win 4116 
  18: 22:30:14.045758 64.100.0.10.23 > 10.0.30.2.41596: P 2006020256:2006020259(3) 
ack 1119515706 win 4116 
  19: 22:30:14.046781 64.100.0.10.23 > 10.0.30.2.41596: P 2006020259:2006020262(3) 
ack 1119515706 win 4116 
  20: 22:30:14.047788 64.100.0.10.23 > 10.0.30.2.41596: P 2006020262:2006020268(6) 
ack 1119515706 win 4116 
  21: 22:30:14.052151 10.0.30.2.41596 > 64.100.0.10.23: P 1119515706:1119515709(3) 
ack 2006020256 win 4076 
  22: 22:30:14.089183 10.0.30.2.41596 > 64.100.0.10.23: P 1119515709:1119515712(3) 
ack 2006020256 win 4076 


ASA1# show cap capout

72 packets captured
   1: 22:30:06.784871 10.0.30.2 > 10.0.10.3: icmp: echo request 
   2: 22:30:06.847688 10.0.10.3 > 10.0.30.2: icmp: echo reply 
   3: 22:30:06.878769 10.0.30.2 > 10.0.10.3: icmp: echo request 
   4: 22:30:06.900557 10.0.10.3 > 10.0.30.2: icmp: echo reply 
   5: 22:30:06.972758 10.0.30.2 > 10.0.10.3: icmp: echo request 
   6: 22:30:06.999399 10.0.10.3 > 10.0.30.2: icmp: echo reply 
   7: 22:30:07.076808 10.0.30.2 > 10.0.10.3: icmp: echo request 
   8: 22:30:07.134422 10.0.10.3 > 10.0.30.2: icmp: echo reply 
   9: 22:30:07.156959 10.0.30.2 > 10.0.10.3: icmp: echo request 
  10: 22:30:07.177420 10.0.10.3 > 10.0.30.2: icmp: echo reply 
  11: 22:30:13.803104 10.0.30.2.41596 > 10.0.10.3.23: S 2599614130:2599614130(0) 
win 4128 <mss 536> 
  12: 22:30:13.860947 10.0.10.3.23 > 10.0.30.2.41596: S 4158597009:4158597009(0) 
ack 2599614131 win 4128 <mss 536> 
  13: 22:30:13.936017 10.0.30.2.41596 > 10.0.10.3.23: . ack 4158597010 win 4128 
  14: 22:30:13.946941 10.0.30.2.41596 > 10.0.10.3.23: P 2599614131:2599614143(12) 
ack 4158597010 win 4128 
  15: 22:30:13.952801 10.0.30.2.41596 > 10.0.10.3.23: . ack 4158597010 win 4128 
  16: 22:30:14.013488 10.0.10.3.23 > 10.0.30.2.41596: P 4158597010:4158597022(12) 
ack 2599614143 win 4116 
  17: 22:30:14.035108 10.0.10.3.23 > 10.0.30.2.41596: P 4158597022:4158597062(40) 
ack 2599614143 win 4116 
  18: 22:30:14.045377 10.0.10.3.23 > 10.0.30.2.41596: P 4158597062:4158597065(3) 
ack 2599614143 win 4116 
  19: 22:30:14.046384 10.0.10.3.23 > 10.0.30.2.41596: P 4158597065:4158597068(3) 
ack 2599614143 win 4116 
  20: 22:30:14.047406 10.0.10.3.23 > 10.0.30.2.41596: P 4158597068:4158597074(6) 
ack 2599614143 win 4116 
  21: 22:30:14.052395 10.0.30.2.41596 > 10.0.10.3.23: P 2599614143:2599614146(3) 
ack 4158597062 win 4076 
  22: 22:30:14.089427 10.0.30.2.41596 > 10.0.10.3.23: P 2599614146:2599614149(3) 
ack 4158597062 win 4076 

Recommendations

1. Avoid the implementation of any unsupported topology

For example, if you have both the VCS Control and VCS Expressway connected behind the inside ASA interface, just as shown in this scenario:

This kind of implementation requires the VCS Control IP address to be translated to the inside IP address of the ASA in order to force the return traffic to come back to the ASA to avoid asymmetric route problems for the NAT reflection.

Note: If the source IP address of the VCS Control is changed during this NAT translation with a twice NAT configuration instead of the suggested NAT reflection configuration, then the VCS Expressway will see traffic from its own public IP address, then the phone services for the MRA devices will not come up. This is not a supported deployment as per section 3 in the recommendations section below.

That said, it is highly recommended to implement the VCS Expressway as an Expressway-E Dual Network Interfaces Implementation instead of the single NIC with NAT reflection.

2. Ensure that SIP/H.323 inspection is completely disabled on the firewalls involved

It is highly recommended to disable SIP and H.323 inspection on firewalls that handle network traffic to or from an Expressway-E. When enabled, SIP/H.323 inspection is frequently found to negatively affect the Expressway built-in firewall/NAT traversal functionality.

This is an example of how to disable SIP and H.323 inspections on the ASA.

policy-map global_policy
 class inspection_default
  no inspect h323 h225 
  no inspect h323 ras 
  no inspect sip  

3. Ensure your actual Expressway implementation complies with the next requirements suggested by the Cisco telepresence developers

• The NAT configuration between the Expressway-C and Expressway-E is not supported.

• It is not supported when the Expressway-C and Expressway-E, get NATed to the same public IP address, for example:
        Expressway-C is configured with IP address 10.1.1.1
        Expressway-E has single NIC configured with IP address 10.2.2.1 and a static NAT is configured in the firewall with public IP address 64.100.0.10
        Then the Expressway-C cannot be NATted to the same public address 64.100.0.10

Recommended VCS Expressway Implementation

The recommended implementation for the VCS Expressway instead of the VCS Expressway with the NAT reflection configuration is the dual network interfaces/dual NIC VCS Expressway implementation, for further information please check the next link.

ASA NAT Configuration and Recommendations for the Expressway-E Dual Network Interfaces Implementation.

Related Information

• ASA NAT Configuration and Recommendations for the Expressway-E Dual Network Interfaces Implementation

• Cisco TelePresence Video Communication Server Basic Configuration (Control with Expressway) Deployment Guide

• Cisco Expressway IP Port Usage for Firewall Traversal

• Placing a Cisco VCS Expressway in a DMZ rather than in the public internet