In comparatie cu alte subiecte de networking pe care le depanam, IPsec este unul din cele mai complexe datorita faptului ca are multe elemente ce-l formeaza pentru a fi functional. Nu o sa detaliez modul cum este configurat, dar cateva reguli trebuie respectate:

  1. Configuratia trebuie sa fie in oglinda pe ambele capete ale tunelului VPN Site to Site.
  2. Trebuie sa existe conectivitate end to end.
  3. Firewall-ul din fata capetelor trebuie sa permita traficul specific IPsec (esp, isakmp, non500-isakmp/nat-traversal)
  4. Pentru sincronizarea timpului din lifetime este necesar ca echipamentele sa aiba acelasi datetime (este recomandat pentru optimizare un NTP server comun).
  5. Asigurarea unei versiuni de firmware cu suport pentru tipul de configuratie dorit si fix pentru bugurile care ar putea cauza probleme de functionalitate.

In experienta mea configurand IPsec S2S pe IOS am observat in problemele intalnite ca aproximativ 70% sunt probleme de configurare, 20% probleme de conectivitate si 10% buguri. Unele din cele mai dificil de gasit au fost cele legate de buguri. In ultimul caz intalnit o sa va prezint metodele folosite de mine pentru a depista un bug.

Am avut un client ce conecta prin VPN reteaua biroului dintr-un oraa din tara cu datacenter-ul sau. Am folosit ikev2 route-based IPsec cu tunele VTI. Problema era ca zilnic interfata tunel din sediul remote era up/down, iar in datacenter interfata la prima vedere era up/up. Factorul catalizator acestei situatii era intreruperea temporara a conexiunii sediului remote prin reload, pierderea energiei, deconectare internet sau un simplu rekey IPsec. Conexiunea intre retelele private nu functiona evident. Pasii de verificare:

  1. Situatia IPsec se desfasura dupa ce routerul isi recapata accesul. Internetul functiona, dar IPsec nu se reconecta ramanand in starea descrisa mai sus. Am testat conectivitatea end-to-end. In mod normal traficul icmp nu este permis in sediul remote, dar am observat ca pachetele icmp de la datacenter ajung, deoarece am pornit un debug icmp pe router:datacenter#ping 2.2.2.2 repeat 100000
    U.U.U.U.U.U.U.U..U.U.U.U.U.U.U..U.U.a

    client_cisco881#debug ip icmp
    client_cisco881#terminal monitor

    Jun 11 08:19:04.151: ICMP: dst (2.2.2.2) administratively prohibited unreachable sent to 1.1.1.1 – mesajul acesta arata ca pachetul icmp ajunge de la datacenter, dar este blocat de firewall permitand totusi livrarea unui mesaj icmp unreachable. Acest lucru nu ne afecteaza, deoarece trebuia doar sa demonstram ca ajunge traficul de la datacenter la client si invers.
  2. Acum verificam daca in firewall este permis pe ambele capete traficul IPsec esp, isakmp, nat-traversal (acesta cu nat-t fiind optional, in cazul nostru nu se aplica, deoarece tunelul este intre routere care nu au ip-urile de WAN translatate).client_cisco881#show access-lists 100

    80 permit udp host 1.1.1.1 any eq isakmp (1643 matches)
    90 permit esp host 1.1.1.1 any
    datacenter#show access-lists WAN-in

    20 permit udp object-group PEERS any eq isakmp (776 matches)
    40 permit esp object-group PEERS any
     (29912 matches)
    In acest object-group PEERS se afla ip-ul public al sediului remote, deci permitem traficul IPsec in ambele sensuri.
  3. Urmeaza sa comparam configuratia. Recomand metoda folosind notepad++. Eu am copiat configuratia de pe datacenter cu privire la acest sediu remote si configuratia de pe sediul remote cu privire la datacenter. In urma comparatiei rezulta ca nu exista nicio problema totul fiind in oglinda. Ce ne intereseaza cand facem acest lucru? Politica ikev2 trebuie sa fie la fel, psk-urile trebuie sa fie identice, transform-set-urile IPsec trebuie sa fie la fel, identitatile (locale si remote) trebuie sa fie mentionate, daca avem configurat pfs trebuie sa avem configurat acelasi grup DH, iar pe interfata tunel trebuie sa specificam mod ipsec si ca protectie folosind profilul ipsec corect. Lifetime-urile erau la fel (pe faza 1 de o zi, iar pe faza 2 de o ora) – deci nu aveam de a face cu spi-uri invalide sau nesincronizari de security association din cauza timpului diferit. In cazul nostru totul era ca la carte.
  4. In acest paz merg pe neincrederea in proprii ochi si trec la: Debugging. Daca am ratat ceva in analiza configuratiei, chiar si cea mai mica chestie prin acest procedeu ar trebui sa observ. Prima data verific notificarile primite din logging-ul propriuzis. Pentru a primi informațiile necesare pe ambele routere trebuie sa avem configurat:logging buffered 120000 notifications – prin aceasta primim notificari cu privire la diverse schimbari de functionalitate
    service timestamps log datetime msec localtime show-timezone – pentru a avea asociat timpul corect in loguriPe routerul remote nu observ nicio notificare, insa in datacenter observ ca interfata tunel nu este chiar up/up, ci flapeaza continuu de cand este up/down la client:
    datacenter#show log

    Jun 10 06:37:33.686 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel7, changed state to up
    Jun 10 06:38:03.666 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel7, changed state to down
    Jun 10 06:38:03.684 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel7, changed state to up
    Jun 10 06:39:34.062 EET: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel7, changed state to down
    In acest moment, pentru a incepe debugging trebuie sa stabilim cine este initiatorul sesiunii IPsec si cine este responder (cel care rsspunde initierii). In debugging se observa pasii stabilirii tunelului in ambele capete, dar eroarea unde se opreste stabilirea respectiva apare intotdeauna pe initiator, deoarece acesta observa problemele de configuratie/conectivitate, responder-ul nu face decat sa reactioneze la mesajele primite si sa stabileasca sesiunea dupa ce-si verifica configuratia. Verificam acest aspect prin comanda show crypto ikev2 sa remote x.x.x.x:
    Pe datacenter observam ca este responder:
    datacenter#show crypto ikev2 sa remote 2.2.2.2 detailed

    Initiator of SA : No
    Clientul se pare ca este initiator:
    client_cisco881#show crypto ikev2 sa remote 1.1.1.1 detailed

    Initiator of SA : YesAcum pornim debugging pe ambele capete. Trebuie sa stabilim o conditie, si anume sa arate debug doar pentru un anumit peer, deoarece daca avem mai multe peer-uri nu vom mai fi capabili sa izolam informatia primita din cauza numarului imens de loguri. In anumite cazuri este posibil sa blocam echipamentul suprasolicitand-ul.debug crypto condition peer ipv4 x.x.x.x – punem conditia selectand peer-ul dorit
    debug crypto ikev2 – efectuam debug pe faza 1
    debug crypto ipsec – debug pe faza 2Acum pe responder procesul negocierii faza 1 decurge normal, dar dupa autentificare psk incepe sa retransmita pachetele si sa expire sesiunea stergand SA-ul din cauza ca initiatorul nu raspunde. Mesajele generate de datacenter sunt in ordinea urmatoare:Initial exchange failed – eroare de ikev2 (faza 1) insemnand ca a esuat stabilirea tunelului faza 1.
    A supplied parameter is incorrect – insemnand ca peer-ul nu este de acord cu un mesaj trimis de datacenter.
    Failed to receive the AUTH msg before the timer expiredAuth exchange failed – ne apropiem de problema. Se pare ca esueaza undeva la autentificare. Datacenter asteapta un raspuns pentru autentificare si nu-l primeste stiind ca setarile sale de autentificare sunt corecte.
    Negotiation context locked currently in usePacket is a retransmission – insemnand ca vin mesaje ce incearca sa faca acelasi lucru ca cele initiale care au inceput negocierea
    Maximum number of retransmissions reached – limita de incercari a fost atinsa. In momentul acesta sesiunea este stearsa si se incearca din nou negocierea la initiativa peer-ului.Tinand minte ca exista ceva cu care peer-ul nu este de acord bazandu-ne pe mesajul ”A supplied parameter is incorrect” incercam initierea unei sesiuni de debugging pe routerul remote (ne gandim ca intiatorul o sa ne arate eroarea specifica). Mesajele primite sunt urmatoarele:Process auth response notify – routerul remote proceseaza raspunsul pentru autentificare in momentul primirii detaliilor de autentificare de la datacenter.

    Searching policy based on peer’s identity ‘1.1.1.1’ of type ‘IPv4 address’ – Acum stim unde se uita device-ul. Se uita sub ”crypto ikev2 profile” unde avem setata identitatea remote a datacenterului dacă regăsește 1.1.1.1

    Failed to locate an item in the database, Verification of peer’s authentication data FAILED, Auth exchange failed, Abort exchange, Deleting SA – Din cate putem observa device-ul nu gaseste aceasta identitate sub ”crypto ikev2 profile” esuand astfel faza 1 la procesul de autentificare. Sa inteleg ca este o eroare de configuratie? Să vedem profilul:
    crypto ikev2 profile IKEv2-Profile
    match identity remote any
    identity local address 2.2.2.2
    authentication remote pre-share
    authentication local pre-share
    keyring local Keys
    dpd 10 2 on-demand

    Pe noi ne intereseaza ”match identity remote” unde trebuie sa gasim 1.1.1.1. Gasim? Aici noi avem ”any” care logic inseamna tot, inclusiv 1.1.1.1. Deci nu este o problema de configuratie. De ce am spus any? Deoarece am doua conexiuni cu datacenter-ul si folosesc acelasi profil ikev2 pentru ambele tunele. Am dorit sa acopar cu any specificarea identitatii ambelor ip-uri publice din DC.

    Avand in vedere ca setarile sunt corecte nu ramane decat o singura explicatie: este un bug. Solutia simpla si rapida a fost sa resetez interfata tunel de pe responder (datacenter) cu shut/no shut, dar nu a rezolvat problema pe termen lung, ea revenind a doua zi de dimineata la urmatorul rekey.

    Am cautat in baza de date Cisco cu privire la bug-uri si am descoperit doua buguri asemanatoare situatiei mele, chiar daca nu vorbea de aceeasi versiune de IOS. Bug-urile sunt CSCve07263 si CSCvi40357 vorbind despre starea tunelului in up/down dupa o resetare de tunel si match remote identity overlap cand avem configurate mai multe profiluri ikev2. In ambele cazuri este configurat ”match identity remote any”. Chiar daca profilul al doilea creat pe client nu este aplicat profilului IPsec folosit pentru tunelul cu DC, din cauza acestui bug, cand se uita la profil nu observa in expresia ”any” identitatea peer-ului (in cazul nostru 1.1.1.1), rezultand eroarea vazuta prin debug ”Failed to locate an item in the database”. Il vede ca suprapus cu profilul al doilea unde am un match remote specific, any incluzand si ip-ul respectiv.

    Solutia propusa in ambele bug-fix-uri a fost resetarea routerului (solutie temporara) sau upgrade de software la versiunea fixed (solutie permanenta). Din fericire am descoperit o metoda care se aplica situatiei mele si repara permanent. In datacenter am subnetul public 1.1.1.0/29 rezervat pentru configuratia de WAN/DMZ, nu am facut decat sa inlocuiesc sub profilul ikev2 ”any” cu ”1.1.1.0/29” acoperind mai specific ambele conexiuni VPN, dar neincluzand identitatea remote de sub celalalt profil ikev2. Configuratia arata acum astfel:

    crypto ikev2 profile IKEv2-Profile
    match identity remote address 1.1.1.0 255.255.255.248

    Cum mi-am dat seama? Am observat ca tunelul vpn cu profilul ikev2 unde aveam identitatea remote specifica functiona si am dedus de aici ca daca setez o identitate remote mai specifica problema de match identity remote overlap nu se mai repeta.

    Acum au trecut trei zile, iar vpn-ul este in continuare stabil.
    Sper ca v-a placut descrierea acestei depanari si ca va fi un ajutor in metodologia folosita de dumneavoastra ca punct de reper.

Articol scris de Bogdan Curduban – Network Engineer