Fehlerbehebung bei AnyConnect VPN-Telefonen - IP-Telefone, ASA und CUCM

Einleitung

  

In diesem Dokument wird die Fehlerbehebung bei IP-Telefonen beschrieben, die das Secure Sockets Layer (SSL)-Protokoll (Cisco AnyConnect Secure Mobility Client) verwenden, um eine Verbindung zu einer Cisco Adaptive Security Appliance (ASA) herzustellen, die als VPN-Gateway verwendet wird, und um eine Verbindung zu einem Cisco Unified Communications Manager (CUCM) herzustellen, der als Sprachserver verwendet wird.

  

Konfigurationsbeispiele für AnyConnect mit VPN-Telefonen finden Sie in den folgenden Dokumenten:

  

• SSL VPN mit IP-Telefonen - Konfigurationsbeispiel
  
  
• AnyConnect VPN-Telefon mit Konfigurationsbeispiel für die Zertifikatsauthentifizierung

  

Hintergrundinformationen

  

Bevor Sie SSL VPN mit IP-Telefonen bereitstellen, müssen Sie sicherstellen, dass Sie die anfänglichen Anforderungen für AnyConnect-Lizenzen für die ASA und für die US-Exportversion von CUCM erfüllen.

  

VPN-Telefonlizenz auf ASA bestätigen

  

Die VPN-Telefonlizenz aktiviert die Funktion in der ASA. Um die Anzahl der Benutzer zu überprüfen, die sich mit dem AnyConnect verbinden können (unabhängig davon, ob es sich um ein IP-Telefon handelt), überprüfen Sie die AnyConnect Premium SSL-Lizenz. Weitere Informationen finden Sie unter Welche ASA-Lizenz ist für IP-Telefon- und mobile VPN-Verbindungen erforderlich?.

  

Verwenden Sie auf der ASA den Befehl show version, um zu überprüfen, ob die Funktion aktiviert ist. Der Lizenzname unterscheidet sich von der ASA-Version:

  

• ASA Version 8.0.x: Der Lizenzname lautet AnyConnect für Linksys Phone.
  
  
• ASA Version 8.2.x und höher: Der Lizenzname lautet AnyConnect für Cisco VPN Phone.

  

Hier ist ein Beispiel für ASA Version 8.0.x:

  

ASA5505(config)# show ver

Cisco Adaptive Security Appliance Software Version 8.0(5)
Device Manager Version 7.0(2)
<snip>
Licensed features for this platform:
VPN Peers                    : 10
WebVPN Peers                 : 2
AnyConnect for Linksys phone : Disabled
<snip>
This platform has a Base license.

  

Hier ein Beispiel für ASA 8.2.x und höher:

  

ASA5520-C(config)# show ver

Cisco Adaptive Security Appliance Software Version 9.1(1)
Device Manager Version 7.1(1)
<snip>
Licensed features for this platform:
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Disabled       perpetual
AnyConnect for Cisco VPN Phone    : Disabled       perpetual
<snip>
This platform has an ASA 5520 VPN Plus license.

  

Export eingeschränkt und Export uneingeschränkt CUCM

  

Sie sollten eine auf den US-Export beschränkte Version von CUCM für die VPN-Telefonfunktion bereitstellen.

  

Wenn Sie eine uneingeschränkte US-Exportversion von CUCM verwenden, beachten Sie Folgendes:

  

• Die Sicherheitskonfigurationen von IP-Telefonen werden geändert, um die Signalisierung und Medienverschlüsselung zu deaktivieren. Dazu gehört auch die Verschlüsselung durch die VPN-Telefonfunktion.
  
  
• VPN-Details können nicht über Import/Export exportiert werden.
  
  
• Die Kontrollkästchen für VPN-Profil, VPN-Gateway, VPN-Gruppe und VPN-Funktionskonfiguration werden nicht angezeigt.

  

Hinweis: Nach dem Upgrade auf die uneingeschränkte US-Exportversion von CUCM können Sie kein Upgrade auf die eingeschränkte US-Exportversion dieser Software durchführen oder eine Neuinstallation durchführen.

  

Häufige Probleme bei der ASA

  

Hinweis: Sie können den Cisco CLI Analyzer (nur für registrierte Kunden) verwenden, um eine Analyse der show-Befehlsausgaben anzuzeigen. Bevor Sie Debug-Befehle verwenden, sollten Sie auch das Dokument Important Information on Debug Commands Cisco (Wichtige Informationen zu Debug-Befehlen) lesen.

  

Zertifikate zur Verwendung auf der ASA

  

Auf der ASA können Sie selbstsignierte SSL-Zertifikate, SSL-Zertifikate von Drittanbietern und Platzhalterzertifikate verwenden, die die Kommunikation zwischen dem IP-Telefon und der ASA sicherstellen.

  

Es kann nur ein Identitätszertifikat verwendet werden, da jeder Schnittstelle nur ein Zertifikat zugewiesen werden kann.

  

Installieren Sie für SSL-Zertifikate von Drittanbietern die vollständige Kette in der ASA, und schließen Sie alle Zwischen- und Stammzertifikate ein.

  

Vertrauenspunkt/Zertifikat für ASA-Export und CUCM-Import

  

Das Zertifikat, das die ASA dem IP-Telefon während der SSL-Aushandlung vorlegt, muss von der ASA exportiert und in den CUCM importiert werden. Überprüfen Sie den Vertrauenspunkt, der der Schnittstelle zugewiesen ist, mit der die IP-Telefone verbunden sind, um zu erfahren, welches Zertifikat von der ASA exportiert werden soll.

  

Verwenden Sie den Befehl show run ssl, um den zu exportierenden Vertrauenspunkt (Zertifikat) zu überprüfen. Weitere Informationen finden Sie unter AnyConnect VPN-Telefon mit Konfigurationsbeispiel für die Zertifikatsauthentifizierung.

  

