MRA-Telefondienste fehlschlagen aufgrund der Quell-IP-Übersetzung über NAT-Reflektion (einzelne NIC-Konfiguration mit aktivierter statischer NAT)

Einführung

In diesem Dokument wird beschrieben, wie Sie bei einem Ausfall der Telefondienste über MRA, der durch die IP-Quellübersetzung über NAT-Reflektion verursacht wird, mit einer Expressway-E Single-NIC mit statischer NAT-Konfiguration Fehler beheben können.

Voraussetzungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• NAT (Network Address Translation)
• SIP (Session Initiation Protocol)
• Grundkonfiguration des Cisco Video Communication Server (VCS) oder Expressway
• Mobiler und Remote-Zugriff (MRA) über Expressway oder VCS

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hinweis: Expressway-Geräte werden im gesamten Dokument als Expressway-E und Expressway-C bezeichnet. Die gleiche Konfiguration gilt jedoch auch für Video Communication Server (VCS) Expressway- und VCS Control-Geräte. 

Hintergrundinformationen

Dieses Dokument behandelt ein Szenario, in dem Mobil- und Remote-Zugriff auf Expressway mit Expressway-E mithilfe einer einzigen NIC und einer statischen NAT-Adresse bereitgestellt wurde (beschrieben als 3-Port-Firewall DMZ mit Single Expressway-E LAN Interface, wie im Expressway Basic Configuration Guide beschrieben). MRA-Benutzer können sich erfolgreich anmelden, haben jedoch keinen Zugriff auf Telefondienste.

Die SIP-REGISTER-Nachricht von einem externen Client wird von Expressway-E erfolgreich an Port 5061 empfangen.
Expressway-E erstellt dann eine SIP-SERVICE-Nachricht an Expressway-C. Diese Anfrage resultiert in einem 408 Request Timeout.

Problem

Telefondienste schlagen fehl, da die SIP-REGISTER-Nachricht nicht an den Cisco Unified Communications Manager (CUCM oder Call Manager) weitergeleitet wird. Expressway-E und Expressway-C sind nicht in der Lage, ihre Zertifikate ordnungsgemäß über den SIP SERVICE Message Exchange auszutauschen. Die SIP-SERVICE-Nachrichten erhalten nur ein 408 Request Timeout als Antwort vom Expressway-C. Da die SIP-SERVICE-Nachricht nicht erfolgreich ist, leitet das Expressway-E die SIP-REGISTER-Nachricht nicht an den Expressway-C weiter.
Dies liegt daran, dass die Firewall zwischen Expressway-C und Expressway-E die Quell-IP (und Port)-Übersetzung für Nachrichten vom Expressway-C zum Expressway-E durchführt. Dies führt dazu, dass Expressway-C diese SIP-SERVICE-Nachrichten fälschlicherweise an die übersetzte Adresse anstatt an die eigene lokale Adresse weiterleitet. In einem erfolgreichen Szenario verarbeitet Expressway-C die SIP-SERVICE-Nachricht selbst. (Die SIP-SERVICE-Nachricht zwischen Expressway-E und Expressway-C wird zur Prüfung von Zertifikaten verwendet und wird daher nur zu Beginn einer Traversal Zone-Einrichtung oder bei der ersten Registrierung über MRA angezeigt.)

Netzwerkdiagramm

Das folgende Bild zeigt ein Beispiel für ein Netzwerkdiagramm, das in diesem Dokument als Referenz verwendet wird:

Details

