In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie eine Reflexionskonfiguration für die Network Address Translation (NAT) auf den Cisco Adaptive Security Appliances für spezielle Cisco TelePresence-Szenarien implementiert wird, bei denen diese Art der NAT-Konfiguration auf der Firewall erforderlich ist.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Cisco ASA (Adaptive Security Appliance): grundlegende NAT-Konfiguration
Cisco TelePresence Video Communication Server (VCS) Control und VCS Expressway - Grundkonfiguration.
Anmerkung: Dieses Dokument ist nur dann für die Verwendung vorgesehen, wenn die empfohlene Bereitstellungsmethode eines VCS-Expressway oder Expressway-Edge mit beiden NIC-Schnittstellen in verschiedenen DMZs nicht verwendet werden kann. Weitere Informationen zur empfohlenen Bereitstellung mit dualen NICs finden Sie unter dem folgenden Link auf Seite 60: Cisco TelePresence Video Communication Server - Basiskonfiguration (Steuerung mit Expressway) - Bereitstellungsleitfaden
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
Cisco Appliances der Serien ASA 5500 und 5500-X, auf denen die Softwareversion 8.3 oder höher ausgeführt wird.
Cisco VCS Version X8.x und höher
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.
Hinweis: Im gesamten Dokument werden VCS-Geräte als VCS Expressway und VCS Control bezeichnet. Die gleiche Konfiguration gilt jedoch für Expressway-E- und Expressway-C-Geräte.
Laut Cisco TelePresence-Dokumentation gibt es zwei Arten von TelePresence-Szenarien, bei denen die NAT-Reflexionskonfiguration auf den FWs erforderlich ist, damit die VCS Control über die öffentliche IP-Adresse des VCS Expressway mit dem VCS Expressway kommunizieren kann.
Das erste Szenario umfasst ein einzelnes Subnetz der demilitarisierten Zone (DMZ), das eine einzelne VCS Expressway-LAN-Schnittstelle nutzt, und das zweite Szenario eine FW-DMZ mit drei Ports, die eine einzelne VCS Expressway-LAN-Schnittstelle nutzt.
Tipp: Weitere Informationen zur TelePresence-Implementierung finden Sie im Bereitstellungsleitfaden zur Cisco TelePresence Video Communication Server-Basiskonfiguration (Steuerung mit Expressway).
Die folgenden Topologien werden von Cisco NICHT empfohlen. Die empfohlene Bereitstellungsmethode für einen VCS Expressway oder Expressway Edge besteht darin, zwei verschiedene DMZs zu verwenden, wobei der Expressway in jeder DMZ eine NIC aufweist. Dieser Leitfaden ist für den Einsatz in Umgebungen vorgesehen, in denen die empfohlene Bereitstellungsmethode nicht verwendet werden kann.
In diesem Szenario kann FW A Datenverkehr an FW B weiterleiten (und umgekehrt). Der VCS Expressway ermöglicht die Übertragung von Videodatenverkehr über FW B, ohne dass der Datenverkehrsfluss auf FW B von den externen zu den internen Schnittstellen reduziert wird. Der VCS Expressway übernimmt auch das FW Traversal auf seiner öffentlichen Seite.
Hier ein Beispiel für dieses Szenario:

Bei dieser Bereitstellung werden folgende Komponenten verwendet:
Für FW A wurde eine statische Eins-zu-Eins-NAT konfiguriert, die die NAT für die öffentliche Adresse 64.100.0.10 an die LAN1-IP-Adresse des VCS Expressway durchführt. Der statische NAT-Modus wurde für die LAN1-Schnittstelle auf dem VCS Expressway mit der statischen NAT-IP-Adresse 64.100.0.10 aktiviert.
Anmerkung: Sie müssen den FQDN (Fully Qualified Domain Name) des VCS Expressway in der VCS Control Secure Traversal Client Zone (Peer Address) so eingeben, wie er von außerhalb des Netzwerks zu sehen ist. Der Grund hierfür ist, dass der VCS Expressway im statischen NAT-Modus anfordert, dass eingehender Signalisierungs- und Medienverkehr an seinen externen FQDN anstatt an seinen privaten Namen gesendet wird. Dies bedeutet auch, dass die externe FW den Verkehr von der VCS Control zum externen VCS Expressway FQDN zulassen muss. Dies wird als NAT-Reflektion bezeichnet und wird möglicherweise nicht von allen FW-Typen unterstützt.
In diesem Beispiel muss FW B die NAT-Reflektion des Datenverkehrs zulassen, der von der VCS Control stammt, die für die externe IP-Adresse (64.100.0.10) des VCS Expressway bestimmt ist. Die Traversal-Zone auf der VCS Control muss 64.100.0.10 als Peer-Adresse aufweisen (nach FQDN zu IP Konvertierung).
Der VCS Expressway sollte mit einem Standard-Gateway 10.0.10.1 konfiguriert werden. Ob die statischen Routen in diesem Szenario erforderlich sind, hängt von den Funktionen und Einstellungen von FW A und FW B ab. Die Kommunikation von der VCS Control zum VCS Expressway erfolgt über die IP-Adresse 64.100.0.10 des VCS Expressway. und der Rückverkehr vom VCS Expressway zur VCS Control muss ggf. über das Standard Gateway geführt werden.
Der VCS Expressway kann der Cisco TMS mit der IP-Adresse 10.0.10.3 (oder mit der IP-Adresse 64.100.0.10, falls FW B dies zulässt) hinzugefügt werden, da die Cisco TMS Managementkommunikation durch die statischen NAT-Moduseinstellungen auf dem VCS Expressway nicht beeinflusst wird.
Hier ein Beispiel für dieses Szenario:

Bei dieser Bereitstellung wird eine FW mit 3 Ports verwendet, um Folgendes zu erstellen:
Für FW A wurde eine statische Eins-zu-Eins-NAT konfiguriert, die die NAT der öffentlichen IP-Adresse 64.100.0.10 zur LAN1-IP-Adresse des VCS Expressway durchführt. Der statische NAT-Modus wurde für die LAN1-Schnittstelle auf dem VCS Expressway mit der statischen NAT-IP-Adresse 64.100.0.10 aktiviert.
Der VCS Expressway sollte mit einem Standard-Gateway 10.0.10.1 konfiguriert werden. Da dieses Gateway für den gesamten Verkehr, der den VCS Expressway verlässt, verwendet werden muss, sind bei dieser Art der Bereitstellung keine statischen Routen erforderlich.
Die Traversal-Client-Zone auf der VCS Control muss aus denselben Gründen wie im vorherigen Szenario beschrieben mit einer Peer-Adresse konfiguriert werden, die mit der statischen NAT-Adresse des VCS Expressway (in diesem Beispiel 64.100.0.10) übereinstimmt.
Anmerkung: Das bedeutet, dass FW A Datenverkehr von der VCS Control mit einer Ziel-IP-Adresse 64.100.0.10 zulassen muss. Dies wird auch als NAT-Reflektion bezeichnet, und es ist zu beachten, dass dies nicht von allen Arten von FWs unterstützt wird.
Der VCS Expressway kann der Cisco TMS mit der IP-Adresse 10.0.10.2 (oder mit der IP-Adresse 64.100.0.10, falls FW A dies zulässt) hinzugefügt werden, da die Cisco TMS Managementkommunikation durch die statischen NAT-Moduseinstellungen auf dem VCS Expressway nicht beeinflusst wird.
In diesem Abschnitt wird beschrieben, wie die NAT-Reflektion in der ASA für die beiden unterschiedlichen VCS C- und E-Implementierungsszenarien konfiguriert wird.
Im ersten Szenario müssen Sie diese NAT-Reflexionskonfiguration auf FW A anwenden, um die Kommunikation von der VCS Control (10.0.30.2) zu ermöglichen, die an die externe IP-Adresse (64.100.0.10) des VCS Expressway gerichtet ist:

In diesem Beispiel lautet die IP-Adresse von VCS Control 10.0.30.2/24 und die IP-Adresse von VCS Expressway 10.0.10.3/24.
Wenn Sie davon ausgehen, dass die IP-Adresse 10.0.30.2 der VCS-Steuerung bei der Suche nach dem VCS Expressway mit der IP-Zieladresse 64.100.0.10 von innen nach außen bei FW B erhalten bleibt, wird in diesen Beispielen die Konfiguration der NAT-Reflektion gezeigt, die Sie bei FW B implementieren sollten.
Beispiel für ASA Version 8.3 und höher:
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.
Beispiel für ASA Version 8.2 und frühere Versionen:
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
Anmerkung: Das Hauptziel dieser NAT-Reflexionskonfiguration besteht darin, der VCS Control die Möglichkeit zu geben, die VCS-Schnellstraße zu erreichen. Dabei wird anstelle der privaten IP-Adresse die öffentliche IP-Adresse der VCS-Schnellstraße verwendet. Wenn die Quell-IP-Adresse der VCS Control während dieser NAT-Übersetzung mit einer zweifachen NAT-Konfiguration anstelle der gerade gezeigten vorgeschlagenen NAT-Konfiguration geändert wird, sodass VCS Expressway den Datenverkehr von seiner eigenen öffentlichen IP-Adresse erkennt, werden die Telefondienste für die MRA-Geräte nicht aktiviert. Dies ist keine unterstützte Bereitstellung gemäß Abschnitt 3 im unten stehenden Abschnitt mit Empfehlungen.
Im zweiten Szenario müssen Sie diese NAT-Reflektionskonfiguration auf FW A anwenden, um die NAT-Reflektion des eingehenden Datenverkehrs von VCS Control 10.0.30.2 zu ermöglichen, der an die externe IP-Adresse (64.100.0.10) des VCS Expressway gerichtet ist:

