0

Cisco AnyConnect Secure Mobility Client: Abweichender Port / Keine IPSec-Verbindung möglich

Guten Tag zusammen,

ich bin heute auf ein interessantes Problem mit dem Cisco AnyConnect  Secure Mobility Client gestoßen. Diesen habe ich für einen Kunden eingerichtet, der nur eine öffentliche IP-Adresse besitzt. Port TCP/443 ist bereits durch einen Server in Benutzung und kann somit nicht für das VPN verwendet werden. Entsprechend musste die VPN-Konfiguration angepasst werden.

Hierzu habe ich zunächst die Ports für das WebVPN und die IPSec Client Services auf TCP/8000 geändert. Dies geschieht im ASDM unter „Remote Access VPN“, „Network (Client) Access“ und dann unter „AnyConnect Connection Profiles“.

 

port_settings

 

Nun kann das Connection Profile wie üblich erstellt werden. Anschließend muss in der XML-Datei für das Profil der Eintrag für den Server angepasst werden. Wir fügen wier hinter dem FQDN „:8000“ hinzu und verändern somit das Socket. Außerdem stellen wir das primäre Protokoll auf IPSec ein.

 

client_profile

 

Anschließend verbinden wir uns mit dem AnyConnect Secure Mobility Client auf den FQDN:8000. Die erste Verbindung wird über SSL hergestellt und ist erfolgreich. Außerdem wird hier das Client Profile heruntergeladen und lokal gespeichert. Die XML-Datei finden Sie unter folgendem Pfad: „C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile“. In der XML-Datei sollte sich auch das veränderte Socket wiederfinden.

Nach dem Trennen der VPN-Verbindung erfolgt der nächste Verbindungsaufbau über IPSec IKEv2. Bei unserem Kunden war dies jedoch nicht erfolgreich. Nach dem Löschen des Profils konnten wir wiederholt eine SSL-Verbindung herstellen. Die folgende IPSec-Verbindung konnte jedoch wiederholt nicht aufgebaut werden.

Somit begann die Fehlersuche. Die Einstellungen in der ASA schienen korrekt. Laut Wireshark versuchte auch mein Rechner eine IPSec Verbindung aufzubauen. Der Packet Capture Wizard auf der ASA konnte die IKE-Pakete ebenfalls finden. Es schien also als würde die ASA die Pakete einfach nicht verarbeiten.

Nach einem Telefonat mit Cisco wurde dieser Verdacht bestätigt. Der Supportengineer war gestern zufällig in einem Lab über dasselbe Problem gestolpert. Es handelt sich hierbei um einen Bug. Die Lösung ist zwar nicht naheliegend, aber simpel:

crypto ikev1 enable outside
no crypto ikev1 enable outside

Wir aktivieren auf dem Access Interface (in meinem Fall „outside“) IKEv1 und deaktivieren es anschließend wieder. Natürlich nutzt AnyConnect kein IKEv1, aber das Problem wird hierdurch dauerhaft behoben.

Abschließend können wir noch verifizieren, dass die Verbindung tatsächlich über IKEv2 hergestellt wurde. Dies geht wahlweise über den ASDM oder in der Shell via:

show vpn-sessiondb detail anyconnect

 

Bei Fragen zu diesem oder anderen Themen stehe ich Ihnen jederzeit gerne zur Verfügung. Meine Kontaktdaten finden Sie auf http://www.netzorange.de

Ich wünsche Ihnen einen angenehmen Abend.

 

Beste Grüße

Benedikt Wollenweber

 

 

Abgelegt unter: Netzwerk Tags: , , , , ,

Ähnliche Artikel

Bookmarke uns!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© 2017 IT-Dienstleistungen. All rights reserved. XHTML / CSS Valid.