Servizi telefonici MRA non riusciti a causa della conversione IP di origine su reflection NAT (configurazione NIC singola con NAT statico abilitato)

Introduzione

In questo documento viene descritto come risolvere i problemi relativi a errori dei servizi telefonici su MRA causati dalla conversione dell'IP di origine su reflection NAT, con una scheda NIC Expressway-E con configurazione NAT statica.

Prerequisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• NAT (Network Address Translation)
• SIP (Session Initiation Protocol)
• Configurazione base Cisco Video Communication Server (VCS) o Expressway
• Mobile and Remote Access (MRA) over Expressway o VCS

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Nota: in tutto il documento, i dispositivi Expressway vengono denominati Expressway-E ed Expressway-C. Tuttavia, la stessa configurazione si applica a Video Communication Server (VCS) Expressway e ai dispositivi di controllo VCS. 

Premesse

Questo documento descrive uno scenario in cui Mobile and Remote Access è stato implementato su Expressway con Expressway-E utilizzando una singola NIC e un indirizzo NAT statico (descritto come DMZ firewall a 3 porte con interfaccia LAN Single Expressway-E, come descritto nella Guida alla configurazione di base di Expressway). Gli utenti MRA sono in grado di eseguire l'accesso, ma non hanno accesso ai servizi telefonici.

Il messaggio SIP REGISTER dal client esterno è stato ricevuto da Expressway-E correttamente sulla porta 5061.
Expressway-E crea quindi un messaggio SIP SERVICE verso Expressway-C. La richiesta genera un timeout di richiesta 408.

Problema

Servizi telefonici non riusciti. Il messaggio SIP REGISTER non passa attraverso Cisco Unified Communications Manager (CUCM o Call Manager). Expressway-E ed Expressway-C non sono in grado di scambiare correttamente i propri certificati utilizzando lo scambio di messaggi SIP SERVICE. I messaggi SIP SERVICE ottengono solo un timeout di richiesta 408 come risposta da Expressway-C. Poiché il messaggio SIP SERVICE ha esito negativo, Expressway-E non inoltra il messaggio SIP REGISTER a Expressway-C.
Questo problema è causato dal fatto che il firewall tra Expressway-C ed Expressway-E esegue la conversione IP (e della porta) dei messaggi da Expressway-C a Expressway-E. In questo modo, Expressway-C instrada in modo non corretto i messaggi SIP SERVICE verso l'indirizzo tradotto anziché verso il proprio indirizzo locale. In uno scenario corretto, Expressway-C elabora il messaggio SIP SERVICE stesso. Il messaggio SIP SERVICE tra Expressway-E ed Expressway-C viene utilizzato per verificare i certificati e pertanto viene visualizzato solo all'inizio dell'impostazione di una zona di attraversamento o alla prima registrazione su MRA.

Esempio di rete

L'immagine seguente mostra un esempio di diagramma di rete, utilizzato come riferimento in questo documento:

Dettagli

Dall'acquisizione del pacchetto Expressway-C, è possibile notare che Expressway-C (10.0.30.2) si connette correttamente all'indirizzo IP pubblico NAT statico Expressway-E (64.100.0.10) sulla porta 7003. (Si noti che la porta di origine è 27901 sull'Expressway-C): 

Nelle acquisizioni dei pacchetti di Expressway-E, è possibile vedere che la connessione viene da 64.100.0.10 sulla porta 4401 (che è il proprio indirizzo IP pubblico NAT statico) con destinazione 10.0.10.2 e porta 7003:

Queste sono le prospettive della connessione tra Expressway-C ed 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

Ciò indica che il firewall tra Expressway-C ed Expressway-E sta eseguendo la conversione dell'IP di origine e della porta su tali messaggi.
Se si esamina il flusso di comunicazione SIP su Expressway-E, è possibile vedere che ottiene il SIP REGISTER dal dispositivo client MRA, Expressway-E genera un messaggio SIP SERVICE per scambiare i propri certificati con Expressway-C, ma ciò genera un timeout di richiesta 408.

Prove nei registri diagnostici

Si noti che l'intestazione Route di questo messaggio SIP SERVICE (inviato da Expressway-E a Expressway-C) contiene l'IP e la porta dell'indirizzo NAT (64.100.0.10:4401).
Quando il messaggio arriva a Expressway-C, Expressway-C tenta di instradare il messaggio in base all'intestazione della route verso 64.100.0.10:4401. L'operazione non riesce in quanto non è possibile stabilire una connessione a questo indirizzo, in quanto si trova sul lato server di Expressway-E. Anche se Expressway-C è in grado di connettersi a questo indirizzo, non è corretto in quanto il messaggio SIP SERVICE è destinato a Expressway-C per la ricezione e l'elaborazione. 

Il messaggio SIP SERVICE arriva a Expressway-C:

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 tenta di inviare questo messaggio SIP SERVICE relativo ai dati visualizzati nell'intestazione della route, ma la connessione non riesce: 

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"

Nell'acquisizione di pacchetti di Expressway-C, il tentativo di TCP SYN ottiene una risposta RST: 

 Di conseguenza, Expressway-C invia un timeout di richiesta 408 verso Expressway-E: 

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

Soluzione

Ci sono due possibili soluzioni per questa condizione.

Disabilita la conversione della porta IP di origine sul firewall

Se si disabilita la conversione della porta/IP di origine sul firewall, il server Expressway-E visualizzerà il traffico Expressway-C come in arrivo dalle 10.0.30.2:27901 (indirizzo IP e porta effettivi su Expressway-C) anziché dalle 64.100.0.10:4401 (indirizzo NAT). In questo modo, l'intestazione Route nel messaggio SIP SERVICE contiene il valore 10.0.30.2:27901 e, alla ricezione di questo messaggio, Expressway-C lo instrada a se stesso e vi esegue alcune elaborazioni, restituendo un 200 OK all'Expressway-E (se tutto va bene) che inoltrerà tramite il messaggio SIP REGISTER per continuare il processo di registrazione.

Passaggio a una configurazione a due schede NIC

Con una configurazione a doppia scheda NIC su Expressway-E, non è necessario eseguire la riflessione NAT ed evitare il problema. Tuttavia, accertarsi che il firewall interno tra Expressway-E ed Expressway-C (se presente) non esegua la conversione dell'origine IP/porta dal traffico da Expressway-C a Expressway-E (con conseguenti problemi simili).

Informazioni correlate

• Le distribuzioni di rete supportate per Expressway sono descritte in dettaglio nell'Appendice 4 della Guida alla configurazione di base di Expressway
• Seguire i dettagli della configurazione ASA per configurare le distribuzioni di rete Expressway supportate