Hinweis: Wenn Sie ein Zertifikat eines Drittanbieters für eine oder mehrere ASAs bereitgestellt haben, müssen Sie jedes Identitätszertifikat von jeder ASA exportieren und dann als phone-vpn-trust in den CUCM importieren.

  

ASA präsentiert selbstsigniertes ECDSA-Zertifikat anstelle des konfigurierten RSA-Zertifikats

  

Wenn dieses Problem auftritt, können neuere Telefonmodelle keine Verbindung herstellen, während bei älteren Telefonmodellen keine Probleme auftreten. Hier sind die Protokolle auf dem Telefon, wenn dieses Problem auftritt:

  

VPNC: -protocol_handler: SSL dpd 30 sec from SG (enabled)
VPNC: -protocol_handler: connect: do_dtls_connect
VPNC: -do_dtls_connect: udp_connect
VPNC: -udp_connect: getsockname failed
VPNC: -udp_connect: binding sock to eth0 IP 63.85.30.39
VPNC: -udp_connect: getsockname failed
VPNC: -udp_connect: connecting to 63.85.30.34:443
VPNC: -udp_connect: connected to 63.85.30.34:443
VPNC: -do_dtls_connect: create_dtls_connection
VPNC: -create_dtls_connection: cipher list: AES256-SHA
VPNC: -create_dtls_connection: calling SSL_connect in non-block mode
VPNC: -dtls_state_cb: DTLS: SSL_connect: before/connect initialization
VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 write client hello A
VPNC: -dtls_state_cb: DTLS: SSL_connect: DTLS1 read hello verify request A
VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 write client hello A
VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 flush data
VPNC: -dtls_state_cb: DTLS: write: alert: fatal:illegal parameter
VPNC: -vpnc_set_notify_netsd : cmd: 0x5 event: 0x40000 status: 0x0 error: 0x0 
VPNC: -alert_err: DTLS write alert: code 47, illegal parameter
VPNC: -create_dtls_connection: SSL_connect ret -1, error 1
VPNC: -DTLS: SSL_connect: SSL_ERROR_SSL (error 1)
VPNC: -DTLS: SSL_connect: error:140920C5:SSL routines:SSL3_GET_SERVER_HELLO:
 old session cipher not returned
VPNC: -create_dtls_connection: DTLS setup failure, cleanup
VPNC: -do_dtls_connect: create_dtls_connection failed
VPNC: -protocol_handler: connect: do_dtls_connect failed
VPNC: -protocol_handler: connect : err: SSL success DTLS fail

  

In Version 9.4.1 und höher wird die Verschlüsselung elliptischer Kurven für SSL/TLS unterstützt. Wenn ein SSL VPN-Client, der eine elliptische Kurve unterstützt (z. B. ein neues Telefonmodell), eine Verbindung mit der ASA herstellt, wird die Chiffriersuite für elliptische Kurven ausgehandelt, und die ASA stellt dem SSL VPN-Client ein Zertifikat für eine elliptische Kurve zur Verfügung, auch wenn die entsprechende Schnittstelle mit einem RSA-basierten Vertrauenspunkt konfiguriert ist. Um zu verhindern, dass die ASA ein selbstsigniertes SSL-Zertifikat präsentiert, muss der Administrator die Verschlüsselungssuiten entfernen, die über den Befehl ssl cipher korrespondieren. Bei einer Schnittstelle, die mit einem RSA-Vertrauenspunkt konfiguriert ist, kann der Administrator diesen Befehl ausführen, sodass nur RSA-basierte Chiffren ausgehandelt werden:

  

ssl cipher tlsv1.2 custom "AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA"

  

Bei der Implementierung der Cisco Bug-ID CSCuu02848 wird der Konfiguration Priorität eingeräumt. Explizit konfigurierte Zertifikate werden immer verwendet. Selbstsignierte Zertifikate werden nur verwendet, wenn kein konfiguriertes Zertifikat vorhanden ist.

  

Client-Verschlüsselung	RSA-Zertifikat	Nur EC-Zertifikat	Beide Zertifikate	None
Nur RSA-Verschlüsselungen	Verwendet RSA-Zertifikat Verwendet RSA-Verschlüsselungen	Selbstsigniertes RSA-Zertifikat Verwendet RSA-Verschlüsselungen	Verwendet RSA-Zertifikat Verwendet RSA-Verschlüsselungen	Selbstsigniertes RSA-Zertifikat Verwendet RSA-Verschlüsselungen
Nur EC-Chiffren (selten)	Verbindung schlägt fehl	Verwendet EC-Zertifikat Verwendet EC-Chiffren	Verwendet EC-Zertifikat Verwendet EC-Chiffren	Selbstsigniertes EG-Zertifikat Verwendet EC-Chiffren
Nur beide Chiffren	Verwendet RSA-Zertifikat Verwendet RSA-Verschlüsselungen	Verwendet EC-Zertifikat Verwendet EC-Chiffren	Verwendet EC-Zertifikat Verwendet EC-Chiffren	Selbstsigniertes EG-Zertifikat Verwendet EC-Chiffren

  

Externe Datenbank zur Authentifizierung von IP-Telefonbenutzern

  

Sie können eine externe Datenbank verwenden, um IP-Telefonbenutzer zu authentifizieren. Protokolle wie das Lightweight Directory Access Protocol (LDAP) oder der Remote Authentication Dial In User Service (RADIUS) können zur Authentifizierung von VPN-Telefonbenutzern verwendet werden.

  

Zertifikats-Hash-Übereinstimmung zwischen ASA-Zertifikat und VPN-Telefonvertrauensliste

  

