Falha nos serviços telefônicos MRA devido à conversão IP de origem sobre reflexão NAT (configuração de NIC única com NAT estático ativado)

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