Contenu

Introduction

Conditions préalables

Components Used

Informations générales

Problème

Diagramme du réseau

Détails

Preuves dans les journaux de diagnostic

Solution

Désactiver la traduction de port IP source sur le pare-feu

Passer à une configuration de carte réseau double

Informations connexes

Introduction

Ce document décrit comment dépanner les pannes de services téléphoniques sur MRA causées par la traduction IP source sur réflexion NAT, avec Expressway-E single-NIC avec configuration NAT statique.

Conditions préalables

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- NAT (Network Address Translation)

- SIP (Session Initiation Protocol)

- Configuration de base de Cisco Video Communication Server (VCS) ou Expressway

- Accès mobile et distant (MRA) sur Expressway ou VCS

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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 votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Remarque : Dans l’ensemble du document, les périphériques Expressway sont appelés Expressway-E et Expressway-C. Cependant, la même configuration s’applique aux périphériques Expressway et VCS Control de Video Communication Server (VCS).

Informations générales

Ce document couvre un scénario dans lequel l’accès mobile et distant a été déployé sur Expressway avec Expressway-E à l’aide d’une seule carte réseau et d’une adresse NAT statique (décrite comme DMZ de pare-feu à 3 ports utilisant une interface LAN Expressway-E unique, comme décrit dans le Guide de configuration de base d’Expressway). Les utilisateurs MRA peuvent se connecter correctement, mais n'ont pas accès aux services téléphoniques.

Le message SIP REGISTER du client externe est reçu par Expressway-E sur le port 5061.

Expressway-E crée ensuite un message SIP SERVICE vers Expressway-C. Cette requête entraîne un délai d’attente de la requête 408.

Problème

Les services téléphoniques échouent car le message SIP REGISTER ne passe pas par Cisco Unified Communications Manager (CUCM ou Call Manager). Expressway-E et Expressway-C ne peuvent pas échanger leurs certificats correctement à l’aide de l’échange de messages SIP SERVICE. Les messages SIP SERVICE obtiennent uniquement un délai d’attente de requête 408 en réponse de l’Expressway-C. Comme le message SIP SERVICE échoue, l’Expressway-E ne transmet pas le message SIP REGISTER à l’Expressway-C.

Ceci est dû au fait que le pare-feu entre Expressway-C et Expressway-E effectue la traduction IP (et port) source des messages de l’Expressway-C vers l’Expressway-E. Cela entraîne le routage incorrect de ces messages SIP SERVICE vers cette adresse traduite, au lieu de sa propre adresse locale. Dans un scénario réussi, l’Expressway-C traite le message SIP SERVICE lui-même. (Le message SIP SERVICE entre Expressway-E et Expressway-C est utilisé pour vérifier les certificats et n’est donc visible qu’au début de la configuration d’une zone de traversée, ou lors de la première inscription sur MRA.)

Diagramme du réseau

L'image suivante fournit un exemple de diagramme de réseau, qui est utilisé comme référence dans ce document :

Détails

À partir des captures de paquets Expressway-C, vous pouvez voir que l’Expressway-C (10.0.30.2) se connecte correctement à l’adresse IP publique NAT statique Expressway-E (64.100.0.10) sur le port 7003. (Notez que le port source est 27901 sur l’Expressway-C) :

Dans les captures de paquets de l’Expressway-E, vous pouvez voir que la connexion provient de 64.100.0.10 sur le port 4401 (qui est sa propre adresse IP publique NAT statique) avec la destination 10.0.10.2 et le port 7003 :

Voici les perspectives de la connexion entre Expressway-C et 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

Cela indique que le pare-feu entre Expressway-C et Expressway-E effectue la traduction IP et de port source sur ces messages.

Si vous regardez le flux de communication SIP sur Expressway-E, vous pouvez voir qu’il obtient le SIP REGISTER du périphérique client MRA, alors Expressway-E génère un message SIP SERVICE pour échanger ses certificats avec Expressway-C, mais cela donne un délai d’attente de requête 408.

Preuves dans les journaux de diagnostic

Notez que l’en-tête de route de ce message SIP SERVICE (envoyé d’Expressway-E à Expressway-C) contient l’adresse IP et le port de l’adresse NAT (64.100.0.10:4401).

Lorsque ce message arrive à l’Expressway-C, Expressway-C tente de router le message en fonction de cet en-tête de route, vers 64.100.0.10:4401. Cette opération échoue car elle ne peut pas établir de connexion à cette adresse, car cette adresse se trouve du côté du serveur Expressway-E. Même si Expressway-C peut se connecter à cette adresse, elle n’est pas correcte car le message SIP SERVICE est destiné à la réception et au traitement d’Expressway-C.

Le message SIP SERVICE arrive à 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 tente d’envoyer ce message SIP SERVICE sur ce qu’il indique dans l’en-tête de route, mais la connexion échoue :

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"

Dans la capture de paquets d’Expressway-C, la tentative SYN TCP obtient une réponse RST :

En conséquence, Expressway-C envoie un délai de requête 408 vers l’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

Solution

Il existe deux solutions possibles à cette situation.

Désactiver la traduction de port IP source sur le pare-feu

Si vous désactivez la traduction IP/port source sur le pare-feu, le serveur Expressway-E voit le trafic Expressway-C comme provenant de 10.0.30.2:27901 (IP et port réels sur l’Expressway-C) au lieu de 64.100.0.10:4401 (adresse NAT). De cette manière, l’en-tête de route du message SIP SERVICE contient la valeur 10.0.30.2:27901 et à réception de ce message, l’Expressway-C le routera vers lui-même et effectuera un certain traitement sur celui-ci, ce qui donne 200 OK à renvoyer à l’Expressway-E (si tout va bien) qui passera ensuite par proxy via le message SIP REGISTER pour poursuivre le processus d'inscription.

Passer à une configuration de carte réseau double

Avec une configuration de carte réseau double sur Expressway-E, il n’est pas nécessaire d’effectuer une réflexion NAT et le problème est évité. Cependant, assurez-vous que le pare-feu interne entre Expressway-E et Expressway-C (s’il est présent) n’effectue pas de traduction IP/port source du trafic entre Expressway-C et Expressway-E (ce qui entraînerait des problèmes similaires).

Informations connexes

- Les déploiements réseau pris en charge pour Expressway sont détaillés dans l’annexe 4 du Guide de configuration de base d’Expressway

- Suivez les détails de la configuration ASA afin de configurer les déploiements réseau Expressway pris en charge