Cloud VPN zu Cisco ASA: Neuaufbau nach abweichendem Vorschlag

NEGOTIATION_FAILURE auf einem Cloud VPN Tunnel mit einer Cisco ASA am anderen Ende ist fast immer eine Abweichung beim Vorschlag oder bei den Selektoren, und die erste nützliche Tatsache ist, dass keine Bearbeitung das behebt. Cloud VPN legt den IKE-Vorschlag fest, wenn das Tunnelobjekt erstellt wird. Es gibt kein Feld, um einen Algorithmus an Ort und Stelle zu ändern, also ist die Reparatur ein Löschen und ein Neuanlegen mit einem festgehaltenen Ausgangspunkt. Behandeln Sie es als Neuaufbau, und die Arbeit wird zu einer Checkliste statt zu einem Nachmittag voller Vermutungen.

Lesen Sie den Fehler, bevor Sie etwas löschen

Ein Aushandlungsfehler ist ein Phasenproblem, und das Peer-Log nennt meist die Phase. Scheitert Phase 1, konnten sich die Enden nicht auf einen Vorschlag einigen oder sich nicht gegenseitig authentifizieren. Scheitert Phase 2, kam der Tunnel hoch und die geschützten Selektoren passten nicht. Das sind unterschiedliche Reparaturen, und die Logzeile lohnt sich, bevor jemand eine Konfiguration anfasst.

Der Fehler schließt auch Dinge aus. Es ist keine VPC-Route, keine Firewall-Regel auf der Tunnelschnittstelle und kein Namensauflösungsfehler innerhalb des Netzes. Dem nachzujagen erzeugt selbstsichere Änderungen, die das Ergebnis nicht ändern können, und macht die spätere Behebung schwerer zuzuordnen.

Halten Sie beide Konfigurationen fest, solange es sie noch gibt

Einen Tunnel zu löschen dauert eine halbe Minute und zerstört den einzigen Beweis, den Sie hatten. Schreiben Sie davor die lokalen und entfernten Selektoren, die Peer-Adresse, wem das gemeinsame Geheimnis gehört und die Crypto Map bzw. das IKEv2-Profil der ASA auf. Die ASA beantwortet zwei getrennte Fragen: was konfiguriert ist und was gerade läuft:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Lesen Sie auf der Google-Seite das Tunnelobjekt statt der Konsolenzusammenfassung, denn die Peer-Adresse und die Selektor-Felder sind die Werte, die Sie exakt reproduzieren müssen:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Tragen Sie diese Werte ins Ticket ein, bevor Sie das erste Mal löschen. Der Neuaufbau unten funktioniert nur, weil Sie dasselbe Objekt mit einem bewussten Unterschied neu anlegen können.

Die Algorithmen, über die eine Seite nicht verhandeln will

Cloud VPN wählt nicht aus einer Reihe von IKEv1-Algorithmen wie ein traditioneller Peer. Die Peer-Einstellungen, die es erwartet, sind fest: aes-cbc-128 für die Verschlüsselung, sha1-96 für Integrität und PRF, Diffie-Hellman-Gruppe 2, 36,600 Sekunden für Phase 1 und 10,800 Sekunden für Phase 2. Die ASA-Richtlinie muss genau diese Menge anbieten. Ein zweiter Vorschlag auf der ASA schadet nicht, solange der passende ebenfalls in der Liste steht.

IKEv2 gibt beiden Seiten mehr Spielraum, aber die Regeln behalten dieselbe Form: PFS aktivieren, eine DH-Gruppe wählen, die der Tunnel unterstützt, und die Vorschlagsliste kurz genug halten, damit eine Abweichung offensichtlich ist. Ein ASA-Peer an Cloud VPN bedeutet außerdem statisches Routing, also müssen die geschützten Präfixe geplant und aufgelistet werden, statt sie BGP zu überlassen.

Eine aus einer fremden Herstellervorlage kopierte Lebensdauer ist hier der übliche falsche Weg. Google veröffentlicht diese Werte als erforderliche Peer-Einstellungen, setzen Sie sie also; ein kürzerer Wert wird nicht auf das hochverhandelt, was die ASA will.

Löschen, neu anlegen und den alten Zustand aufräumen

Löschen Sie den Tunnel, nicht das Gateway, und notieren Sie den Namen, den Cloud VPN dem Ersatz gibt, denn Namen werden vergeben und nicht wiederverwendet. Legen Sie ihn mit den festgehaltenen Werten und derselben Peer-Adresse neu an und fügen Sie dann den passenden Vorschlag zur Richtlinienliste der ASA hinzu.

Räumen Sie die Security Associations nach der ASA-Änderung und vor dem Lesen des Ergebnisses auf. Eine ASA kann eine veraltete Richtlinie weiter anbieten, bis die aktuelle SA abläuft, also sieht eine korrekte Konfiguration über die gesamte alte Lebensdauer kaputt aus, und der Beobachter schließt, der Neuaufbau sei gescheitert, obwohl er noch nicht begonnen hatte:

clear crypto ikev2 sa
clear crypto ipsec sa

Bestätigen Sie, dass Phase 1 hochkommt, bevor Sie Phase 2 ansehen. Solange Phase 1 unten ist, sind der Vorschlag oder der vorab geteilte Schlüssel falsch, und Selektorarbeit ändert daran nichts.

Selektoren spiegeln, dann entscheiden die Zähler

Phase 2 funktioniert nur, wenn beide Enden sich über die geschützten Adressen einig sind, und die Einigkeit ist gespiegelt, nicht geteilt. Der lokale Selektor von Google muss zu dem Selektor passen, den die ASA als entfernt bezeichnet, und der entfernte Selektor von Google zu dem, was die ASA als lokal bezeichnet. Ein Tunnel mit 0.0.0.0/0 auf einer Seite und einem einzelnen Subnetz auf der anderen besteht Phase 1 und scheitert dann in Phase 2 mit derselben Schlagzeile. Keine Seite kann die Liste der anderen erweitern.

Listen Sie bei richtlinienbasierten Selektoren jedes Präfixpaar auf und halten Sie die Liste im Ticket fest. Ein später vor Ort hinzugefügtes Subnetz erfordert eine Änderung an beiden Enden, denn eine neue Route auf der ASA erweitert keinen Selektor, und das Ergebnis ist ein Tunnel, der steht und nur Verkehr für die Präfixe durchlässt, die am ersten Tag existierten.

Schließen Sie mit einem Host-zu-Host-Fluss ab und lesen Sie die Byte-Zähler auf beiden Seiten. Zähler, die auf der ASA steigen und auf Google flach bleiben, bedeuten meist, dass die Antwort über eine andere Schnittstelle hinausgeht oder der Selektor das Rückpräfix nicht abdeckt. Notieren Sie Algorithmen, Lebensdauern, Selektoren und den neuen Tunnelnamen, denn die nächste Vorschlagsänderung wiederholt diesen Neuaufbau, und diese Werte machen daraus eine kurze Aufgabe.