Denken Sie daran, dass Sie das der ASA SSL-Schnittstelle zugewiesene Zertifikat herunterladen und als Phone-VPN-Trust Certificate in den CUCM hochladen müssen. Unterschiedliche Umstände können dazu führen, dass der Hash für dieses von der ASA bereitgestellte Zertifikat nicht mit dem vom CUCM-Server generierten Hash übereinstimmt, der über die Konfigurationsdatei an das VPN-Telefon übertragen wird.

  

Nachdem die Konfiguration abgeschlossen ist, testen Sie die VPN-Verbindung zwischen dem IP-Telefon und der ASA. Wenn die Verbindung weiterhin fehlschlägt, überprüfen Sie, ob der Hash des ASA-Zertifikats mit dem Hash übereinstimmt, den das IP-Telefon erwartet:

  

1. Überprüfen Sie den von der ASA präsentierten Secure Hash Algorithm 1 (SHA1)-Hash.
   
   
2. Verwenden Sie TFTP, um die Konfigurationsdatei für das IP-Telefon vom CUCM herunterzuladen.
   
   
3. Decodieren Sie den Hash von hexadezimal auf Basis 64 oder von Basis 64 auf hexadezimal.

  

SHA1-Hash überprüfen

  

Die ASA präsentiert das Zertifikat, das mit dem ssl trustpoint-Befehl auf der Schnittstelle angewendet wurde, mit der das IP-Telefon verbunden wird. Um dieses Zertifikat zu überprüfen, öffnen Sie den Browser (in diesem Beispiel Firefox), und geben Sie die URL (group-url) ein, mit der die Telefone verbunden werden sollen:

  

  

IP-Telefon-Konfigurationsdatei herunterladen

  

Laden Sie von einem PC mit direktem Zugriff auf den CUCM die TFTP-Konfigurationsdatei für das Telefon mit Verbindungsproblemen herunter. Zwei Downloadmethoden sind:

  

1. Öffnen Sie eine CLI-Sitzung in Windows, und verwenden Sie den Befehl tftp -i <TFTP-Server> GET SEP<Phone Mac Address>.cnf.xml.
   

   Hinweis: Wenn Sie einen Fehler erhalten, der dem unten angezeigten ähnelt, sollten Sie sicherstellen, dass die TFTP-Client-Funktion aktiviert ist.

   
   
   
   
   
2. Verwenden Sie eine Anwendung wie Tftpd32, um die Datei herunterzuladen:
   
   
   
   
3. Sobald die Datei heruntergeladen wurde, öffnen Sie das XML, und suchen Sie nach der vpnGroup-Konfiguration. Dieses Beispiel zeigt den zu überprüfenden Abschnitt und den certHash:
   
   

   <vpnGroup>
   <mtu>1290</mtu>
   <failConnectTime>30</failConnectTime>
   <authMethod>2</authMethod>
   <pswdPersistent>0</pswdPersistent>
   <autoNetDetect>0</autoNetDetect>
   <enableHostIDCheck>0</enableHostIDCheck>
   <addresses>
   <url1>https://10.198.16.140/VPNPhone</url1>
   </addresses>
   <credentials>
   <hashAlg>0</hashAlg>
   
            
            
              5X6B6plUwUSXZnjQ4kGM33mpMXY= 
            
   </credentials>
   </vpnGroup>

  

Decodierung des Hashs

  

Bestätigen Sie, dass beide Hashwerte übereinstimmen. Der Browser stellt den Hash im hexadezimalen Format dar, während die XML-Datei das Basisformat 64 verwendet. Konvertieren Sie also ein Format in das andere, um die Übereinstimmung zu bestätigen. Es stehen viele Übersetzer zur Verfügung; ein Beispiel ist der ÜBERSETZER, BINARY .

  

  

Hinweis: Wenn der vorherige Hash-Wert nicht übereinstimmt, vertraut das VPN-Telefon der mit der ASA ausgehandelten Verbindung nicht, und die Verbindung schlägt fehl.

  

VPN-Lastenausgleich und IP-Telefone

  

Für VPN-Telefone wird kein SSL VPN mit Lastausgleich unterstützt. VPN-Telefone führen keine echte Zertifikatsvalidierung durch, sondern verwenden stattdessen vom CUCM nach unten geschobene Hashes zur Validierung der Server. Da es sich beim VPN-Lastenausgleich im Wesentlichen um eine HTTP-Umleitung handelt, müssen die Telefone mehrere Zertifikate validieren, was zu Fehlern führt. Symptome eines VPN-Lastverteilungsfehlers:

  

• Das Telefon wechselt zwischen den Servern und benötigt außergewöhnlich lange, um eine Verbindung herzustellen, oder fällt irgendwann aus.
  
  
• Die Telefonprotokolle enthalten folgende Meldungen:
  
  

  909: NOT 20:59:50.051721 VPNC: do_login: got login response
  910: NOT 20:59:50.052581 VPNC: process_login: HTTP/1.0 302 Temporary moved
  911: NOT 20:59:50.053221 VPNC: process_login: login code: 302 (redirected)
  912: NOT 20:59:50.053823 VPNC: process_login: redirection indicated
  913: NOT 20:59:50.054441 VPNC: process_login: new 'Location': 
     /+webvpn+/index.html
  914: NOT 20:59:50.055141 VPNC: set_redirect_url: new URL 
     <https://xyz1.abc.com:443/+webvpn+/index.html>

  

CSD und IP-Telefone

  

Derzeit unterstützen IP-Telefone den Cisco Secure Desktop (CSD) nicht und stellen keine Verbindung her, wenn der CSD für Tunnelgruppen oder global in der ASA aktiviert ist.

  

Überprüfen Sie zunächst, ob auf der ASA die CSD aktiviert ist. Geben Sie den Befehl show run webvpn in die ASA-CLI ein:

  

ASA5510-F# show run webvpn
webvpn
 enable outside
 csd image disk0:/csd_3.6.6210-k9.pkg
csd enable
 anyconnect image disk0:/anyconnect-win-3.1.00495-k9.pkg 1
 anyconnect enable
ASA5510-F#

  

Um CSD-Probleme während einer IP-Telefonverbindung zu überprüfen, überprüfen Sie die Protokolle oder Fehlerbehebungen in der ASA.

  

ASA-Protokolle

  

%ASA-4-724002: Group <VPNPhone> User <Phone> IP <172.6.250.9> WebVPN session not 
   terminated. Cisco Secure Desktop was not running on the client's workstation.

ASA-Fehlersuche

  

debug webvpn anyconnect 255
<snip>
Tunnel Group: VPNPhone, Client Cert Auth Success.
WebVPN: CSD data not sent from client
http_remove_auth_handle(): handle 24 not found!
<snip>

  

Hinweis: Bei großen Bereitstellungen mit einer hohen Anzahl an AnyConnect-Benutzern empfiehlt Cisco, dass Sie debug webvpn anyconnect nicht aktivieren. Die Ausgabe kann nicht nach IP-Adresse gefiltert werden, sodass eine große Informationsmenge erzeugt werden kann.

  

In ASA Version 8.2 und höher müssen Sie den Befehl without-csd unter den webvpn-Attributen der Tunnelgruppe anwenden:

  

tunnel-group VPNPhone webvpn-attributes
 authentication certificate
 group-url https://asa5520-c.cisco.com/VPNPhone enable
 without-csd

  

In früheren Versionen der ASA war dies nicht möglich. Die einzige Problemumgehung bestand daher darin, den CSD global zu deaktivieren.

  

Im Cisco Adaptive Security Device Manager (ASDM) können Sie den CSD für ein bestimmtes Verbindungsprofil deaktivieren, wie in diesem Beispiel gezeigt:

  

  

Hinweis: Verwenden Sie eine Gruppen-URL, um die CSD-Funktion zu deaktivieren.

  

DAP-Regeln

  

In den meisten Bereitstellungen werden IP-Telefone nicht nur mit der ASA verbunden, sondern auch verschiedene Gerätetypen (Microsoft, Linux, Mac OS) und Mobilgeräte (Android, iOS). Aus diesem Grund ist es normal, eine vorhandene Konfiguration von Dynamic Access Policy (DAP)-Regeln zu finden, wobei die Standardaktion unter der DfltAccessPolicy in den meisten Fällen die Beendigung der Verbindung ist.

  

In diesem Fall erstellen Sie eine separate DAP-Regel für die VPN-Telefone. Verwenden Sie einen bestimmten Parameter, z. B. das Verbindungsprofil, und legen Sie die Aktion auf Weiter fest:

  

  

Wenn Sie keine bestimmte DAP-Richtlinie für IP-Telefone erstellen, zeigt die ASA einen Treffer unter der DfltAccessPolicy und eine fehlgeschlagene Verbindung an:

  

%ASA-6-716038: Group <DfltGrpPolicy> User <CP-7962G-SEP8CB64F576113> IP 
   <172.16.250.9> Authentication: successful, Session Type: WebVPN.
%ASA-7-734003: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9: Session 
   Attribute aaa.cisco.grouppolicy = GroupPolicy_VPNPhone
<snip>
%ASA-6-734001: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9, 
   Connection AnyConnect: The following DAP records were selected for this 
   connection: DfltAccessPolicy
%ASA-5-734002: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9: Connection 
   terminated by the following DAP records: DfltAccessPolicy

  

Wenn Sie eine bestimmte DAP-Richtlinie für die IP-Telefone mit der Aktion "Continue" (Weiter) erstellt haben, können Sie eine Verbindung herstellen mit:

  

%ASA-7-746012: user-identity: Add IP-User mapping 10.10.10.10 - 
   LOCAL\CP-7962G-SEP8CB64F576113 Succeeded - VPN user
%ASA-4-722051: Group <GroupPolicy_VPNPhone> User <CP-7962G-SEP8CB64F576113> IP 
   <172.16.250.9> Address <10.10.10.10> assigned to session
%ASA-6-734001: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9, Connection 
   AnyConnect: The following DAP records were selected for this connection: VPNPhone

  

Ererbte Werte von DfltGrpPolicy oder anderen Gruppen

  

In vielen Fällen wird die DfltGrpPolicy mit mehreren Optionen eingerichtet. Diese Einstellungen werden standardmäßig für die IP-Telefonsitzung übernommen, es sei denn, sie werden manuell in der Gruppenrichtlinie festgelegt, die vom IP-Telefon verwendet werden soll.

  

Einige Parameter, die sich auf die Verbindung auswirken können, wenn sie von der DfltGrpPolicy geerbt werden, sind:

  

• Gruppensperre
  
  
• VPN-Tunnelprotokoll
  
  
• VPN-gleichzeitige Anmeldungen
  
  
• VPN-Filter

  

Angenommen, Sie haben diese Beispielkonfiguration in der DfltGrpPolicy und dem GroupPolicy_VPNPhone:

  

group-policy DfltGrpPolicy attributes
 vpn-simultaneous-logins 0
 vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-clientless
 group-lock value DefaultWEBVPNGroup
 vpn-filter value NO-TRAFFIC

group-policy GroupPolicy_VPNPhone attributes
 wins-server none
 dns-server value 10.198.29.20
 default-domain value cisco.com

  

Die Verbindung erbt die Parameter der DfltGrpPolicy, die nicht explizit unter GroupPolicy_VPNPhone angegeben wurden, und überträgt alle Informationen während der Verbindung an das IP-Telefon.

  

Um dies zu vermeiden, geben Sie die Werte, die Sie direkt in der Gruppe benötigen, manuell an:

  

