Cloud VPN naar Cisco ASA: opnieuw opbouwen na een afwijkend voorstel

NEGOTIATION_FAILURE op een Cloud VPN-tunnel met een Cisco ASA aan de andere kant is bijna altijd een meningsverschil over het voorstel of over de selectors, en het eerste nuttige feit is dat geen enkele bewerking dat oplost. Cloud VPN legt het IKE-voorstel vast wanneer het tunnelobject wordt aangemaakt. Er is geen veld om een algoritme ter plaatse te wijzigen, dus de reparatie is verwijderen en opnieuw aanmaken met een vastgelegd uitgangspunt. Behandel het als een herbouw en het werk wordt een checklist in plaats van een middag gissen.

Lees de fout voordat je iets verwijdert

Een onderhandelingsfout is een fase probleem, en de peer-log noemt meestal de fase. Fase 1 die faalt betekent dat de uiteinden het niet eens werden over een voorstel of elkaar niet konden authenticeren. Fase 2 die faalt betekent dat de tunnel omhoog kwam en de beschermde selectors niet overeenkwamen. Dat zijn verschillende reparaties, en de logregel is het waard om eruit te halen voordat iemand een configuratie aanraakt.

De fout sluit ook dingen uit. Het is geen VPC-route, geen firewallregel op de tunnelinterface en geen naamresolutiefout binnen het netwerk. Die najagen levert zelfverzekerde wijzigingen op die het resultaat niet kunnen veranderen, en ze maken de uiteindelijke oplossing moeilijker toe te schrijven.

Leg beide configuraties vast zolang ze nog bestaan

Een tunnel verwijderen kost een halve minuut en vernietigt het enige bewijs dat je had. Schrijf daarvoor de lokale en externe selectors op, het peeradres, wie het gedeelde geheim bezit, en de crypto map of het IKEv2-profiel van de ASA. De ASA beantwoordt twee aparte vragen: wat is geconfigureerd en wat staat er nu omhoog:

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

Lees aan de Google-kant het tunnelobject in plaats van de consolesamenvatting, want het peeradres en de selectorvelden zijn de waarden die je exact moet reproduceren:

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

Zet die waarden in de ticket voordat je voor het eerst verwijdert. De herbouw hieronder werkt alleen omdat je hetzelfde object opnieuw kunt aanmaken met één bewuste afwijking.

De algoritmen waarover één kant weigert te onderhandelen

Cloud VPN kiest niet uit een reeks IKEv1-algoritmen zoals een traditionele peer. De peerinstellingen die het verwacht zijn vast: aes-cbc-128 voor versleuteling, sha1-96 voor zowel integriteit als PRF, Diffie-Hellman-groep 2, 36,600 seconden voor fase 1 en 10,800 seconden voor fase 2. Het ASA-beleid moet precies die set bieden. Een tweede voorstel op de ASA kan geen kwaad zolang het overeenkomende ook in de lijst staat.

IKEv2 geeft beide kanten meer ruimte, maar de regels houden dezelfde vorm: schakel PFS in, kies een DH-groep die de tunnel ondersteunt, en houd de voorstellenlijst kort genoeg zodat een afwijking duidelijk is. Een ASA-peer op Cloud VPN betekent ook statische routing, dus de beschermde prefixen moeten worden gepland en opgesomd in plaats van aan BGP overgelaten.

Een levensduur die uit de template van een andere leverancier is gekopieerd is hier de gebruikelijke verkeerde afslag. Google publiceert deze waarden als vereiste peerinstellingen, dus stel ze in; een kortere waarde wordt niet opwaarts onderhandeld tot wat de ASA wil.

Verwijder, maak opnieuw aan en ruim de oude toestand op

Verwijder de tunnel, niet de gateway, en noteer de naam die Cloud VPN aan de vervanging geeft, want namen worden toegewezen en niet hergebruikt. Maak hem opnieuw aan met de vastgelegde waarden en hetzelfde peeradres, en voeg dan het overeenkomende voorstel toe aan de beleidslijst van de ASA.

Ruim de security associations op na de wijziging op de ASA en voordat je het resultaat leest. Een ASA kan een verouderd beleid blijven aanbieden tot de huidige SA verloopt, dus een correcte configuratie ziet er kapot uit gedurende de hele oude levensduur en de wachter concludeert dat de herbouw is mislukt terwijl die nog niet begonnen was:

clear crypto ikev2 sa
clear crypto ipsec sa

Bevestig dat fase 1 omhoog komt voordat je naar fase 2 kijkt. Zolang fase 1 omlaag is, zijn het voorstel of de vooraf gedeelde sleutel onjuist, en selectorwerk verandert dat niet.

Selectors spiegelen, daarna beslissen de tellers

Fase 2 werkt alleen als beide uiteinden het eens zijn over de beschermde adressen, en de overeenstemming is gespiegeld, niet gedeeld. De lokale selector van Google moet overeenkomen met de selector die de ASA extern noemt, en de externe selector van Google met wat de ASA lokaal noemt. Een tunnel met 0.0.0.0/0 aan de ene kant en één subnet aan de andere passeert fase 1 en faalt daarna in fase 2 met dezelfde hoofdfout. Geen enkele kant kan de lijst van de andere verbreden.

Voor beleidsgebaseerde selectors, som elke prefixpaar op en bewaar de lijst in de ticket. Een subnet dat later on-premises wordt toegevoegd vereist een wijziging aan beide kanten, want een nieuwe route op de ASA verbreedt geen selector, en het resultaat is een tunnel die omhoog staat en alleen verkeer doorlaat voor de prefixen die op de eerste dag bestonden.

Sluit af met één host-naar-host-stroom en lees de bytetellers aan beide kanten. Tellers die op de ASA stijgen en op Google vlak blijven betekenen meestal dat het antwoord via een andere interface naar buiten gaat, of dat de selector het retourprefix niet dekt. Noteer de algoritmen, levensduren, selectors en de nieuwe tunnelnaam, want de volgende voorstelwijziging herhaalt deze herbouw en die waarden maken er een kort klusje van.