Mobiele MRA-telefonie faalt als gevolg van IP-vertaling van bronnen via NAT-reflectie (één NIC-configuratie met statische NAT ingeschakeld)

Inleiding

Dit document beschrijft hoe u problemen kunt oplossen bij het falen van telefoonservices via MRA veroorzaakt door IP-vertaling van bron via NAT-reflectie, met Expressway-E enkele-NIC met Static NAT-configuratie.

Voorwaarden

Cisco raadt kennis van de volgende onderwerpen aan:

• NAT (netwerkadresomzetting)
• SIP (Session Initiation Protocol)
• Cisco Video Communication Server (VCS) of Express-basisconfiguratie
• Mobiele en Remote Access (MRA) via snelweg of VCS

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Opmerking: Via het gehele document worden expressway-apparaten aangeduid als Expressway-E en Expressway-C. Dezelfde configuratie is echter van toepassing op VCS (Video Communication Server)-expressway en VCS-regelapparatuur. 

Achtergrondinformatie

Dit document bestrijkt een schenking waarin mobiele en externe toegang is geïmplementeerd op snelweg met snelweg met snelweg-E door gebruik te maken van één NAT-adres (beschreven als 3-poorts DMZ met firewall-DMZ en één E LAN-interface, zoals beschreven in de Grondconfiguratie van de snelweg). Gebruikers van MRA kunnen met succes inloggen, maar hebben geen toegang tot telefoondiensten.

Het SIP REGISTER-bericht van externe client wordt ontvangen door Expressway-E met succes op poort 5061.
Expressway-E maakt vervolgens een SIP-SERVICEbericht naar Expressway-C. Dit verzoek resulteert in een Time-out voor 408 aanvragen.

Probleem

De telefoonservices falen omdat het SIP REGISTER-bericht niet naar de Cisco Unified Communications Manager (CUCM of Call Manager) gaat. Expressway-E en Expressway-C kunnen hun certificaten niet correct uitwisselen via de SIP SERVICE-berichtuitwisseling. De SIP SERVICE-berichten krijgen alleen een Time-out bij 408 aanvraag als antwoord van de sneltoets C. Aangezien het SIP-SERVICE-bericht niet succesvol is, stuurt de expressway-E het SIP-REGISTER-bericht niet naar de snelweg-C.
Dit wordt veroorzaakt door het feit dat de firewall tussen Expressway-C en Expressway-E IP (en poort)-vertaling levert voor berichten van de Expressway-C naar de Expressway-E. Dit resulteert in het verzenden van die SIP-SERVICEberichten in de expressway-C, onjuist naar dat vertaalde adres, in plaats van zijn eigen lokale adres. In een succesvol scenario, verwerkt de Expressway-C het SIP SERVICE-bericht zelf. (Het SIP SERVICE-bericht tussen expressway-E en Expressway-C wordt gebruikt voor de controle van certificaten en wordt daarom alleen gezien aan het begin van een instelling voor traversale zones, of bij eerste registratie via MRA.)

Netwerkdiagram

Het volgende beeld geeft een voorbeeld van een netwerkdiagram, dat als referentie in dit document wordt gebruikt:

Details

Op basis van de pakketvastlegging Expressway-C kunt u zien dat de Expressway-C (10.0.30.2) met succes verbonden is met het statische NAT-adres (64.100.0.10) van Expressway-E in poort 7003. (Merk op dat de bronpoort 27901 is op de Expressway-C.): 

In pakketopnamen van de snelweg-E kunt u zien dat de verbinding van 64.100.0.10 op poort 4401 (dat zijn eigen statische NAT openbare IP-adres is) komt met bestemming 10.0.10.2 en poort 7003:

Dit zijn de perspectieven van het verband tussen Expressway-C en E:

 autosnelweg C : 10.0.30.2:27901 <-> 64.100.0.10:7003
 E : 64.10.0.10:4401 <-> 10.0.10.2:7003

Dit wijst erop dat de firewall tussen Expressway-C en Expressway-E bron-IP en poortvertaling op die berichten doet.
Als u de stroom van SIP-communicatie op Expressway-E bekijkt, kunt u zien dat het SIP REGISTER krijgt van het MRA-clientapparaat en dan genereert Expressway-E een SIP-SERVICE-bericht om certificaten uit te wisselen met de Expressway-C, maar dit resulteert in een Time-out voor 408 aanvragen.

Bewijs in diagnostische logboek

Merk op dat de routeheader van dit SIP SERVICE-bericht (verzonden van expressway-E naar Expressway-C) het IP en de poort van het NAT-adres bevat (64.10.0.10:4401).
Wanneer dit bericht aankomt bij de Expressway-C probeert Expressway-C het bericht te verzenden dat is gebaseerd op de Routekop naar 64.100.0.10:4401. Dit faalt omdat het geen verbinding met dit adres kan maken, aangezien dit adres aan de kant van de server Expressway-E is. Zelfs als Expressway-C in staat is om verbinding te maken met dit adres, is dit niet correct aangezien het SIP-SERVICE-bericht is bedoeld voor expressway-C om te ontvangen en te verwerken. 

SIP SERVICE-bericht wordt automatisch naar POS-C verzonden:

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 probeert dit SIP SERVICE-bericht te verzenden naar wat in de Routekop wordt weergegeven, maar de verbinding is verbroken: 

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"

In de pakketopname van Expressway-C krijgt de TCP-SYN-poging een RST-respons: 

 Het resultaat is dat Expressway-C een Time-out van 408 aanvragen stuurt naar de 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

Oplossing

Er zijn twee mogelijke oplossingen voor deze aandoening.

Uitschakelen van de bron IP-poortvertaling in de firewall

Als u de bron IP/poorts-vertaling in de firewall uitschakelt, worden de expressway-E-serverbeelden met C-verkeer weergegeven vanaf 10.0.30.2:27901 (werkelijke IP en poort op de expressway-C) in plaats van 64.10.0.10:4401 (NAT-adres). Op deze manier bevat de routekop in het SIP-SERVICE-bericht 10.0.30.2:27901 waarde en na ontvangst van dit bericht zal de sneltoets-C het naar zichzelf leiden en er enige verwerking aan uitvoeren, resulterend in een 200 OK om terug te worden gestuurd naar de expressway-E (indien alles goed gaat), die dan proxy door het SIP-REGISTER-bericht doet het registratieproces voort te zetten .

Naar een dubbele NIC-configuratie verplaatsen

Met een dubbele NIC configuratie op Expressway-E, hoeft NAT-reflectie niet te worden uitgevoerd en wordt het probleem vermeden. Zorg er echter voor dat de interne firewall tussen Expressway-E en Expressway-C (indien aanwezig) niet bestaat in het omzetten van bron-IP/poort van verkeer van Expressway-C naar Expressway-E (wat zou leiden tot soortgelijke problemen).

Gerelateerde informatie

• Ondersteunde netwerkimplementaties voor snelwegen zijn gedetailleerd in aanhangsel 4 van de handleiding voor basisconfiguratie van de snelweg
• Volg de ASA configuratie details om de ondersteunde implementaties van snelwegen te configureren