Fallo en los servicios telefónicos MRA debido a la traducción IP de origen sobre la reflexión NAT (configuración NIC única con NAT estática habilitada)

Introducción

Este documento describe cómo resolver problemas de falla de servicios telefónicos sobre MRA causada por la traducción IP de origen sobre la reflexión NAT, con Expressway-E single-NIC con configuración NAT estática.

Prerequisites

Cisco recomienda que tenga conocimiento sobre estos temas:

• NAT (traducción de direcciones de red)
• SIP (protocolo de inicio de sesión)
• Configuración básica de Cisco Video Communication Server (VCS) o Expressway
• Acceso remoto y móvil (MRA) a través de Expressway o VCS

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Nota: A través de todo el documento, los dispositivos de Expressway se denominan Expressway-E y Expressway-C. Sin embargo, la misma configuración se aplica a los dispositivos de control VCS y Expressway de Video Communication Server (VCS). 

Antecedentes

Este documento describe un escenario en el que se ha implementado el acceso móvil y remoto en Expressway con Expressway-E usando una única dirección NIC y NAT estática (descrita como DMZ de firewall de 3 puertos con interfaz LAN de Expressway-E, como se describe en la Guía de configuración básica de Expressway). Los usuarios de MRA pueden iniciar sesión correctamente, pero no tienen acceso a los servicios telefónicos.

Expressway-E recibe correctamente el mensaje SIP REGISTER del cliente externo en el puerto 5061.
Expressway-E luego crea un mensaje de servicio SIP hacia Expressway-C. Esta solicitud da como resultado un tiempo de espera de solicitud 408.

Problema

Los servicios telefónicos fallan porque el mensaje SIP REGISTER no pasa a Cisco Unified Communications Manager (CUCM o Call Manager). Expressway-E y Expressway-C no pueden intercambiar sus certificados correctamente mediante el intercambio de mensajes de servicio SIP. Los mensajes de servicio SIP solo obtienen un tiempo de espera de solicitud 408 como respuesta de Expressway-C. Como el mensaje de servicio SIP no es exitoso, Expressway-E no reenvía el mensaje de registro SIP a Expressway-C.
Esto se debe al hecho de que el firewall entre Expressway-C y Expressway-E realiza la traducción IP de origen (y de puerto) para los mensajes de Expressway-C a Expressway-E. Esto da como resultado que Expressway-C rutea esos mensajes de servicio SIP incorrectamente hacia esa dirección traducida, en lugar de su propia dirección local. En un escenario exitoso, Expressway-C procesa el mensaje SIP SERVICE en sí mismo. (El mensaje SIP SERVICE entre Expressway-E y Expressway-C se utiliza para comprobar los certificados y, por lo tanto, solo se ve al principio de una configuración de zona transversal o al primer registro sobre MRA.)

Diagrama de la red

La siguiente imagen proporciona un ejemplo de un diagrama de red, que se utiliza como referencia en todo este documento:

Detalles

Desde las capturas de paquetes de Expressway-C, puede ver que Expressway-C (10.0.30.2) se conecta correctamente a la dirección IP pública NAT estática de Expressway-E (64.100.0.10) en el puerto 7003. (Observe que el puerto de origen es 27901 en Expressway-C): 

En las capturas de paquetes de Expressway-E puede ver que la conexión viene de 64.100.0.10 en el puerto 4401 (que es su propia dirección IP pública NAT estática) con el destino 10.0.10.2 y el puerto 7003:

Estas son las perspectivas de la conexión entre Expressway-C y 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

Esto indica que el firewall entre Expressway-C y Expressway-E está realizando la traducción de IP de origen y de puerto en esos mensajes.
Si observa el flujo de la comunicación SIP en Expressway-E, puede ver que obtiene el REGISTRO SIP del dispositivo cliente MRA y, a continuación, Expressway-E genera un mensaje de servicio SIP para intercambiar sus certificados con Expressway-C, pero esto da lugar a un tiempo de espera de solicitud 408.

Evidencia en registros de diagnóstico

Observe que el encabezado de ruta de este mensaje de servicio SIP (enviado desde Expressway-E a Expressway-C) contiene la IP y el puerto de la dirección NAT (64.100.0.10:4401).
Cuando este mensaje llega a Expressway-C, Expressway-C intenta rutear el mensaje basándose en ese encabezado de ruta, hacia 64.100.0.10:4401. Esto falla porque no puede hacer una conexión a esta dirección, ya que esta dirección está en el lado del servidor de Expressway-E. Incluso si Expressway-C puede conectarse a esta dirección, no es correcto, ya que el mensaje de servicio SIP está destinado a que Expressway-C reciba y procese. 

El mensaje SIP SERVICE llega 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 intenta enviar este mensaje de servicio SIP sobre lo que muestra en el encabezado de ruta, pero la conexión falla: 

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"

En la captura de paquetes de Expressway-C, el intento TCP SYN obtiene una respuesta RST: 

 El resultado es que Expressway-C envía un tiempo de espera de solicitud 408 hacia 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

Solución

Hay dos soluciones posibles para esta condición.

Inhabilite la traducción del puerto IP de origen en el firewall

Si desactiva la traducción de IP/puerto de origen en el firewall, el servidor de Expressway-E ve el tráfico de Expressway-C como si llegara desde 10.0.30.2:27901 (IP y puerto reales en Expressway-C) en lugar de 64.100.0.10:4401 (dirección NAT). De esta manera, el encabezado de ruta en el mensaje SIP SERVICE contiene el valor 10.0.30.2:27901 y, al recibir este mensaje, Expressway-C lo ruteará a sí mismo y realizará algún procesamiento en él que resultará en un 200 OK para ser enviado de vuelta a Expressway-E (si todo va bien) que luego pasará por el mensaje SIP REGISTER el proceso de registro.

Cambio a una configuración NIC dual

Con una configuración NIC dual en Expressway-E, no es necesario realizar la reflexión NAT y se evita el problema. Sin embargo, asegúrese de que el firewall interno entre Expressway-E y Expressway-C (si está presente) no esté realizando la traducción de IP/puerto de origen del tráfico de Expressway-C a Expressway-E (lo que provocaría problemas similares).

Información Relacionada

• Las implementaciones de red admitidas para Expressway se detallan en el Apéndice 4 de la Guía de Configuración Básica de Expressway
• Siga los detalles de configuración de ASA para configurar las implementaciones de red de Expressway soportadas