Problemen met IPsec-problemen voor servicetunnels op vEdge-servers met IKEv2 oplossen

Downloadopties

  • PDF     (557.5 KB)
    Met Adobe Reader op diverse apparaten bekijken
Bijgewerkt:18 november 2021
Document-id:217418

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

    Inleiding

    Dit document beschrijft hoe u problemen kunt oplossen met de meest gebruikelijke problemen voor IPsec-tunnels (Internet Protocol Security) naar apparaten van derden met Internet Key Exchange versie 2 (IKEv2) geconfigureerd. Wordt meestal beschouwd als Service/Transport-tunnels op Cisco SD-WAN documentatie. Dit document legt ook uit hoe u IKE-debugs kunt inschakelen en lezen en hoe u deze kunt koppelen aan de pakketuitwisseling om inzicht te krijgen in het punt van de mislukking van een IPsec-onderhandeling.

    Voorwaarden

    Vereisten

    Cisco raadt kennis van de volgende onderwerpen aan:

    • IKEv2
    • IPsec-onderhandeling
    • Cisco SD-WAN

    Gebruikte componenten

    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 live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

    Achtergrondinformatie

    IKE-woordenlijst

    • IPsec (Internet Protocol Security) is een standaardreeks protocollen tussen 2 communicatiepunten in het IP-netwerk die gegevensverificatie, -integriteit en -vertrouwelijkheid bieden.
    • Internet Key Exchange versie 2 (IKEv2) is het protocol dat wordt gebruikt om een security associatie (SA) in de IPsec-protocolreeks in te stellen.
    • Een security association (SA) is de instelling van gedeelde beveiligingskenmerken tussen twee netwerkentiteiten ter ondersteuning van beveiligde communicatie. Een SA kan attributen zoals cryptografisch algoritme en wijze omvatten; verkeerscoderingssleutel; en parameters voor de netwerkgegevens die via de verbinding moeten worden doorgegeven.
    • De leveranciersidentificatiecodes (VID) worden gebruikt om peer-apparaten met de zelfde verkopersimplementatie te identificeren om verkoper-specifieke eigenschappen te steunen.
    • Opnieuw: willekeurige waarden die in de uitwisseling worden gemaakt om willekeur toe te voegen en terugspeelaanvallen te voorkomen.
    • Key-exchange (KE) informatie voor het Diffie-Hellman (DH) beveiligde key-exchange proces.
    • Identity Initiator/Responder (IDi/IDr) wordt gebruikt om de peer authenticatiegegevens te sturen. Deze informatie wordt doorgegeven onder de bescherming van het gemeenschappelijk gedeeld geheim.
    • De IPSec gedeelde sleutel kan worden afgeleid met het gebruik van DH opnieuw om Perfect Forward Secrecy (PFS) te verzekeren of met een verfrissing van het gedeelde geheim dat uit de oorspronkelijke DH-uitwisseling wordt afgeleid.
    • Diffie-Hellman (DH) sleuteluitwisseling is een veilige methode van cryptografische algoritmes ruilen via een publiek kanaal.
    • Traffic Selectors (TS) zijn de proxy-identiteiten of het verkeer dat op de IPsec-onderhandeling wordt uitgewisseld om door de versleutelde tunnel te gaan.

    IKEv2 Packet Exchange

    Elk IKE-pakket bevat payloadinformatie voor de tunnelinstelling. De IKE-woordenlijst legt de afkortingen uit die op deze afbeelding worden getoond als deel van de payload-inhoud voor de pakketuitwisseling.

    IKEV2 - NAT-TIKEV2-Exchange

    Opmerking: Het is belangrijk om te verifiëren op welke pakketuitwisseling van de IKE-onderhandeling de IPsec-tunnel er niet in slaagt snel te analyseren welke configuratie betrokken is om het probleem effectief aan te pakken.

    Opmerking: Dit document beschrijft niet dieper de IKEv2 Packet exchange. Voor meer verwijzingen, navigeer naar IKEv2 Packet Exchange en Protocol Level Debugging

    Het is nodig om de vEdge-configuratie te correleren met de Cisco IOS® XE-configuratie. Ook is het handig om de IPsec-concepten en de payload-inhoud af te stemmen op IKEv2-pakketuitwisselingen zoals in de afbeelding.

    Config for vedge and IOS-XE

    Opmerking: Elk deel van de configuratie wijzigt een aspect van de IKE-onderhandelingsuitwisseling. Het is belangrijk de opdrachten te correleren met de protocolonderhandeling van IPsec.

    Problemen oplossen

    IKE-debugs inschakelen

    Op vEdge debug iked maakt debug level informatie of IKEv1 of IKEv2.

    debug iked misc high
    debug iked event high

    Het is mogelijk om de huidige debug informatie binnen vshell weer te geven en de opdrachtstaart -f <debug path> uit te voeren.

    vshell
    tail -f /var/log/message

    In CLI is ook mogelijk om de huidige logbestanden/debug-informatie voor het opgegeven pad weer te geven.

    monitor start /var/log/messages

    Tips voor het starten van het probleemoplossingsproces voor IPsec-problemen

    Het is mogelijk om drie verschillende IPsec scenario's te scheiden. Het is een goed referentiepunt om het symptoom te identificeren voor een betere benadering van de kennis om te beginnen.

    1. IPsec-tunnel maakt geen verbinding.
    2. IPsec-tunnel ging omlaag en herstelde vanzelf. (Geknipt)
    3. IPsec-tunnel ging omlaag en blijft in downstate.

    Aangezien de IPsec-tunnel geen symptomen veroorzaakt, is het nodig om in real-time te debuggen om te verifiëren wat het huidige gedrag is bij de IKE-onderhandeling.

    Voor IPsec-tunnels daalde en herstelde het op zijn eigen symptomen, het meest bekend als tunnel Flapped en de worteloorzaakanalyse (RCA) is nodig. Het is onontbeerlijk om de tijdstempel te kennen wanneer de tunnel daalde of een geschatte tijd hebben om de debugs te bekijken.

    Want IPsec-tunnel ging omlaag en het blijft downstate symptomen, het betekent dat de tunnel eerder werkte, maar om welke reden dan ook, het daalde en we moeten de reden van de afbraak en het huidige gedrag dat verhindert dat de tunnel opnieuw succesvol wordt opgezet kennen.

    Identificeer de punten voordat de probleemoplossing wordt gestart:

    1. IPsec-tunnel (nummer) met problemen en configuratie.
    2. Tijdstempel bij het uitvallen van de tunnel (indien van toepassing).
    3. IPsec peer-IP-adres (tunnelbestemming).

    Alle debugs en logboeken worden opgeslagen op /var/log/message bestanden, voor de huidige logboeken, ze worden opgeslagen op het berichtenbestand, maar voor dit specifieke symptoom de flap kan worden geïdentificeerd uren / dagen na het probleem, meest waarschijnlijk debugs gerelateerd zou zijn op message1, 2, 3..etc. Het is belangrijk om de tijdstempel te kennen om het juiste berichtbestand te bekijken en de debugs (charon) te analyseren voor de IKE-onderhandeling van de IPsec Tunnel in verband met.

    De meeste debugs afdrukken niet het nummer van de IPsec-tunnel. De meest frequente manier om de onderhandeling en pakketten te identificeren is met het IP-adres van de externe peer en het IP-adres waar de tunnel op de rand is gesourcet. Enkele voorbeelden van IKE debugs gedrukt:

    Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_IPsec2_1'
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1

    De debugs voor de IKE INIT-onderhandeling tonen het IPsec-tunnelnummer. De latere informatie voor pakketuitwisseling gebruikt echter alleen de IPsec-tunneladressen.


    Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_ipsec2_1'
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
    Jun 18 00:31:22 vedge01 charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
    Jun 18 00:31:22 vedge01 charon: 16[NET] sending packet: from 10.132.3.92[500] to 10.10.10.1[500] (464 bytes)
    Jun 18 00:31:22 vedge01 charon: 12[NET] received packet: from 10.10.10.1[500] to 10.132.3.92[500] (468 bytes)
    Jun 18 00:31:22 vedge01 charon: 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HTTP_CERT_LOOK) N(FRAG_SUP) V ]
    Jun 18 00:31:22 vedge01 charon: 12[ENC] received unknown vendor ID: 4f:85:58:17:1d:21:a0:8d:69:cb:5f:60:9b:3c:06:00
    Jun 18 00:31:22 vedge01 charon: 12[IKE] local host is behind NAT, sending keep alives

    IPsec-tunnelconfiguratie:

    interface ipsec2
  ip address 192.168.1.9/30
  tunnel-source      10.132.3.92
  tunnel-destination 10.10.10.1
  dead-peer-detection interval 30
  ike
   version      2
   rekey        86400
   cipher-suite aes256-cbc-sha1
   group        14
   authentication-type
    pre-shared-key
     pre-shared-secret $8$wgrs/Cw6tX0na34yF4Fga0B62mGBpHFdOzFaRmoYfnBioWVO3s3efFPBbkaZqvoN
    !
   !
  !
  ipsec
   rekey                   3600
   replay-window           512
   cipher-suite            aes256-gcm
   perfect-forward-secrecy group-14
  !

    Symptoom 1.  IPsec-tunnel wordt niet tot stand gebracht

    Aangezien de kwestie de eerste implementatie voor de tunnel kan zijn, is het niet omhoog geweest en de IKE debugs zijn de beste optie.

    Symptoom 2.  IPsec-tunnel ging omlaag en deze werd weer zelfstandig opgebouwd

    Zoals eerder vermeld, wordt dit symptoom gewoonlijk geadresseerd om de wortel oorzaak van te weten te komen waarom de tunnel daalde. Met de analyse van de worteloorzaak bekend, soms, verhindert de admin van het netwerk verdere kwesties.

    Identificeer de punten voordat de probleemoplossing wordt gestart:

    1. IPsec-tunnel (nummer) met problemen en configuratie.
    2. Het tijdstempel toen de tunnel naar beneden ging.
    3. IPsec peer-IP-adres (tunnelbestemming)

    DPD-heruitzendingen

    In dit voorbeeld ging de tunnel op 18 juni om 00:31:17 naar beneden.

    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down

    Opmerking: De logboeken voor IPsec-tunneling zijn geen deel van foutopsporing, het zijn FTMD-logboeken. Daarom zou charon noch IKE worden gedrukt.

    Opmerking: De verwante logboeken zijn gewoonlijk niet samen gedrukt, is er meer informatie tussen hen niet met betrekking tot het zelfde proces. 

    Stap 1. Nadat de tijdstempel wordt geïdentificeerd en de tijd en de logbestanden worden gecorreleerd, begin om de logbestanden van onder naar boven te bekijken.

    Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
    Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:28:22 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)  
    Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request 
    Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ] 
    Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

    De laatste succesvolle DPD pakketuitwisseling wordt beschreven als verzoek # 542.

    Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ] 
    Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 13.51.17.190[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]

     Stap 2. Alle informatie in de juiste volgorde samenvoegen:

    Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ] 
    Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 10.132.3.92[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ] 

    Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request 
    Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ] 
    Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

    Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 

    Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:28:22 Lvedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 

    Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"LONDSR01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down

    In het beschreven voorbeeld gaat de tunnel omlaag omdat vEdge01 de DPD-pakketten van 10.10.10.1 niet ontvangt. Verwacht wordt dat de IPsec-peer na 3 DPD-uitzendingen "verloren" is en de tunnel daalt. Er zijn meerdere redenen voor dit gedrag, meestal is het gerelateerd aan de ISP waar de pakketten verloren zijn gegaan of op het pad zijn gevallen. Als de kwestie één keer voorkomt, is er geen manier om het verloren verkeer te volgen. Als de kwestie echter blijft voortduren, kan het pakket worden gevolgd met het gebruik van opnamen op vEdge, externe IPSec-peer en de ISP.

    Symptoom 3. IPsec-tunnel ging omlaag en blijft downstate

    Zoals eerder in dit symptoom werd vermeld, werkte de tunnel voordien prima, maar om welke reden dan ook is hij neergehaald en is de tunnel niet in staat geweest om weer succesvol tot stand te komen. In dit scenario is er een effect op het netwerk.

    identificeer de punten voordat de probleemoplossing begint:

    1. IPsec-tunnel (nummer) met problemen en configuratie.
    2. Het tijdstempel toen de tunnel naar beneden ging.
    3. IPsec peer-IP-adres (tunnelbestemming)

    Foute PFS

    In dit voorbeeld, begint de probleemoplossing niet met de tijdstempel wanneer de tunnel daalt. Aangezien de kwestie voortduurt, zijn de IKE debugs de beste optie. 

    interface ipsec1
  description             VWAN_VPN
  ip address 192.168.0.101/30
  tunnel-source-interface ge0/0
  tunnel-destination      10.10.10.1
  ike
   version      2
   rekey        28800
   cipher-suite aes256-cbc-sha1
   group        2
   authentication-type
    pre-shared-key
     pre-shared-secret "$8$njK2pLLjgKWNQu0KecNtY3+fo3hbTs0/7iJy6unNtersmCGjGB38kIPjsoqqXZdVmtizLu79\naQdjt2POM242Yw=="
    !
   !
  !
  ipsec
   rekey                   3600
   replay-window           512
   cipher-suite            aes256-cbc-sha1
   perfect-forward-secrecy group-16 
  !
  mtu                     1400
  no shutdown

    De debug-sleutel is ingeschakeld en onderhandeling wordt weergegeven.

    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (508 bytes) 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] parsed CREATE_CHILD_SA request 557 [ SA No TSi TSr ] 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] no acceptable proposal found 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] failed to establish CHILD_SA, keeping IKE_SA 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] generating CREATE_CHILD_SA response 557 [ N(NO_PROP) ] 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes) 

    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (76 bytes) 
    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] parsed INFORMATIONAL request 558 [ ] 
    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] generating INFORMATIONAL response 558 [ ] 
    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes) 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (396 bytes) 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[ENC] parsed CREATE_CHILD_SA request 559 [ SA No TSi TSr ] 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:58 Avedge01 charon: 07[IKE] no acceptable proposal found 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA

    Opmerking:  CREATE_CHILD_SA pakketten worden uitgewisseld voor elke rekey of nieuwe SA. Voor meer referenties navigeer je naar IKEv2 Packet Exchange

    IKE debugs tonen hetzelfde gedrag en het wordt constant herhaald, dus het is mogelijk om een deel van de informatie te nemen en het te analyseren: 

    CREATE_CHILD_SA betekent een rekey, met als doel dat de nieuwe SPIS gegenereerd en uitgewisseld wordt tussen de IPsec-endpoints.

    • De vedge ontvangt het CREATE_CHILD_SA verzoekpakket van 10.10.10.1.
    • De vedge verwerkt het verzoek en verifieert de voorstellen (SA) verzonden door peer 10.10.10.1
    • De vedge vergelijkt het ontvangen voorstel verzonden door de peer met zijn geconfigureerde voorstellen.
    • De uitgewisselde CREATE_CHILD_SA mislukt met "geen aanvaardbare voorstellen gevonden".

    De vraag is nu: Waarom is er een configuratiewanverhouding als de tunnel eerder werkte en geen veranderingen werden aangebracht?

    Analyseer in diep, is er een extra veld op de geconfigureerde voorstellen die de peer niet verzendt.

    geconfigureerde voorstellen: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ

    Ontvangen voorstellen:
    ESP:AES_GCM_16_256/NO_EXT_SEQ
    ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
    ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ
    ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
    ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
    ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ

    MODP_4096 is DH-groep 16, die randen heeft geconfigureerd voor PFS (perfect-forward-secrecy) in fase 2 (IPsec-sectie).

    PFS is de enige foutieve configuratie waarin de tunnel met succes kan worden opgezet of niet afhankelijk van wie de initiator of het antwoordapparaat in de IKE-onderhandeling is. Wanneer de sleutel echter start, kan de tunnel niet verder gaan en kan dit symptoom worden gepresenteerd of gerelateerd aan.

    vEdge IPSec/IKEv2-tunnel wordt niet opnieuw geïnitieerd nadat deze is uitgeschakeld als gevolg van een Delete-gebeurtenis

    Zie Cisco bug-id CSCvx86427 voor meer informatie over dit gedrag.

    Aangezien de kwestie voortduurt, zijn de IKE debugs de beste opties. Echter, voor deze bepaalde bug als debugs zijn ingeschakeld wordt geen informatie weergegeven noch de terminal noch het berichtbestand.

    Om dit probleem te verhelpen en te verifiëren of vEdge de Cisco bug-id CSC86427 raakt, is het nodig om het moment te vinden waarop de tunnel uitvalt.

    identificeer de punten voordat de probleemoplossing begint:

    1. IPsec-tunnel (nummer) met problemen en configuratie.
    2. Het tijdstempel toen de tunnel naar beneden ging.
    3. IPsec peer-IP-adres (tunnelbestemming)

    Nadat de tijdstempel wordt geïdentificeerd, en de tijd en de logboeken worden gecorreleerd, herzie de logboeken vlak vóór wanneer de tunnel daalt.

    Apr 13 22:05:21 vedge01 charon: 12[IKE] received DELETE for IKE_SA ipsec1_1[217] 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1] 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1] 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted 
    Apr 13 22:05:21 vedge01 charon: 12[ENC] generating INFORMATIONAL response 4586 [ ] 
    Apr 13 22:05:21 vedge01 charon: 12[NET] sending packet: from 10.16.0.5[4500] to 10.10.10.1[4500] (80 bytes) 
    Apr 13 22:05:21 vedge01 charon: 12[KNL] Deleting SAD entry with SPI 00000e77 
    Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec1 DOWN
    Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.1.0.1 vpn-id:1 if-name:"ipsec1" new-state:down

    Opmerking:  Er zijn multiples DELETES pakketten op een IPsec onderhandeling, en de Delete voor CHILD_SA is een verwachte Delete voor een REKEY-proces, deze kwestie wordt gezien wanneer een puur IKE_SA DELETE-pakket wordt ontvangen zonder enige specifieke IPsec-onderhandeling. Hiermee verwijdert u alle IPsec/IKE-tunnels.

    Gerelateerde informatie

    Revisiegeschiedenis

    Revisie Publicatiedatum Opmerkingen
    2.0
    18-Nov-2021
    Meer informatie aan het document toevoegen
    1.0
    29-Sep-2021
    Eerste vrijgave
    TAC Authored

    Bijgedragen door Cisco-engineers

    • Amanda Nava Zarate
      Cisco TAC Engineer

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco