Contents

Introduction

Prerequisites

Componentes Utilizados

Informações de Apoio

Problema

Diagrama de Rede

Detalhes

Evidência em registros de diagnóstico

Solução

Desative a conversão da porta IP origem no firewall

Mover para uma configuração de NIC dupla

Informações Relacionadas

Introduction

Este documento descreve como solucionar problemas de falha de serviços de telefone por MRA causados pela conversão de IP de origem por reflexão de NAT, com uma única NIC Expressway-E com configuração de NAT estático.

Prerequisites

A Cisco recomenda que você tenha conhecimento destes tópicos:

- NAT (Network Address Translation, Conversão de endereço de rede)

- SIP (Session Initiation Protocol)

- Configuração básica do Cisco Video Communication Server (VCS) ou Expressway

- Acesso móvel e remoto (MRA) sobre Expressway ou VCS

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Observação: por meio de todo o documento, os dispositivos Expressway são chamados de Expressway-E e Expressway-C. No entanto, a mesma configuração se aplica aos dispositivos VCS (Video Communication Server, servidor de comunicação de vídeo) Expressway e VCS Control.

Informações de Apoio

Este documento aborda um cenário em que o Acesso Móvel e Remoto foi implantado no Expressway com Expressway-E usando uma única placa de rede e endereço NAT estático (descrito como Firewall DMZ de 3 portas usando uma interface de LAN Expressway-E, como descrito no Guia de Configuração Básica do Expressway). Os usuários do MRA podem fazer login com êxito, mas não têm acesso aos serviços telefônicos.

A mensagem SIP REGISTER do cliente externo é recebida pelo Expressway-E com êxito na porta 5061.

O Expressway-E cria uma mensagem de serviço SIP para o Expressway-C. Essa solicitação resulta em um 408 Request Timeout.

Problema

Os serviços de telefone falham porque a mensagem SIP REGISTER não passa pelo Cisco Unified Communications Manager (CUCM ou Call Manager). O Expressway-E e o Expressway-C não podem trocar seus certificados corretamente usando a troca de mensagens SIP SERVICE. As mensagens SIP SERVICE obtêm apenas um 408 Request Timeout como resposta do Expressway-C. Como a mensagem SIP SERVICE não é bem-sucedida, o Expressway-E não encaminha a mensagem SIP REGISTER para o Expressway-C.

Isso é causado pelo fato de o firewall entre o Expressway-C e o Expressway-E não originar a conversão de IP (e porta) para mensagens do Expressway-C para o Expressway-E. Isso resulta no roteamento do Expressway-C dessas mensagens de serviço SIP incorretamente para esse endereço convertido, em vez de seu próprio endereço local. Em um cenário bem-sucedido, o Expressway-C processa a própria mensagem SIP SERVICE. (A mensagem SIP SERVICE entre o Expressway-E e o Expressway-C é usada para verificar certificados e, portanto, só é vista no início de uma configuração de zona de passagem ou no primeiro registro sobre o MRA.)

Diagrama de Rede

A imagem a seguir fornece um exemplo de um diagrama de rede, que é usado como referência neste documento:

Detalhes

Nas capturas de pacotes do Expressway-C, você pode ver que o Expressway-C (10.0.30.2) se conecta com êxito ao endereço IP público estático do NAT do Expressway-E (64.100.0.10) na porta 7003. (Observe que a porta de origem é 27901 no Expressway-C):

Em capturas de pacotes do Expressway-E, você pode ver que a conexão vem de 64.100.0.10 na porta 4401 (que é seu próprio endereço IP público de NAT estático) com o destino 10.0.10.2 e a porta 7003:

Estas são as perspectivas da conexão entre o Expressway-C e 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

Isso indica que o firewall entre o Expressway-C e o Expressway-E está fazendo a conversão de IP de origem e porta nessas mensagens.

Se você observar o fluxo de comunicação SIP no Expressway-E, poderá ver que ele obtém o REGISTRO SIP do dispositivo cliente MRA, então o Expressway-E gera uma mensagem de serviço SIP para trocar seus certificados com o Expressway-C, mas isso resulta em um tempo limite de solicitação de 408.

Evidência em registros de diagnóstico

Observe que o cabeçalho de rota desta mensagem de serviço SIP (enviada do Expressway-E para o Expressway-C) contém o IP e a porta do endereço NAT (64.100.0.10:4401).

Quando essa mensagem chega no Expressway-C, o Expressway-C tenta rotear a mensagem com base nesse cabeçalho de rota, em direção a 64.100.0.10:4401. Isso falha, pois não é possível fazer uma conexão com esse endereço, pois esse endereço está no lado do servidor Expressway-E. Mesmo que o Expressway-C possa se conectar a esse endereço, ele não está correto, pois a mensagem SIP SERVICE destina-se a receber e processar o Expressway-C.

A mensagem SIP SERVICE chega ao 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"

O Expressway-C tenta enviar esta mensagem SIP SERVICE para o que ela mostra no cabeçalho Route, mas a conexão falha:

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"

Na captura de pacotes do Expressway-C, a tentativa de TCP SYN obtém uma resposta RST:

O resultado é que o Expressway-C envia um Tempo Limite de Solicitação 408 para o 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

Solução

Há duas soluções possíveis para essa condição.

Desative a conversão da porta IP origem no firewall

Se você desabilitar a tradução IP/porta origem no firewall, o servidor Expressway-E visualizará o tráfego Expressway-C como chegando de 10.0.30.2:27901 (IP e porta reais no Expressway-C) em vez de 64.100.0.10:4401 (endereço NAT). Dessa forma, o cabeçalho Rota na mensagem SIP SERVICE contém o valor 10.0.30.2:27901 e, ao receber essa mensagem, o Expressway-C o encaminhará para si mesmo e realizará algum processamento nele, resultando em um 200 OK para ser enviado de volta ao Expressway-E (se tudo ficar bem) que irá proxy através do SIP REGISTRO para continuar o processo de registro.

Mover para uma configuração de NIC dupla

Com uma configuração de NIC dupla no Expressway-E, a reflexão de NAT não precisa ser realizada e o problema é evitado. No entanto, certifique-se de que o firewall interno entre o Expressway-E e o Expressway-C (se presente) não esteja fazendo a conversão IP/porta origem do tráfego do Expressway-C para o Expressway-E (o que resultaria em problemas semelhantes).

Informações Relacionadas

- As implantações de rede suportadas para o Expressway estão detalhadas no Apêndice 4 do Guia de Configuração Básica do Expressway

- Siga os detalhes de configuração do ASA para configurar implantações de rede suportadas do Expressway