Contenido

Introducción

Prerequisites

Componentes Utilizados

Antecedentes

Problema

Diagrama de la red

Detalles

Evidencia en registros de diagnóstico

Solución

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

Cambio a una configuración NIC dual

Información Relacionada

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