In diesem Beispiel lautet die IP-Adresse von VCS Control 10.0.30.2/24 und die IP-Adresse von VCS Expressway 10.0.10.2/24.
Wenn Sie davon ausgehen, dass die IP-Adresse 10.0.30.2 der VCS-Steuerung bei der Suche nach dem VCS Expressway mit der IP-Zieladresse 64.100.0.10 von innen zur DMZ-Schnittstelle von FW A verbleibt, wird in diesen Beispielen die Konfiguration der NAT-Reflektion gezeigt, die Sie in FW A implementieren sollten.
Beispiel für ASA Version 8.3 und höher:
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.
Beispiel für ASA Version 8.2 und frühere Versionen:
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
Anmerkung: Das Hauptziel dieser NAT-Reflexionskonfiguration besteht darin, dass die VCS Control die VCS-Schnellstraße erreichen kann, jedoch mit der öffentlichen IP-Adresse der VCS-Schnellstraße anstelle ihrer privaten IP-Adresse. Wenn die Quell-IP-Adresse der VCS Control während dieser NAT-Übersetzung mit einer doppelten NAT-Konfiguration anstelle der gerade gezeigten NAT-Konfiguration geändert wird, was dazu führt, dass VCS Expressway den Datenverkehr von seiner eigenen öffentlichen IP-Adresse sieht, werden die Telefondienste für die MRA-Geräte nicht aktiviert. Dies ist keine unterstützte Bereitstellung gemäß Abschnitt 3 im unten stehenden Abschnitt mit Empfehlungen.
In diesem Abschnitt werden die Packet-Tracer-Ausgänge beschrieben, die Sie in ASA sehen können, um zu bestätigen, dass die NAT-Reflektionskonfiguration sowohl im VCS C- als auch im E-Implementierungsszenario wie erforderlich funktioniert.
Die Ausgabe des FW B Packet Tracer für ASA Version 8.3 und höher lautet wie folgt:
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
Die Ausgabe des FW B-Paketverfolgungsgeräts für ASA Version 8.2 und früher:
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
Die folgende Ausgabe des FW A Packet Tracer für ASA Version 8.3 und höher ist verfügbar:
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
Die folgende Ausgabe des FW A Packet Tracer für ASA Version 8.2 und frühere Versionen:
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
Sie können die Paketerfassung auf den ASA-Schnittstellen konfigurieren, um die NAT-Übersetzung zu bestätigen, wenn die Pakete in die beteiligten FW-Schnittstellen eintreten und diese verlassen.
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
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
Wenn beispielsweise sowohl VCS Control als auch VCS Expressway hinter der ASA-Schnittstelle angeschlossen sind, wie in diesem Szenario gezeigt:

Bei dieser Art der Implementierung muss die IP-Adresse der VCS-Steuerung in die interne IP-Adresse der ASA übersetzt werden, damit der zurückkehrende Datenverkehr zur ASA zurückkehren muss, um asymmetrische Routenprobleme für die NAT-Reflektion zu vermeiden.
Hinweis: Wenn die Quell-IP-Adresse der VCS Control während dieser NAT-Übersetzung mit einer doppelten NAT-Konfiguration anstelle der vorgeschlagenen NAT-Reflexionskonfiguration geändert wird, sieht der VCS Expressway den Datenverkehr von seiner eigenen öffentlichen IP-Adresse, dann werden die Telefondienste für die MRA-Geräte nicht aktiviert. Dies ist keine unterstützte Bereitstellung gemäß Abschnitt 3 im unten stehenden Abschnitt mit Empfehlungen.
Dennoch wird dringend empfohlen, den VCS Expressway anstelle der einzelnen NIC mit NAT-Reflexion als Expressway-E Dual Network Interfaces Implementation zu implementieren.
Es wird dringend empfohlen, die SIP- und H.323-Inspektion auf Firewalls zu deaktivieren, die Netzwerkverkehr von oder zu einem Expressway-E verarbeiten. Wenn diese Funktion aktiviert ist, wird häufig festgestellt, dass SIP/H.323-Prüfungen die integrierte Firewall-/NAT-Überbrückungsfunktion von Expressway beeinträchtigen.
Dies ist ein Beispiel dafür, wie SIP- und H.323-Prüfungen auf der ASA deaktiviert werden.
policy-map global_policy class inspection_default no inspect h323 h225 no inspect h323 ras no inspect sip
Die empfohlene Implementierung für den VCS Expressway anstelle des VCS Expressway mit der NAT-Reflexionskonfiguration ist die Implementierung der dualen Netzwerkschnittstellen/dualen NIC VCS Expressway. Weitere Informationen finden Sie unter dem nächsten Link.
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
30-Oct-2017
|
Erstveröffentlichung |
Feedback