Aus den Expressway-C-Paketerfassungen können Sie sehen, dass der Expressway-C (10.0.30.2) erfolgreich mit der statischen öffentlichen IP-Adresse Expressway-E (64.100.0.10) an Port 7003 verbunden ist. (Beachten Sie, dass der Quellport auf dem Expressway-C "27901" lautet: 

In der Paketerfassung des Expressway-E kann man sehen, dass die Verbindung von 64.100.0.10 auf Port 4401 (d. h. seine eigene statische öffentliche NAT-IP-Adresse) mit Ziel 10.0.10.2 und Port 7003 hergestellt wird:

Dies sind die Perspektiven der Verbindung zwischen Expressway-C und E:

 Expressway-C: 10.0.30.2:27901 <-> 64.100.0.10:7003
 Expressway-E: 64.100.0.10:4401 <-> 10.0.10.2:7003

Dies weist darauf hin, dass die Firewall zwischen Expressway-C und Expressway-E die Quell-IP- und Port-Übersetzung für diese Nachrichten durchführt.
Wenn Sie sich den SIP-Kommunikationsfluss auf Expressway-E anschauen, sehen Sie, dass der SIP-REGISTER vom MRA-Client-Gerät abgerufen wird. Anschließend generiert Expressway-E eine SIP-SERVICE-Nachricht, um seine Zertifikate mit dem Expressway-C auszutauschen. Dies führt jedoch zu einem 408 Request-Timeout.

Beweise für Diagnoseprotokolle

Beachten Sie, dass der Route-Header dieser SIP-SERVICE-Nachricht (von Expressway-E an Expressway-C gesendet) die IP-Adresse und den Port der NAT-Adresse (64.100.0.10:4401) enthält.
Wenn diese Nachricht auf dem Expressway-C eingeht, versucht Expressway-C, die Nachricht basierend auf diesem Route-Header an 64.100.0.10:4401 weiterzuleiten. Dies schlägt fehl, da es keine Verbindung zu dieser Adresse herstellen kann, da diese Adresse auf der Seite des Expressway-E Servers ist. Auch wenn Expressway-C eine Verbindung zu dieser Adresse herstellen kann, ist sie nicht korrekt, da die SIP-SERVICE-Nachricht für den Empfang und die Bearbeitung von Expressway-C vorgesehen ist. 

Die SIP-SERVICE-Nachricht kommt bei Expressway-C an:

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,973" Module="network.sip" Level="DEBUG":  Action="Received"  Local-ip="10.0.30.2"  Local-port="27901"  Src-ip="64.100.0.10"  Src-port="7003"  Msg-Hash="123456789123456789"
 SIPMSG:
 |SERVICE sip:serviceserver@cucm02.example.local SIP/2.0
 Via: SIP/2.0/TLS 64.100.0.10:7003;egress-zone=UCTraversal;branch=[branchID];proxy-call-id=[callid];rport
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=[branchID];received=127.0.0.1;rport=25063;ingress-zone=DefaultZone
 Call-ID: abcd12345678@127.0.0.1
 CSeq: 4616 SERVICE
 Contact: <sip:serviceproxy@cucm02.example.local>
 From: <sip:serviceproxy@cucm02.example.local>;tag=0987654321aaaa
 To: <sip:serviceserver@cucm02.example.local>
 Max-Forwards: 15
 Route: <sip:64.100.0.10:4401;transport=tls;apparent;ds;lr>
 Route: <sip:127.0.0.1:22210;transport=tcp;vcs-cate;lr>
 User-Agent: TANDBERG/4132 (X8.7.2)
 Date: Tue, 19 Apr 2016 07:09:13 GMT
 Event: service
 P-Asserted-Identity: <sip:serviceproxy@cucm02.example.local>
 X-TAATag: e90b4983919b1f7a46d38f835
 Identity: "7ioJ9gpsS5ob2TUAttNxBGYRWDbnRuf5skrkxP+B14ngRvjkIWIu7BQP5W7vW1BTVyVaGuubV5u7rPDc5anDx9u46i/8TkxxYuxkr83DEh/cYPWlwO7JvTP5nub6/EtEt6RXvwizY6Gm/MXV4eMqQJ06kA86EFxP1SsRxop0YjUs61B10JnBrtQjOicskoAuMGzNjiBKvcCAbrASGtWP015vRp9khcs3e8vmkpZH5Qtef6+gNaRWPES3MS=="
 Content-Type: multipart/mixed;boundary=boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Length: 2555
 
 --boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Type: application/text
 
 <?xml version="1.0" encoding="utf-8"?> <methodCall><params><username>john.smith</username><realm>expe.example.com</realm><nonce>2i78worv9unccs6vbclfi4xai78worv9unccs6vbclfi4xa4i15j</nonce><qop>auth</qop><cnonce>54f80570</cnonce><nc>00000001</nc><response>2i78worv9unccs6vbclfi4xa4i15j</response><uri>sip:cucm02.example.local</uri><method>REGISTER</method><id>12345678</id><caching-enabled>true</caching-enabled><reqtype>collab-edge</reqtype></params><methodName>DigestAuth</methodName><version>1.0</version><msgid>12345678979</msgid><sipdomain>cucm02.example.local</sipdomain></methodCall>
 
 --boundary-6j7zrmj35ifsu3efg5ga603hnz1nbf
 Content-Type: application/x-x509-ca-cert
-----BEGIN CERTIFICATE-----
hknS5nQ8NJEspxLPY0N4BvA8iL7ZasOqnqgHRlj95N8bn
OfigoKhe90kV6Y7PRbRpwFv6jGiFR8hyepr3t2BPec0aZ
ZAK3ZC92RQbDjCxy2U99L8WLlTpJQwIuTjLHicbiNCNZu
Be9xEMgewwGFVfSzW08DzlecJNXpsKqQ0ivbpLbwreXJG
SCbcse3O67yvghMDsotcK4gur11FZWOZJFa3EMlgoT3Mj
ApGvMfL9caTjY1EaLWDl5rWGGe8FpRLCizrz0wwUGg7Px
Moy6kAujtolwN9BUI0sgJ98MnBuuREJZNW7g7nJL5zywT
FXhMgy9PBUMuwjgu5KruY4caWDYtNu1kZzCtnm044lOk7
xhIOoOWWj9sNFnDQGDrgBIFBjggEihSbZr6h4Pq2ZMZ4r
i5yGpz0j7a6lg2NOKm6FXpfqVlB7zvyQsM6x0XJEImpjV
al0nHYkTLkBEmK5jVosgyOrSWpZPimc364sRxRW4ABZZX
M6XstZNGhvQNDVk1JlfCN5yRtEgEkkizeWOHJcts922wL
2rVTfUfWGXMkca8YHKj2ixkthNnHVbLG0YoUNOUDHq1xu
49F7Kcw7neuQQZ4MmEif59lnyhY7qEIQVEpGn0jgqZAX8
omNVxTewa9nTXvjxo5xvTLghYfESCqniBbtWwMhhRuR7N
eh09OvFWsuUyHJmDBYpoNZWTXEB4Fw5XwfjzZAoHzOFV6
xcE4LGYrpI4EbaZ58r8uVrfXkrNrgepFw2zMgamhwf9n5
AzEU2gh9vTUNZEAn8De5XQKAipeehO8Dpef2JTBLV5avf
nh7rfxh8BZY4xteSRox8iBnT4Na6qsDMb2gvp6gTYFFJH
RGMHIe5siI1HhARqDjen4EwrKfMOYNJWTqmx4mjDrqyme
 -----END CERTIFICATE-----
 
 
  |

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,977" Module="developer.sip.leg" Level="INFO" CodeLocation="ppcmains/sip/sipproxy/SipProxyLeg.cpp(10047)" Method="SipProxyLeg::routeViaNettleIfNeeded" Thread="0x3150905deea6":  this="0xc76759f343ca" Type="Outbound"  routingViaNettle="false"  twoInARow="false" oneIsATraversalServerZone="false" isCall="false" isRefer="false" fromClusterPeer="false" fromNettle="false" toNettle="false" inboundZone=UC_Traversal (encryption-mode=on ice-mode=off) outboundZone=DefaultZone (encryption-mode=auto ice-mode=off) encryptionSettingsRequireNettle="true" iceSettingsRequireNettle="false" needlesslyNettling="false" routeViaNettle="false"

Expressway-C versucht, diese SIP-SERVICE-Nachricht an die Angaben im Routen-Header zu senden, die Verbindung schlägt jedoch fehl: 

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,979" Module="network.tcp" Level="DEBUG":  Src-ip="10.0.30.2" Src-port="27921" Dst-ip="64.100.0.10" Dst-port="4401" Detail="TCP Connecting"
2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,980" Module="network.tcp" Level="ERROR":  Src-ip="10.0.30.2" Src-port="27921" Dst-ip="64.100.0.10" Dst-port="4401" Detail="TCP Connection Failed"

Bei der Paketerfassung von Expressway-C erhält der TCP-SYN-Versuch eine RST-Antwort: 

 Das Ergebnis ist, dass Expressway-C ein 408 Request Timeout an Expressway-E sendet: 

2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,982" Module="network.sip" Level="INFO":  Action="Sent"  Local-ip="10.0.30.2"  Local-port="27901"  Dst-ip="64.100.0.10"  Dst-port="7003"   Detail="Sending Response Code=408, Method=SERVICE, CSeq=4616, To=sip:serviceserver@cucm02.example.local, Call-ID=abcd12345678@127.0.0.1, From-Tag=0987654321aaaa, To-Tag=0987654321bbbb, Msg-Hash=123456789123456789"
2016-04-19T17:09:13+10:00 expc tvcs: UTCTime="2016-04-19 07:09:13,982" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.0.30.2"  Local-port="27901"  Dst-ip="64.100.0.10"  Dst-port="7003"  Msg-Hash="123456789123456789"
 SIPMSG:
 |SIP/2.0 408 Request Timeout
 Via: SIP/2.0/TLS 64.100.0.10:7003;egress-zone=UCTraversal;branch=[branchID];proxy-call-id=[callid];received=64.100.0.10;rport=7003;ingress-zone=UCTraversal;ingress-zone-id=4
 Via: SIP/2.0/TCP 127.0.0.1:5060;branch=[branchID];received=127.0.0.1;rport=25063;ingress-zone=DefaultZone
 Call-ID: abcd12345678@127.0.0.1
 CSeq: 4616 SERVICE
 From: <sip:serviceproxy@cucm02.example.local>;tag=0987654321aaaa
 To: <sip:serviceserver@cucm02.example.local>;tag=0987654321bbbb
 Server: TANDBERG/4132 (X8.7.2)
 Warning: 399 10.0.30.2:5061 "Request Timeout"
 Content-Length: 0

Lösung

Es gibt zwei mögliche Lösungen für diese Bedingung.

Deaktivieren Sie die Quell-IP-Port-Übersetzung auf der Firewall.

Wenn Sie die Quell-IP/Port-Übersetzung auf der Firewall deaktivieren, betrachtet der Expressway-E-Server den Expressway-C-Datenverkehr als von 10.0.30.2:27901 ankommend (tatsächliche IP und Port auf dem Expressway-C) anstatt von 64.100.0.10:4401 (NAT-Adresse). Auf diese Weise enthält der Routen-Header in der SIP-SERVICE-Nachricht den Wert 10.0.30.2:27901. Nach Erhalt dieser Nachricht leitet der Expressway-C die Nachricht an sich weiter und verarbeitet sie, sodass ein 200 OK an den Expressway-E zurückgesendet werden kann (wenn alles in Ordnung ist), der dann über die SIP REGISTER-Nachricht protrahiert Setzen Sie den Registrierungsprozess fort.

Wechsel zu einer Konfiguration mit zwei NICs

Bei einer Konfiguration mit zwei NICs auf Expressway-E muss keine NAT-Reflektion durchgeführt werden, und das Problem wird vermieden. Stellen Sie jedoch sicher, dass die interne Firewall zwischen Expressway-E und Expressway-C (sofern vorhanden) keine IP/Port-Quell-Übersetzung vom Datenverkehr von Expressway-C nach Expressway-E durchführt (was zu ähnlichen Problemen führen würde).

Zugehörige Informationen

• Unterstützte Netzwerkbereitstellungen für Expressway sind in Anhang 4 des Expressway Basic Configuration Guide detailliert beschrieben.
• Befolgen Sie die ASA-Konfigurationsdetails, um die unterstützten Expressway-Netzwerkbereitstellungen zu konfigurieren.