group-policy GroupPolicy_VPNPhone internal
group-policy GroupPolicy_VPNPhone attributes
 wins-server none
 dns-server value 10.198.29.20
 vpn-simultaneous-logins 3
 vpn-tunnel-protocol ssl-client
 group-lock value VPNPhone
 vpn-filter none
 default-domain value cisco.com

  

Um die Standardwerte von DfltGrpPolicy zu überprüfen, verwenden Sie den Befehl show run all group-policy. In diesem Beispiel wird der Unterschied zwischen den Ausgaben verdeutlicht:

  

ASA5510-F# show run group-policy DfltGrpPolicy
group-policy DfltGrpPolicy attributes
 dns-server value 10.198.29.20 10.198.29.21
 vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless
 default-domain value cisco.com
ASA5510-F#


ASA5510-F# sh run all group-policy DfltGrpPolicy
group-policy DfltGrpPolicy internal
group-policy DfltGrpPolicy attributes
 banner none
 wins-server none
 dns-server value 10.198.29.20 10.198.29.21
 dhcp-network-scope none
 vpn-access-hours none
 vpn-simultaneous-logins 3
 vpn-idle-timeout 30
 vpn-idle-timeout alert-interval 1
 vpn-session-timeout none
 vpn-session-timeout alert-interval 1
 vpn-filter none
 ipv6-vpn-filter none
 vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless

  

Die Ausgabe der Gruppenrichtlinien-Inherit-Attribute über den ASDM lautet wie folgt:

  

  

Unterstützte Verschlüsselungschiffren

  

Ein AnyConnect VPN-Telefon, das mit dem IP-Telefon 7962G und der Firmware Version 9.1.1 getestet wurde, unterstützt nur zwei Chiffren, die beide Advanced Encryption Standard (AES) sind: AES256-SHA und AES128-SHA. Wenn die richtigen Chiffren nicht im ASA-Gerät angegeben sind, wird die Verbindung abgelehnt, wie im ASA-Protokoll angezeigt:

  

%ASA-7-725010: Device supports the following 2 cipher(s).
%ASA-7-725011: Cipher[1] : RC4-SHA
%ASA-7-725011: Cipher[2] : DES-CBC3-SHA
%ASA-7-725008: SSL client outside:172.16.250.9/52684 proposes the following 
   2 cipher(s).
%ASA-7-725011: Cipher[1] : AES256-SHA
%ASA-7-725011: Cipher[2] : AES128-SHA
%ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_HELLO Reason: no 
   shared cipher

  

Um zu überprüfen, ob auf der ASA die richtigen Chiffren aktiviert sind, geben Sie die Befehle show run all ssl und show ssl ein:

  

ASA5510-F# show run all ssl
ssl server-version any
ssl client-version any
ssl encryption rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1
ssl trust-point SSL outside
ASA5510-F#

ASA5510-F# show ssl
Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1
Start connections using SSLv3 and negotiate to SSLv3 or TLSv1
Enabled cipher order: rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1
Disabled ciphers: des-sha1 rc4-md5 dhe-aes128-sha1 dhe-aes256-sha1 null-sha1
SSL trust-points:
  outside interface: SSL
Certificate authentication is not enabled
ASA5510-F#

  

Häufige Probleme in CUCM

  

VPN-Einstellungen werden nicht auf IP-Telefon angewendet

  

Wenden Sie nach dem Erstellen der Konfiguration auf dem CUCM (Gateway, Gruppe und Profil) die VPN-Einstellungen im allgemeinen Telefonprofil an:

  

1. Navigieren Sie zu Gerät > Geräteeinstellungen > Allgemeines Telefonprofil.
   
   
   
   
2. Geben Sie die VPN-Informationen ein:
   
   
   
   
3. Navigieren Sie zu Gerät > Telefon, und stellen Sie sicher, dass dieses Profil der Telefonkonfiguration zugewiesen ist:
   
   

  

Authentifizierungsmethode des Zertifikats

  

Es gibt zwei Möglichkeiten, die Zertifikatauthentifizierung für IP-Telefone zu konfigurieren: MIC (Manufacturer Installed Certificate) und LSC (Locally Significant Certificate). Unter AnyConnect VPN Phone with Certificate Authentication Configuration Example finden Sie die für Ihre Situation am besten geeignete Option.

  

Wenn Sie die Zertifikatsauthentifizierung konfigurieren, exportieren Sie die Zertifikate (Root CA) vom CUCM-Server und importieren Sie sie in die ASA:

  

1. Melden Sie sich beim CUCM an.
   
   
2. Navigieren Sie zu Unified OS Administration > Security > Certificate Management.
   
   
3. Suchen Sie nach der CAPF (Certificate Authority Proxy Function) oder der Cisco_Manufacturing_CA. Der Zertifikatstyp hängt davon ab, ob Sie die MIC- oder LSC-Zertifikatauthentifizierung verwendet haben.
   
   
4. Laden Sie die Datei auf den lokalen Computer.

  

Melden Sie sich nach dem Herunterladen der Dateien über die CLI oder den ASDM bei der ASA an, und importieren Sie das Zertifikat als Zertifizierungsstellenzertifikat.

  

  

Standardmäßig sind alle Telefone, die VPN unterstützen, mit MICs vorinstalliert. Die Modelle 7960 und 7940 enthalten kein MIC und erfordern einen speziellen Installationsvorgang, damit das LSC sicher registriert wird.

  

Die neuesten Cisco IP-Telefone (8811, 8841, 8851 und 8861) enthalten MIC-Zertifikate, die von der neuen Manufacturing SHA2 CA unterzeichnet wurden:

  

• Die CUCM-Version 10.5(1) enthält die neuen SHA2-Zertifikate und vertraut ihnen.
  
  
• Wenn Sie eine frühere CUCM-Version ausführen, müssen Sie möglicherweise das neue Fertigungszertifizierungsstellenzertifikat herunterladen und:
  
  
  • Laden Sie sie in die CAPF-trust-Klasse hoch, sodass sich die Telefone mit CAPF authentifizieren können, um ein LSC zu erhalten.
    
    
  • Laden Sie sie in CallManager-trust hoch, wenn Sie möchten, dass sich die Telefone mit einem MIC für SIP 5061 authentifizieren.
    
    

Tipp: Klicken Sie auf diesen Link, um die SHA2-Zertifizierungsstelle abzurufen, wenn auf dem CUCM derzeit eine frühere Version ausgeführt wird.

  

Vorsicht: Cisco empfiehlt, MICs nur für die LSC-Installation zu verwenden. Cisco unterstützt LSCs zur Authentifizierung der TLS-Verbindung mit dem CUCM. Da die MIC-Root-Zertifikate kompromittiert werden können, gehen Kunden, die Telefone für die Verwendung von MICs für die TLS-Authentifizierung oder einen anderen Zweck konfigurieren, dies auf eigenes Risiko. Cisco übernimmt keine Haftung, wenn die MICs gefährdet sind.

  

Wenn auf dem Telefon ein LSC vorhanden ist, wird bei der Authentifizierung standardmäßig das LSC verwendet, unabhängig davon, ob auf dem Telefon ein MIC vorhanden ist. Wenn ein MIC und ein LSC im Telefon vorhanden sind, wird für die Authentifizierung das LSC verwendet. Wenn auf dem Telefon kein LSC, aber ein MIC vorhanden ist, wird bei der Authentifizierung das MIC verwendet.

  

Hinweis: Denken Sie daran, dass Sie für die Zertifikatsauthentifizierung das SSL-Zertifikat von der ASA exportieren und in den CUCM importieren sollten.

  

Host-ID-Prüfung

  

Wenn der allgemeine Name (CN) im Betreff des Zertifikats nicht mit der URL (Gruppen-URL) übereinstimmt, die die Telefone für die Verbindung mit dem ASA über das VPN verwenden, deaktivieren Sie die Host-ID-Überprüfung auf dem CUCM, oder verwenden Sie ein Zertifikat auf dem ASA, das mit der URL auf dem ASA übereinstimmt.

  

Dies ist erforderlich, wenn das SSL-Zertifikat der ASA ein Platzhalterzertifikat ist, das SSL-Zertifikat ein anderes SAN enthält (Subject Alternative Name) oder die URL mit der IP-Adresse anstelle des vollqualifizierten Domänennamens (Fully Qualified Domain Name, FQDN) erstellt wurde.

  

Dies ist ein Beispiel für ein IP-Telefonprotokoll, wenn die CN des Zertifikats nicht mit der URL übereinstimmt, die das Telefon erreichen möchte.

  

1231: NOT 07:07:32.445560 VPNC: DNS has wildcard, starting checks...
1232: ERR 07:07:32.446239 VPNC: Generic third level wildcards are not allowed, 
   stopping checks on host=(test.vpn.com) and dns=(*.vpn.com)
1233: NOT 07:07:32.446993 VPNC: hostID not found in subjectAltNames
1234: NOT 07:07:32.447703 VPNC: hostID not found in subject name
1235: ERR 07:07:32.448306 VPNC: hostIDCheck failed!!

  

Um die Überprüfung der Host-ID im CUCM zu deaktivieren, navigieren Sie zu Advanced Features > VPN > VPN Profile:

  

  

Zusätzliche Fehlerbehebung

  

Protokolle und Fehlerbehebungen auf der ASA

  

Auf der ASA können Sie die folgenden Debug- und Protokollfunktionen zur Fehlerbehebung aktivieren:

  

logging enable
logging buffer-size 1048576
logging buffered debugging

debug webvpn anyconnect 255

  

Hinweis: Bei großen Bereitstellungen mit einer großen Anzahl an AnyConnect-Benutzern empfiehlt Cisco, dass Sie das debug webvpnh anyconnect-Ereignis nicht aktivieren. Die Ausgabe kann nicht nach IP-Adresse gefiltert werden, sodass eine große Informationsmenge erzeugt werden kann.

  

IP-Telefon-Protokolle

  

Um auf die Telefonprotokolle zuzugreifen, aktivieren Sie die Webzugriffsfunktion. Melden Sie sich beim CUCM an, und navigieren Sie zu Device > Phone > Phone Configuration. Suchen Sie das IP-Telefon, auf dem Sie diese Funktion aktivieren möchten, und suchen Sie den Abschnitt für Webzugriff. Wenden Sie die Konfigurationsänderungen auf das IP-Telefon an:

  

  

Sobald Sie den Dienst aktivieren und das Telefon zurücksetzen, um diese neue Funktion einzufügen, können Sie im Browser auf IP-Telefonprotokolle zugreifen. Verwenden Sie die IP-Adresse des Telefons von einem Computer mit Zugriff auf dieses Subnetz. Rufen Sie die Konsolenprotokolle auf, und überprüfen Sie die fünf Protokolldateien. Da das Telefon die fünf Dateien überschreibt, müssen Sie alle diese Dateien überprüfen, um die gesuchten Informationen zu finden.

  

  

Korrelierte Probleme zwischen ASA-Protokollen und IP-Telefon-Protokollen

  

Dies ist ein Beispiel für die Korrelation der Protokolle von ASA und IP-Telefon. In diesem Beispiel stimmt der Hash des Zertifikats auf der ASA nicht mit dem Hash des Zertifikats in der Konfigurationsdatei des Telefons überein, da das Zertifikat auf der ASA durch ein anderes Zertifikat ersetzt wurde.

  

ASA-Protokolle

  

%ASA-7-725012: Device chooses cipher : AES128-SHA for the SSL session with 
   client outside:172.16.250.9/50091
%ASA-7-725014: SSL lib error. Function: SSL3_READ_BYTES Reason: tlsv1 alert 
   unknown ca
%ASA-6-725006: Device failed SSL handshake with client outside:172.16.250.9/50091

  

Telefonprotokolle

  

 902: NOT 10:19:27.155936 VPNC: ssl_state_cb: TLSv1: SSL_connect: before/connect 
   initialization
 903: NOT 10:19:27.162212 VPNC: ssl_state_cb: TLSv1: SSL_connect: unknown state
 904: NOT 10:19:27.361610 VPNC: ssl_state_cb: TLSv1: SSL_connect: SSLv3 read 
   server hello A
 905: NOT 10:19:27.364687 VPNC: cert_vfy_cb: depth:1 of 1, subject:
    </CN=10.198.16.140/unstructuredName=10.198.16.140>
 906: NOT 10:19:27.365344 VPNC: cert_vfy_cb: depth:1 of 1, pre_err: 18 (self 
   signed certificate)
 907: NOT 10:19:27.368304 VPNC: cert_vfy_cb: peer cert saved: /tmp/leaf.crt
 908: NOT 10:19:27.375718 SECD: Leaf cert hash = 
   1289B8A7AA9FFD84865E38939F3466A61B5608FC
 909: ERR 10:19:27.376752 SECD: EROR:secLoadFile: file not found </tmp/issuer.crt>
 910: ERR 10:19:27.377361 SECD: Unable to open file /tmp/issuer.crt
 911: ERR 10:19:27.420205 VPNC: VPN cert chain verification failed, issuer 
   certificate not found and leaf not trusted
 912: ERR 10:19:27.421467 VPNC: ssl_state_cb: TLSv1: write: alert: fatal:
   unknown CA
 913: ERR 10:19:27.422295 VPNC: alert_err: SSL write alert: code 48, unknown CA
 914: ERR 10:19:27.423201 VPNC: create_ssl_connection: SSL_connect ret -1 error 1
 915: ERR 10:19:27.423820 VPNC: SSL: SSL_connect: SSL_ERROR_SSL (error 1)
 916: ERR 10:19:27.424541 VPNC: SSL: SSL_connect: error:14090086:SSL 
    routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
 917: ERR 10:19:27.425156 VPNC: create_ssl_connection: SSL setup failure
 918: ERR 10:19:27.426473 VPNC: do_login: create_ssl_connection failed
 919: NOT 10:19:27.427334 VPNC: vpn_stop: de-activating vpn
 920: NOT 10:19:27.428156 VPNC: vpn_set_auto: auto -> auto
 921: NOT 10:19:27.428653 VPNC: vpn_set_active: activated -> de-activated
 922: NOT 10:19:27.429187 VPNC: set_login_state: LOGIN: 1 (TRYING) --> 3 (FAILED)
 923: NOT 10:19:27.429716 VPNC: set_login_state: VPNC : 1 (LoggingIn) --> 3 
   (LoginFailed)
 924: NOT 10:19:27.430297 VPNC: vpnc_send_notify: notify type: 1 [LoginFailed]
 925: NOT 10:19:27.430812 VPNC: vpnc_send_notify: notify code: 37 
   [SslAlertSrvrCert]
 926: NOT 10:19:27.431331 VPNC: vpnc_send_notify: notify desc: [alert: Unknown 
   CA (server cert)]
 927: NOT 10:19:27.431841 VPNC: vpnc_send_notify: sending signal 28 w/ value 13 to 
   pid 14
 928: ERR 10:19:27.432467 VPNC: protocol_handler: login failed

  

Funktion "Span to PC Port"

  

Sie können einen Computer direkt mit einem Telefon verbinden. Das Telefon verfügt über einen Switchport auf der Rückseite.

  

Konfigurieren Sie das Telefon wie zuvor, aktivieren Sie den Span to PC-Port auf dem CUCM, und wenden Sie die Konfiguration an. Das Telefon beginnt, eine Kopie jedes Frames an den PC zu senden. Verwenden Sie Wireshark im Promiscuous-Modus, um den Datenverkehr für die Analyse zu erfassen.

  

  

Konfigurationsänderungen bei IP-Telefonen, die über VPN verbunden sind

  

Eine häufige Frage ist, ob Sie die VPN-Konfiguration ändern können, während das IP-Telefon über AnyConnect mit dem Netzwerk verbunden ist. Die Antwort ist "Ja", Sie sollten jedoch einige Konfigurationseinstellungen bestätigen.

  

Nehmen Sie die erforderlichen Änderungen in CUCM vor, und wenden Sie die Änderungen dann auf das Telefon an. Es gibt drei Optionen (Apply Config (Konfiguration anwenden), Reset (Zurücksetzen) und Restart (Neustart)), um die neue Konfiguration auf das Telefon zu übertragen. Obwohl alle drei Optionen die VPN-Verbindung zwischen Telefon und ASA trennen, können Sie die Verbindung automatisch wiederherstellen, wenn Sie die Zertifikatsauthentifizierung verwenden. Wenn Sie Authentifizierung, Autorisierung und Abrechnung (AAA) verwenden, werden Sie erneut zur Eingabe Ihrer Anmeldeinformationen aufgefordert.

  

  

Hinweis: Befindet sich das IP-Telefon an der Remote-Seite, erhält es normalerweise eine IP-Adresse von einem externen DHCP-Server. Damit das IP-Telefon die neue Konfiguration vom CUCM erhält, muss es sich an den TFTP-Server in der Hauptniederlassung wenden. Normalerweise ist der CUCM derselbe TFTP-Server.

  

Um die Konfigurationsdateien mit den Änderungen zu erhalten, stellen Sie sicher, dass die IP-Adresse für den TFTP-Server in den Netzwerkeinstellungen des Telefons korrekt eingerichtet ist. Verwenden Sie zur Bestätigung die Option 150 des DHCP-Servers, oder legen Sie das TFTP manuell auf dem Telefon fest. Auf diesen TFTP-Server kann über eine AnyConnect-Sitzung zugegriffen werden.

  

Wenn das IP-Telefon den TFTP-Server von einem lokalen DHCP-Server empfängt, diese Adresse jedoch falsch ist, können Sie die alternative TFTP-Serveroption verwenden, um die vom DHCP-Server bereitgestellte IP-Adresse des TFTP-Servers zu überschreiben. In diesem Verfahren wird beschrieben, wie Sie den alternativen TFTP-Server anwenden:

  

1. Navigieren Sie zu Einstellungen > Netzwerkkonfiguration > IPv4-Konfiguration.
   
   
2. Navigieren Sie zu Alternative TFTP-Option.
   
   
3. Drücken Sie die programmierbare Taste Ja, damit das Telefon einen alternativen TFTP-Server verwendet; andernfalls drücken Sie die programmierbare Taste Nein. Wenn die Option gesperrt ist, drücken Sie * * #, um sie zu entsperren.
   
   
4. Drücken Sie die programmierbare Taste Speich.
   
   
5. Option "Apply the Alternate TFTP Server under TFTP Server 1" (TFTP-Server 1).

  

Überprüfen Sie die Statusmeldungen im Webbrowser oder direkt in den Telefonmenüs, um sicherzustellen, dass das Telefon die richtigen Informationen erhält. Wenn die Kommunikation korrekt eingerichtet ist, werden Meldungen wie diese angezeigt:

  

  

Wenn das Telefon die Informationen nicht vom TFTP-Server abrufen kann, erhalten Sie folgende TFTP-Fehlermeldungen:

  

  

Erneuerung des ASA SSL-Zertifikats

  

Wenn Sie ein funktionsfähiges AnyConnect VPN-Telefon eingerichtet haben, Ihr ASA SSL-Zertifikat jedoch bald abläuft, müssen Sie nicht alle IP-Telefone zum Hauptstandort bringen, um die neuen SSL-Zertifikate in das Telefon einzuschleusen. Sie können die neuen Zertifikate hinzufügen, während das VPN verbunden ist.

  

Wenn Sie das Root-Zertifizierungsstellenzertifikat der ASA anstelle des Identitätszertifikats exportiert oder importiert haben und wenn Sie während dieser Verlängerung dieselbe Zertifizierungsstelle (Vendor, CA) verwenden möchten, müssen Sie das Zertifikat im CUCM nicht ändern, da es identisch bleibt. Wenn Sie jedoch das Identitätszertifikat verwendet haben, ist dieses Verfahren erforderlich. Andernfalls stimmen die Hash-Werte zwischen ASA und IP-Telefon nicht überein, und die Verbindung wird vom Telefon nicht als vertrauenswürdig eingestuft.

  

1. Erneuern Sie das Zertifikat auf der ASA.
   

   Hinweis: Weitere Informationen finden Sie unter ASA 8.x: Renew and Install the SSL Certificate with ASDM. Erstellen Sie einen separaten Vertrauenspunkt, und wenden Sie dieses neue Zertifikat mit dem Befehl ssl trustpoint <name> outside nicht an, bis Sie das Zertifikat auf alle VPN-IP-Telefone angewendet haben.

2. Exportieren Sie das neue Zertifikat.
   
   
3. Importieren Sie das neue Zertifikat als Phone-VPN-Trust-Zertifikat in den CUCM.
   

   Hinweis: Beachten Sie, dass beim Hochladen von Zertifikaten mit derselben CN das alte Zertifikat in Phone-VPN-trust CSCuh19734 überschrieben wird.

4. Navigieren Sie zur Konfiguration des VPN-Gateways im CUCM, und wenden Sie das neue Zertifikat an. Sie verfügen jetzt über beide Zertifikate: das Zertifikat, das bald abläuft, und das neue Zertifikat, das noch nicht auf die ASA angewendet wurde.
   
   
5. Wenden Sie diese neue Konfiguration auf das IP-Telefon an. Navigieren Sie zu Apply Config > Reset > Restart (Konfiguration anwenden > Zurücksetzen > Neustart), um die neuen Konfigurationsänderungen über den VPN-Tunnel in das IP-Telefon einzufügen. Stellen Sie sicher, dass alle IP-Telefone über das VPN verbunden sind und dass sie den TFTP-Server über den Tunnel erreichen können.
   
   
6. Verwenden Sie TFTP, um die Statusmeldungen und die Konfigurationsdatei zu überprüfen und zu bestätigen, dass das IP-Telefon die Konfigurationsdatei mit den Änderungen erhalten hat.
   
   
7. Wenden Sie den neuen SSL-Vertrauenspunkt auf der ASA an, und ersetzen Sie das alte Zertifikat.

  

Hinweis: Wenn das ASA SSL-Zertifikat bereits abgelaufen ist und die IP-Telefone keine Verbindung über AnyConnect herstellen können, können Sie die Änderungen (z. B. den Hash des neuen ASA-Zertifikats) an das IP-Telefon übertragen. Legen Sie für das TFTP auf dem IP-Telefon manuell eine öffentliche IP-Adresse fest, damit das IP-Telefon die Informationen von dort abrufen kann. Verwenden Sie einen öffentlichen TFTP-Server, um die Konfigurationsdatei zu hosten. Ein Beispiel hierfür ist die Erstellung einer Port Forwarding-Funktion auf der ASA, die den Datenverkehr an den internen TFTP-Server umleitet.