www.SAMURAJ-cz.com 

02.05.2024 Zikmund Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

FortiGate IPsec VPN, debug a problémy

Upraveno 26.04.2021 08:40 | vytvořeno 14.04.2021 18:23 | Samuraj - Petr Bouška |
Pokusil jsem se dát dohromady stručný popis fungování IPsec protokolu pro navazování VPN. Primárně se článek zaměřuje na Site to Site VPN s využitím IKEv2 (a ESP). Nestudoval jsem RFC, informace jsou z různých článků na internetu, nejčastěji od výrobců (zaměřeno na Fortinet). Teorie se zaměřuje na jednotlivé termíny a bodový popis. Následuje orientační popis konfigurace IPsec VPN na FortiGate. Zbytek článku se věnuje tomu, jak provádět dohled, zjišťovat informace a řešit problémy (Troubleshooting), včetně ladění (Debugging). Zmiňuje také problémy, na které jsem narazil.

Pozn.: Popis v článku vychází z FortiGate FG-300E s FortiOS verzí 6.2.7. Který je nakonfigurovaný jako FGCP cluster a využívá VDOM Partitioning (Virtual clustering). A právě VDOM Partitioning se nakonec ukázal jako důvod problému s IPsec Rekey.

Pozn.: Dostal jsem několik doplnění a informací od certifikovaného Fortinet experta, takže jsem je doplnil do článku.

Základní pojmy a principy IPsec VPN

Dokumentace

Přesné informace nalezneme v RFC k jednotlivým oblastem, kterých je mnoho. Některé popisy na internetu

IPsec VPN

VPN - Virtual Private Network - hlavní typy

  • Site to Site VPN - dvě brány (Peers) navazují statický tunel
  • Remote Access VPN - klient navazuje tunel na vyžádání (On-demand) k bráně

IPsec - Internet Protocol Security

  • standardizovaná skupina protokolů (protocol suite) pro zabezpečení komunikace mezi dvěma koncovými systémy v IP sítích
  • obsahuje obousměrnou autentizaci a vyjednání kryptografických metod a klíčů (autentizuje a šifruje pakety)
  • můžeme využít řadu standardních protokolů a algoritmů

Hlavní protokoly používané v IPsec

  • IKE - Internet Key Exchange - protokol používaný k nastavení SA při vyjednávání IPsec (zde se bavíme hlavně o IKEv2), využívá ISAKMP (Internet Security Association and Key Management Protocol) a Oakley protokol, pro komunikaci používá UDP port 500
  • ESP - Encapsulated Security Payload - vlastní šifrovaná komunikace, používá protokol IP číslo 50

Zjednodušeně se pomocí IKE vyjedná SA a z jeho parametrů naváže šifrovaný tunel pomocí ESP.

IPsec módy zapouzdření (Encapsulation Modes)

  • Tunnel mode - šifruje celý paket (včetně hlavičky) a doplňuje novou hlavičku, standardně pro Site to Site VPN
  • Transport mode - šifruje pouze data, IP hlavička se ponechá a doplní se pouze IPsec hlavička, standardně pro Remote Access VPN

Bezpečnostní atributy a algoritmy

SA - Security Association

  • sdílené bezpečnostní atributy, jako jsou šifrovací algoritmy, klíče a parametry (Packet Sequence Number)
  • vytvoří se vyjednáním pomocí IKE (každá fáze má svoje, takže se využívá IKE SA a IPsec SA)
  • každé SA má identifikátor Security Parameter Index (SPI), index do Security Association DataBase (SADB), které je předáno druhé straně
  • SA se používá pro jednosměrnou komunikaci, pro obousměrnou potřebujeme dvě

Autentizační metody

  • PSK - PreShared Key - Shared Secret - textový řetězec
  • RSA certifikát - veřejný a privátní klíč
  • EAP- Extensible Authentication Protocol

Typy algoritmů a příklady

  • šifrování (Encryption) - DES, 3DES, AES128, AES256, AES256GCM, CHACHA20/POLY1205
  • výměna klíčů (Key exchange) - metoda Diffie-Hellman (vytvoří shared session secret a z něj se odvodí šifrovací klíče), používají se různé DH group
  • autentizace (Authentication) / integrita (Integrity) - využívá hashovací funkce MD5, SHA1, SHA256, SHA512 (někde se používá termín autentizace a někde integrita, také se mluví o využití HMAC, třeba HMAC-SHA256)
  • Pseudo-Random Function (PRF) - obdoba algoritmu integrity, nepoužívá se pro ověřování zpráv, ale zajištění náhodnosti, používá se ve Phase 1, využívá hashovací funkce SHA1, SHA256, SHA512
  • Perfect Forward Secrecy (PFS) - volitelné rozšíření zabezpečení Phase 2, standardně jsou klíče fáze 2 odvozeny od klíčů fáze 1, PFS provede novou výměnu klíčů pomocí Diffie-Hellman, volíme DH group

Pokud se v IKE použije autentizovaný šifrovací algoritmus jako je AES256GCM, tak se nenastavuje autentizační algoritmus. Pro IKEv2 Phase 1 se místo autentizačního algoritmu nastavuje PRF.

Pozn.: V debugu jsem narazil na to, že ač bylo na obou stranách nastaveno PFS pro Phase 2, tak se v Proposal uvádělo PFS is disabled. Našel jsem informaci, která říká, že klíče pro CHILD_SA, které je vytvořeno při IKE_AUTH, jsou vždy odvozeny od IKE klíčů (Phase 1). Teprve při Rekey (CREATE_CHILD_SA) se PFS použije a je vidět při debugu. Některé systémy proto hned po úvodním navázání (IKE_AUTH) provedou nové vyjednání IPsec SA (CREATE_CHILD_SA), aby obsahovalo PFS.

IKE Phase 1 a Phase 2

Proposal (návrh)

  • používá se v IKE Phase 1 a Phase 2, označuje se také jako IKE Proposal a IPsec nebo Child SA Proposal
  • může obsahovat jednu nebo více položek (podporovaných variant)
  • obsahuje určení protokolu, pro Phase 1 standardně IKEv1 nebo IKEv2, pro Phase 2 běžně ESP, zapouzdření (Encapsulation) pro Phase 2 Tunnel nebo Transport
  • dále obsahuje šifrovací algoritmus, algoritmus integrity / autentizace nebo PRF (Phase 1), Diffie-Hellman group nebo PFS (Phase 2), ve Phase 2 také, zda se má použít ESN (Extended Sequence Number)

Key Lifetime

  • délka platnosti klíčů SA
  • IKEv1 vyjednává společný Lifetime, IKEv2 každý Peer používá svůj nastavený Lifetime
  • Phase 1 Lifetime musí být větší než Phase 2 Lifetime
  • FortiOS dovoluje rozsah 120 až 172800 sekund (pro Phase 2 se může nastavit počet bajtů provozu)
  • nastavená hodnota Lifetime se označuje jako Hard SA Lifetime, používá se ještě Soft SA Lifetime, což je hodnota o něco nižší a při ní může dojít k vyjednání nového SA

Rekey a Reauth

  • pokud vyprší SA Lifetime (Hard), tak se SA maže, následně se musí nově navazovat, pokud má fungovat komunikace
  • při vypršení Soft SA Lifetime může dojít k rekey nebo reauthentiction
  • Rekey se pokusí vytvořit novou sadu klíčů (CREATE_CHILD_SA), které se mohou za běhu vyměnit a nedojde k výpadku, podporováno v IKEv2
  • Reauth provede kompletní nové vytvoření včetně autentizace (IKE_SA_INIT a IKE_AUTH), může přerušit provoz, v IKEv2 je možné, aby proběhlo bez výpadku
  • Phase 2 SA se vyjednává pouze pokud existuje provoz (traffic), také k Rekey dojde pouze pokud existuje provoz, jinak jde tunel dolů, Fortinet má řešení, aby oboje nastalo bez existujícího provozu, Auto-negotiate a Autokey Keep Alive

IPsec VPN tunel se navazuje ve dvou fázích

  • Phase 1 - IKE Policy
    • vyjedná se IKE SA
    • naváže bezpečné spojení pro výměnu autentizačních informací
    • provede se ověření (autentizace)
    • zadáváme IP adresy naší a vzdálené brány, verzi IKE, autentizační údaje, Phase 1 Proposal, Key Lifetime
    • můžeme použít NAT Traversal, Dead Peer Detection (DPD)
  • Phase 2 - IPsec Policy
    • vyjedná se IPsec SA (je chráněno existujícím IKE SA)
    • vytvoří VPN tunel
    • definujeme jeden nebo více Phase 2 Selector a k nim Phase 2 Proposal

Phase 2 Selector

  • kombinace zdrojového a cílového subnetu
  • můžeme definovat jednu nebo více kombinací adres, tím omezíme, jaká komunikace může tunelem procházet
  • nebo může vytvořit Selector pro všechny adresy 0.0.0.0/0
  • provádí vyjednání SA (pro každý Selector je samostatné SA)

Pozn.: IKEv1 používá ve Phase 1 Main Mode nebo Aggressive Mode a ve Phase 2 Quick Mode. Proto se někde používá označení Quick Mode Selectors.

NAT-T - Network Address Translation - Traversal

  • IPsec pakety jsou chráněny proti změně (hash)
  • NAT modifikuje IP hlavičku (IP adresy), takže nesouhlasí hash
  • NAT-T provede zapouzdření do UDP, přidá hlavičku, která může být měněna, ta je u příjemce odstraněna
  • při IKE vyjednání se může domluvit, že obě strany používají NAT-T
  • komunikace standardně používá UDP port 4500 (označuje se IPsec over UDP nebo IPsec over NAT-T)

Dead Peer Detection (DPD)

  • pravidelné kontroly, zda je IKE Peer na druhé straně tunelu stále naživu
  • pokud kontrola selže, tak je tunel ukončen a pokusí se o nové vyjednání
  • používá IKE Phase 1 notification (R-U-THERE)

Initiator vs. Responder

  • Initiator - strana, která iniciuje IPsec tunel, spustí IKE vyjednávání
  • Responder - strana, která přijme první IKE zprávy
  • navazování tunelu může probíhat automaticky (standardně při příchodu provozu v rámci VPN) nebo manuálně
  • Responder Only - můžeme nastavit, že pouze reagujeme na navázání tunelu z druhé strany
  • Initiator Only - někde je možno nastavit, že pouze navazujeme tunel

Internet Key Exchange version 2 (IKEv2) zprávy

IKEv2 (oproti IKEv1) úplně nepoužívá Phase 1 a Phase 2. Některé dokumentace nemluví o fázích, ale o IKE SA a CHILD SA. Při výměně paketů je spojená autentizace s vyjednáním prvního IPsec SA (CHILD SA) do jedné zprávy. Tedy se spojuje část Phase 1 a Phase 2 (je tedy otázka, zda níže IKE_AUTH zařadit spíše do fáze 1 nebo 2). Vždy jde o výměnu zpráv Initiatior Request - Responder Response.

Průběh IKEv2 zpráv

  • Phase 1 - IKE_SA - úspěšným výsledkem je šifrované spojení, ale vzdálená strana (Remote Peer) není ověřena (authenticated)
    • dvojice zpráv IKE_SA_INIT - vyjedná šifrovací algoritmy, provede Diffie-Hellman výměnu
  • Phase 2 - CHILD_SA (IPsec SA)
    • dvojice zpráv IKE_AUTH - provede autentizaci a založí první CHILD_SA podle Phase 2 Selector (podle typu autentizace se může vyměnit více IKE_AUTH zpráv)
    • dvojice zpráv CREATE_CHILD_SA - pokud máme více Phase 2 Selector (lokálních a vzdálených subnetů), tak se použije k založení dalšího CHILD_SA, také se používá pro CHILD_SA rekey
    • dvojice zpráv INFORMATIONAL - slouží k výměně kontrolních zpráv souvisejících s chybou nebo upozornění na události

Route-based vs Policy-based VPN

Dokumentace IPsec VPN overview - Types of VPNs, IPsec VPN - Defining security policies

Dozvěděl jsem se, že IPsec VPN lze konfigurovat dvěma různými způsoby (IPsec Operation Modes). Novějsí, přehlednější a s více funkcemi je Route-based přístup. Jediná výhoda Policy-based je to, že je podporován, pokud máme FortiGate v Transparent módu. Mělo by fungovat i to, že na jedné straně IPsec tunelu máme použit Route-based a na druhé Policy-based. Vždy ovšem záleží na použitých zařízeních (výrobce).

Fortinet o tom v dokumentaci příliš nepíše (třeba v příkladech konfigurace IPsec VPN ve FortiOS 6.2.3 Cookbook najdeme pouze jednu malou zmínku). Fortinet preferuje Route-based VPN a defaultně v GUI můžeme konfigurovat pouze tuto. Pokud chceme nastavit Policy-based IPsec VPN, tak musíme nejprve povolit ve Feature Visibility.

Popis z Fortinet dokumentace:

  • Route-based VPN nebo také Interface-based VPN
    • vytváří virtuální IPsec síťové rozhraní (VTI - Virtual Tunnel Interface), které aplikuje šifrování nebo dešifrování na veškerý přenášený provoz
    • nastavujeme statické směrování (static route) pro VPN interface a cílové subnety
    • pro komunikaci oběma směry musíme vytvořit dvě politiky, aby mohla komunikace procházet tunelem
    • podporuje dynamické routovací protokoly
  • Policy-based VPN nebo také Tunnel-mode VPN
    • definujeme speciální politiku (Security Policy, akce IPsec místo Allow), která aplikuje šifrování
    • jedna politika umožní komunikaci oběma směry, akce je IPsec a přiřazujeme VPN tunnel

Na FortiGate se Route-based VPN konfiguruje pomocí příkazů

config vpn ipsec phase1-interface
config vpn ipsec phase2-interface

Kdežto pro Policy-based VPN se používá

config vpn ipsec phase1
config vpn ipsec phase2

Pro Route-based VPN jsem narazil na rozdílné informace ke dvěma otázkám. V případě FortiGate je to jedno, ale pokud je na druhé straně jiné zařízení, tak může být potřeba použít jednu určitou možnost.

  • zda se mají ve Phase 2 Selector přesně definovat subnety (a tak omezit možnou komunikace, dále řešíme politikou) nebo použít všechny adresy 0.0.0.0/0
  • zda se na virtuálním tunnel interface (VTI), které vznikne pro VPN, musí použít adresy a určitý spojovací subnet (příklad IP 192.168.0.1, Remote IP 192.168.0.2/30), nebo necháme prázdné

Našel jsem příklady konfigurace, kde zmiňují, že pro Route-based VPN se subnet nesmí definovat. Co jde do VPN určujeme pomocí statických route. Fortinet v dokumentaci obsahuje obě varianty, s definovaným subnetem i se všemi adresami.

Podobně je možné, že třeba VPN tunel mezi FortiGate a Cisco ASA vyžaduje nastavení adres na interface VTI. Ale pro běžnou VPN FortiGate a FortiGate nastavovat nemusíme. Existují speciální situace, kdy je adresování potřeba (třeba když se má adresa rozhraní použít jako odchozí adresa nebo při dynamickém routingu). Jsou také metody pro automatické adresování IKE Mode Config a DHCP over IPsec.

Konfigurace na FortiGate

Dokumentace FortiOS 6.2.7 Cookbook - IPsec VPNs, FortiOS 6.2.7 CLI Reference - config vpn ipsec phase1-interface, FortiOS 6.0.0 Handbook - IPsec VPN from the GUI

Základní konfigurace IPsec VPN není na FortiGate složitá. Většinu věcí můžeme nastavit pomocí GUI, pouze pár speciálních nastavení se musí provést v CLI. Můžeme využít průvodce (IPsec Wizard), ale mnoho návodů doporučuje VPN vytvářet jako typ Custom.

Příklad vytvoření Site to Site IPsec VPN pomocí GUI

  • (VDOM) > VPN > IPsec Tunnels

Následující obrázky jsou z FortiOS 6.2.7. Vytváří se Route-based VPN (volba Policy-based IPsec VPN není zapnuta ve Feature Visibility).

FortiGate IPsec VPN Creation Wizard

V průvodci zadáme jméno VPN tunelu, to se použije také pro Virtual Tunnel Interface. Zvolíme typ Custom a následně se dostaneme přímo do nastavení parametrů, které jsou děleny na sekce.

FortiGate IPsec VPN Phase 1 Network a Authentication

Zadáváme IP adresu vzdálené brány a volíme lokální rozhraní, přes které se bude vzdálený Peer připojovat. Jako IP adresa lokální VPN brány se defaultně použije IP adresa zvoleného rozhraní. Pokud chceme nastavit jinou adresu, tak zvolíme Local Gateway. Můžeme vybrat Secondary IP address nastavené na rozhraní nebo zadat libovolnou adresu (v tom případě musí být adresa nějak aktivovaná, aby na ní FortiGate poslouchal).

Technical Tip: Forward Error Correction for IPsec VPN, Adding IPsec aggregate members in the GUI

Speciální nastavení je Mode Config pro automatickou konfiguraci Dialup klientů Supporting IKE Mode Config clients.

FortiGate IPsec VPN Phase 1 Proposal

V části Phase 1 Proposal můžeme nastavit jednu nebo více kombinací šifrování a autentizace (integrita). Pokud zvolíme šifrovací algoritmus AES128GCM, AES256GCM nebo CHACHA20/POLY1305, tak místo autentizace nastavujeme PRF (pořád jde o hashovací fuknci).

FortiGate IPsec VPN Phase 1 Proposal PRF

K tomu vybíráme povolené Diffie-Hellman Group. Nastavujeme Key Lifetime fáze 1 (IKE SA).

FortiGate IPsec VPN Phase2 Selector / Proposal

Jako Phase 2 Selector zadáme pojmenovanou dvojici lokálních a vzdálených adres. K tomu definujeme jeden nebo více Phase 2 Proposal. Pro AES128GCM, AES256GCM nebo CHACHA20/POLY1305 se nezadává autentizace. Dále můžeme zapnout PFS a určit Diffie-Hellman Group. Zapnout Replay Detection proti Replay Attacks.

Funkce Auto-negotiate zajistí inicializaci vyjednání Phase 2 SA bez provozu na síti. Funkce Autokey Keep Alive zajistí provedení Rekey, když se blíží vypršení Phase 2 SA, bez provozu na síti.

FortiOS 6.2.7 Cookbook - Phase 2 configuration, Using the IPSec auto-negotiate and keepalive options

Pozn.: Na FortiGate nenastavujeme IPsec protokol, protože podporuje pouze ESP. Defaultně také používá zapouzdření (Encapsulation) Tunnel Mode.

Více subnetů - Phase 2 Selectors

Před časem jsem potřeboval vytvořit IPSec VPN, kde na druhé straně tunelu jsou dva subnety. Ve Fortinet dokumentaci jsem našel, že je třeba vytvořit Address Group, kam se zařadí jednotlivé subnety. V konfiguraci VPN se vybere Named Address a daná skupina. Monitoring ukazoval, že má VPN dva Phase 2 Selectors, takže by asi mělo fungovat, ale navazoval se pouze jeden. Podle informací to takto nefunguje, když je na druhé straně Cisco.

Funkční řešení bylo vytvořit pomocí CLI pod stejnou Phase 1 samostatně dvě Phase 2. Na několika místech to také uvádí Fortinet dokumentace, Technical Tip: IPSec VPN between a FortiGate and a Cisco ASA with multiple subnets.

Zdálo se mi, že v GUI nelze dva selektory vytvořit. Po jejich vytvoření v CLI se zde zobrazí a je možno je editovat. Přidání dalšího selektoru (Add) je k dispozici pouze, když nemáme skupinu otevřenou.

FortiGate IPsec VPN Phase2 Selector Add

Statické směrování - Static Route

  • (VDOM) > Network > Static Routes

Další krok je vytvořit statickou route pro cílovou síť (subnet), která má být dostupná skrze VPN. Zadáme Subnet a jako rozhraní vybereme Virtual Tunnel Interface (VTI) pro naši VPN.

Pro některé případy nemusíme směrování nastavovat ručně, ale můžeme využít dynamický routovací protokol (BGP nebo OSPF). Nebo nastavit, že si FortiGate vytvoří záznam podle přijatého Phase 2 Selector.

config vpn ipsec phase1-interface
   edit VPN-name
       set add-route enable
   next
end

Politiky - Firewall Policy

  • (VDOM) > Policy & Objects > IPv4 Policy

Aby skrze VPN mohla procházet komunikace, tak musíme vytvořit odpovídající politiky. Ze síťového rozhraní interní sítě do VTI IPsec VPN a naopak. Standardně bez NATu. Pokud neexistuje politika, tak nejde VPN navázat.

ike 2:VPNtest: ignoring request to establish IPsec SA, no policy configured

Síťové rozhraní - Network Interface

  • (Global/VDOM) > Network > Interfaces

Pokud je v dané konfiguraci potřeba, tak na Virtual Tunnel Interface nastavíme IP adresu naší a vzdálené brány. VTI se nachází pod rozraním, na kterém je VPN vytvořena.

Nastavení Responder Only

Dokumentace Technical Tip: IPsec VPN response only in phase-1

Pokud chceme, aby FortiGate pouze čekal na IKE vyjednání vzdálené strany, tak můžeme nastavit pomocí CLI.

config vpn ipsec phase1-interface
    edit VPN-name
       set auto-negotiate disable
    next
end

HA (FGCP) cluster a IPsec VPN

Dokumentace FortiOS 6.2.7 Cookbook - IPsec VPN in an HA environment, FortiOS 6.0.0 Handbook - IPsec VPN SA sync

Pokud provozujeme FGCP cluster, tak můžeme nastavit Session Failover (Pickup), kdy se mezi členy clusteru synchronizují session určitých protokolů, patří sem i synchronizace IPsec SA. Pokud dojde k HA Failover (přepnutí), tak nemá být přerušen IPsec VPN provoz.

Podle popisu bych chápal, že když je Session Failover (Pickup) vypnutý, tak se nebude synchronizovat ani IPsec SA. Ale pokud zapneme debug IKE, tak vidíme mnoho zpráv o synchronizaci a je zde i řada chyb.

config system ha
    set session-pickup disable
end

Pro fungování Session Failover je potřeba také zapnutá synchronizace ESP Sequence Numbers (výchozí nastavení je zapnuto).

config vpn ipsec phase1-interface
    edit JMENO
        set ha-sync-esp-seqno enable
    next
end

Pokud máme zapnutý debug a provedeme restart IKE, tak se zaloguje.

ike 0: HA syncing enabled
ike 1: HA state change detected -> master
ike 1: HA syncing enabled

V debugu se nachází mnoho zpráv, které odhaduji, že se týkají synchronizace spojení a SA. I když filtrujeme výstup pro určitý VPN tunel, tak tyto HA zprávy se zobrazují pro všechny tunely. Níže je příklad HA logů při korektním fungování Active-Passive cluster (proběhlo clear tunelu a nové navázání).

Master Node

ike 2:VPNtest:9665: HA send IKE SA del d239ff6252ee86df/45755640c64a91f4
ike 2:VPNtest: HA send IKE connection add X.X.X.X->Y.Y.Y.Y
ike 2:VPNtest:9666: HA send IKE SA add da32bee3295fc2c7/49815d13129c5bf8
ike 2:VPNtest: HA send IKEv2 message ID update send/recv=0/2
ike 2:VPNtest: HA IPsec send ESP seqno 1

Slave Node

ike 2:VPNtest: HA del IKE SA d239ff6252ee86df/45755640c64a91f4
ike 2:VPNtest: deleting IPsec SA with SPI 678def9b
ike 2:VPNtest:VPNtest: deleted IPsec SA with SPI 678def9b, SA count: 0
ike 2: HA add conn, unsupported type 144
ike 2: HA add conn, unsupported type 145
ike 2:VPNtest: HA IKE add conn
ike 2:VPNtest: deleting
ike 2:VPNtest: flushing 
ike 2:VPNtest: flushed 
ike 2:VPNtest: deleted
ike 2:VPNtest: set oper down
ike 2:VPNtest: HA add new connection X.X.X.X->Y.Y.Y.Y
ike 2:VPNtest: HA add IKE SA da32bee3295fc2c7/49815d13129c5bf8
ike 2:VPNtest:9666: HA add IKE SA done
ike 2:VPNtest: set oper up
ike 2:VPNtest:VPNtest: HA add IPsec SA 154ced4e/9ef46b80 seq 1 1
ike 2:VPNtest:VPNtest: src 0 7 0:0.0.0.0-255.255.255.255:0
ike 2:VPNtest:VPNtest: dst 0 7 0:0.0.0.0-255.255.255.255:0
ike 2: HA receive seqno update send/recv=0/2
ike 2:VPNtest: carrier up
ike 2:VPNtest:: HA del IPsec SA 9ef46b80
ike 2:VPNtest: deleting IPsec SA with SPI 9ef46b80
ike 2:VPNtest:VPNtest: deleted IPsec SA with SPI 9ef46b80, SA count: 0
ike 2:VPNtest: HA IPsec receive ESP seqno 1, updating to 47868c01

Při zapnutém VDOM Partitioning (chybném fungování) se na Master Node objevovaly zprávy níže. 

ike 2:VPNtest: HA send IKE connection add X.X.X.X->Y.Y.Y.Y
ike 2:VPNtest:2014: HA send IKE SA add 07d1d5afe37a6977/e88c7b2c40f3e162
ike 2:VPNtest:2014: deleting HA IKEv2 SA b88da824d5851609/359afb17f1288b7e
ike 2:VPNtest:2006: HA send IKE SA del b88da824d5851609/359afb17f1288b7e
ike 2:VPNtest: HA send IKEv2 message ID update send/recv=2/0
ike 2: HA add conn, unsupported type 144
ike 2: HA add conn, unsupported type 145
ike 2:VPNtest: HA IKE add conn
ike 2:VPNtest: HA add IKE SA 07d1d5afe37a6977/e88c7b2c40f3e162
ike 2:VPNtest:2014: HA add IKE SA done
ike 2:VPNtest: HA del IKE SA b88da824d5851609/359afb17f1288b7e
ike 2:VPNtest:: HA del IPsec SA f7738b0b
ike 2:VPNtest:VPNtest: HA add IPsec SA 154cd2cc/a6e192b3 seq 1 1
ike 2: HA receive seqno update send/recv=2/0
ike 2:VPNtest: HA IPsec send ESP seqno 47868c01
ike 2:VPNtest: HA IPsec master ignored unexpected ESP seqno update
ike 2:VPNtest:2006: ignoring message on HA synced IKE_SA
ike 2:VPNfg:1974: have HA IKE SA, attempting message ID sync

Konfigurace v CLI

Pouze ukázka částí testovací konfigurace.

Parametry Phase 1

config vpn ipsec phase1-interface
    edit "VPNtoTest"
        set interface "Internet1"
        set ike-version 2
        set local-gw X.X.X.X
        set peertype any
        set net-device disable
        set proposal aes256-sha512
        set dhgrp 21
        set nattraversal disable
        set remote-gw Y.Y.Y.Y
        set psksecret ENC zzzzzz
    next
end

Parametry Phase 2

config vpn ipsec phase2-interface
    edit "VPNtoTest"
        set phase1name "VPNtoTest"
        set proposal aes256-sha512
        set dhgrp 21
        set replay disable
        set keepalive enable
        set keylifeseconds 600
    next
end

Firewall Policy

config firewall policy
    edit 56
        set name "To Test VPN"
        set uuid zzzzzz
        set srcintf "VPNtestLocalZone"
        set dstintf "VPNToTest"
        set srcaddr "VPNtestLocalNetwork"
        set dstaddr "VPNtestRemoteNetwork"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
    edit 57
        set name "From Test VPN"
        set uuid zzzzzz
        set srcintf "VPNToTest"
        set dstintf "VPNtestLocalZone"
        set srcaddr "VPNtestRemoteNetwork"
        set dstaddr "VPNtestLocalNetwork"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end

Static Route

config router static
    edit 8
        set dst 192.168.0.0 255.255.255.0
        set device "VPNtoTest"
    next
end

Defaultní hodnoty se ve výpisu nezobrazují, takže se hodí zobrazit kompletní výpis pomocí:

show full-configuration

Výpis Phase 1 a Phase 2

config vpn ipsec phase1-interface
    edit "VPNtoTest"
        set type static
        set interface "Internet1"
        set ip-version 4
        set ike-version 2
        set local-gw X.X.X.X
        set keylife 86400
        set authmethod psk
        unset authmethod-remote
        set peertype any
        set net-device disable
        set passive-mode disable
        set exchange-interface-ip disable
        set aggregate-member disable
        set mode-cfg disable
        set proposal aes256-sha512
        set localid ''
        set localid-type auto
        set auto-negotiate enabled
        set negotiate-timeout 30
        set fragmentation enable
        set ip-fragmentation post-encapsulation
        set dpd on-demand
        set forticlient-enforcement disable
        set comments ''
        set npu-offload enable
        set dhgrp 21
        set suite-b disable
        set eap disable
        set ppk disable
        set wizard-type custom
        set reauth disable
        set idle-timeout disable
        set ha-sync-esp-seqno enable
        set auto-discovery-sender disable
        set auto-discovery-receiver disable
        set auto-discovery-forwarder disable
        set encapsulation none
        set nattraversal disable
        set fragmentation-mtu 1200
        set childless-ike disable
        set rekey enable
        set network-overlay disable
        set remote-gw Y.Y.Y.Y
        set monitor ''
        set tunnel-search selectors
        set add-gw-route disable
        set psksecret ENC ...
        set dpd-retrycount 3
        set dpd-retryinterval 20
    next
end
config vpn ipsec phase2-interface
    edit "VPNtoTest"
        set phase1name "VPNtoTest"
        set proposal aes256-sha512
        set pfs enable
        set ipv4-df disable
        set dhgrp 21
        set replay disable
        set keepalive enable
        set auto-negotiate disable
        set auto-discovery-sender phase1
        set auto-discovery-forwarder phase1
        set keylife-type seconds
        set encapsulation tunnel-mode
        set comments ''
        set protocol 0
        set src-addr-type subnet
        set src-port 0
        set dst-addr-type subnet
        set dst-port 0
        set keylifeseconds 600
        set src-subnet 0.0.0.0 0.0.0.0
        set dst-subnet 0.0.0.0 0.0.0.0
    next
end

Dohled, Troubleshooting a Debug IPsec VPN

Dokumentace Technical Tip: Troubleshooting IPsec VPNs, FortiOS 6.0.0 Handbook - Troubleshooting, FortiOS 6.2.7 Cookbook - VPN IPsec troubleshooting

Pozn.: Pokud provozujeme HA (FGCP) cluster, tak je dobré (a někdy nutné) pracovat na aktivním FortiGate (VDOM Master Node, kde je daná VDOM aktivní)

Monitorování

  • (VDOM) > Monitor > IPsec Monitor

Zde můžeme sledovat stav a základní údaje o VPN. Můžeme také shodit nebo nahodit VPN. Pokud klikneme pravým tlačítkem do hlavičky tabulky, tak můžeme zobrazit další sloupce.

FortiGate IPsec Monitor

Logy událostí

  • (VDOM) > Log & Report > Events

Vpravo nahoře přepneme zobrazení na VPN Events. Jsou zde základní události jako negotiate IPsec phase 1, IPsec phase 2 status change - phase2-down, phase2-up, IPsec connection status change - tunnel-up. Ale chybí detaily, například proč se nepovede navázat Phase 1. Pro více detailů musíme využít debug.

Pozn.: Moc nechápu proč, ale IPsec VPN komunikace není vidět v Traffic logu.

Zjištění informací o VPN tunelu

Pozn.: Na konci článku jsou příklady výstupu jednotlivých příkazů.

Seznam IPsec tunelů

get vpn ipsec tunnel summary

Detaily o tunelu

Zobrazí hlavní informace o IPsec tunelu, jako IP adresy, typ (Route-based), mód (IKEv2), přenesená data, DPD, Phase 2 Selector, jeho SA včetně SPI, Lifetime a čas do Rekey, algoritmy.

get vpn ipsec tunnel name JMENO

Zobrazí stav tunelu, způsob ověření, IP adresy, stručné údaje o Phase 2.

diagnose vpn ike config list summary

Informace o Phase 1 daného tunelu (dva příkazy pro téměř stejný výsledek)

Často používané. Zobrazí informace o Phase 1 - adresy, čas vytvoření, počet IKE SA a IPsec SA, detaily o IKE SA včetně SPI, směr navázání (zda jde o Responder nebo Initiator), stav, použitý Proposal (algoritmy), Lifetime a Rekey (Soft Lifetime), DPD.

diagnose vpn ike gateway list name JMENO
get vpn ike gateway JMENO

Informace o Phase 2 daného tunelu

Často používané. Zobrazí základní informace o tunelu (Phase 1) a pak detaily o Phase 2 - Selector, jeho SA včetně SPI, Lifetime (Hard/Soft), čas do exspirace, algoritmy a klíče, NPU (hardware akcelerace).

diagnose vpn tunnel list name JMENO

Operace s tunelem

Restart IKE (všechny tunely se ukončí)

diagnose vpn ike restart

Vyčištění (ukončení) IPsec tunelu (buď všechny tunely nebo vyjmenovaný, místo clear můžeme stejně využít flush)

diagnose vpn ike gateway clear
diagnose vpn ike gateway clear name JMENO

Vymazání Tunnel SA (patrně Phase 2 IPsec SA)

diagnose vpn tunnel flush JMENO

Shození (vypnutí) tunelu (dvě stejné možnosti, můžeme zadat pouze Phase2)

execute vpn ipsec tunnel down Phase2-name Phase1-name
diagnose vpn tunnel down Phase2-name Phase1-name

Aktivace tunelu (dvě stejné možnosti, můžeme zadat pouze Phase2)

execute vpn ipsec tunnel up Phase2-name Phase1-name
diagnose vpn tunnel up Phase2-name Phase1-name

Ping z určité adresy

Pro test VPN (nebo aktivaci tunelu) se může hodit vyvolat ping z IP adresy rozhraní, které je v našem rozsahu pro VPN.

execute ping-options source 172.19.14.1
execute ping 192.168.0.1

Debug - ladění

Pozn.: Na konci článku jsou příklady debugu.

Když řešíme jakýkoliv problém, tak nám nejvíce informací zobrazí, když zapneme debug daného protokolu. Špatné ovšem je, že Fortinet nemá žádnou dokumentaci ke zprávám (není ani pořádný popis zapnutí debugu), které se v debugu objeví. Většinu z nich nikde nenalezne ani Google. Takže můžeme pouze odhadovat podle významu klíčových slov, ale u chyb nevíme, co je způsobuje.

Můžeme nastavit filtrování IKE debugging log. První příkaz zobrazí nastavené filtry, druhý vymaže nastavení. Dále je několik možností, podle čeho filtrovat. Řada diskusí uvádí, že filtrování podle jména Phase 1 nefunguje a mohu to potvrdit. Použitelné je filtrování podle cílové IP adresy. I když máme zapnuté filtrování na určitou cílovou IP adresu a tedy VPN tunel (to funguje), tak se zobrazují zprávy související s HA pro všechny tunely. 

diagnose vpn ike log filter list
diagnose vpn ike log filter clear
diagnose vpn ike log-filter name JMENO
diagnose vpn ike log-filter dst-addr4 X.X.X.X

Můžeme zapnout zobrazení času u jednotlivých záznamů.

diagnose debug console timestamp enable

Zapnutí debugování IKE protokolu (na 30 minut) na nejvyšší stupeň (-1). V článku FortiOS 5.6.0 Cookbook - Results radí použít hodnotu 63, která z výstupu odstraní encryption hash, takže je přehlednější.

diagnose debug application ike -1
diagnose debug enable

Pro vypnutí debug režimu (a reset nastavení) můžeme použít

diagnose debug disable
diagnose debug reset

Souhrnně může vypadat zapnutí debugu

diagnose vpn ike log-filter dst-addr4 X.X.X.X
diagnose debug console timestamp enable
diagnose debug application ike 63
diagnose debug enable

Vypnutí a resetování nastavení

diagnose vpn ike log filter clear
diagnose debug disable
diagnose debug reset

Problémy s IPsec VPN

Autentizace certifikátem a SHA-2

Řešil jsem Site to Site VPN mezi FortiGate a Cisco Firepower. Pro autentizaci se využívá certifikát a Phase 1 Proposal s AES-256-GCM s PRF SHA512 (aes256gcm-prfsha512). Konfigurace VPN nebyl problém, ale tunel se nenavazoval. Důvod se zobrazil až při zapnutí debugu. Část událostí:

2020-07-01 08:29:07.977165 ike 1:JMENO:2924: certificate validation pending
2020-07-01 08:29:07.977755 ike 1:JMENO:2924: certificate validation complete
2020-07-01 08:29:07.977763 ike 1:JMENO:2924: certificate validation succeeded
2020-07-01 08:29:07.977899 ike 1:JMENO:2924: signature verification failed

K této chybě jsem našel jen nějaké staré diskuse, že s certifikátem je třeba použít SHA-1. Udělal jsem nějaké pokusy a funkční bylo

  • změnit autentizaci z certifikátu na Pre-shared Key (PSK)
  • ve fázi 1 použít libovolné šifrování, ale autentizaci nebo PRF SHA1

Nakonec přišel technik druhé strany s tím, že Cisco Firepower má nějaký speciální příkaz, který povolí pro fázi 1 SHA-512, ale pro hashování odpovědi s certifikátem použít SHA-1. Tunel se pak navázal s požadovaným nastavením.

Nefunkční Rekey IKEv2 IPSec VPN

IPsec tunel, zmíněný výše, řadu měsíců docela fungoval. Pak se začal dost intenzivně využívat a došlo k malé konfigurační změně, pouze se vyměnil autentizační certifikát. A najednou začal problém, když mělo dojít k Rekey Phase 2 (IPsec SA), tak přestala tunelem procházet komunikace. FortiGate ukazoval tunel stále navázaný, ale na straně Cisco se hlásil dole.

Provedli jsme úpravu konfigurace na korektní Route-based IPsec VPN a vše se hodně zlepšilo. Ale pořád, když mělo nastat Rekey, tak došlo k přerušení komunikace. VPN byla velmi důležitá, takže jsme nemohli pokračovat v pokusech. Dočasně se vyřešilo alternativním způsobem. Ale vytvořili jsme testovací VPN mezi naším FortiGate clusterem a Cisco Firepower v labu.

Také jsem otevřel ticket na Fortinet Support. Zatím uběhlo více než 14 dní a reakce supportu je stejná, jako jsem popisoval FortiGate 6.2.3 bugy, debug a podpora.

Od začátku jsem tedy začal studovat fungování IPsecu a sepsal tento článek. A děláme pokusy a ladění na testovací VPN. Vypadá to, že problém je na straně FortiGate. K tomu dospěl i Cisco TAC, který analyzoval VPN spojení na druhé straně.

Mě připadá, že problém je ve fungování FGCP HA clusteru FortiGate (s Virtual clustering) a synchronizace IPsec SA. Když se blíží vypršení Phase 2 SA Lifetime, tak Cisco Firepower odesílá žádost o Rekey (CREATE_CHILD_SA). To je vidět na straně Cisco. Ale také při debugu Fortigate, kde je vidět příchozí zpráva, která se opakuje několikrát po sobě. Fortigate na to vždy loguje, že je zpráva ignorovaná.

ike 2: comes Y.Y:Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=CREATE_CHILD id=b88da824d5851609/359afb17f1288b7e:00000002 len=528
ike 2:VPNtest:2006: ignoring message on HA synced IKE_SA

Protože Cisco nedostane odpověď, tak vypne (Bring Down) Phase 1 (IKE SA). A začne kompletní vyjednání tunelu (IKE_SA_INIT), které se povede. To ale způsobí určitou nedostupnost tunelu. Pokud skrze VPN běží ping, tak dojde ke ztrátě 1 až 4 zpráv.

Pokud je situace opačně a FortiGate má provést Rekey, tak se podle logu na něj chystá, ale zjistí, že mu chybí IKE SA. Přitom, když si chvíli předtím vypíšeme údaje o Phase 1, tak vše vypadá v pořádku. Stejně jako v prvním případě, provede FortiGate kompletní nové vyjednání tunelu.

ike 2:VPNtest:VPNtest: IPsec SA f7738b0b/154cd2c6 rekey 59 X.X.X.X->Y.Y:Y.Y:0
ike 2:VPNtest:VPNtest: using existing connection
ike 2:VPNtest:VPNtest: config found
ike 2:VPNtest:VPNtest: IPsec SA connect 59 X.X.X.X->Y.Y:Y.Y:500 negotiating
ike 2:VPNtest: no suitable IKE_SA, queuing CHILD_SA request and initiating IKE_SA negotiation
ike 2:VPNtest:2014: sent IKE msg (SA_INIT): X.X.X.X:500-> Y.Y:Y.Y:500, len=260, id=07d1d5afe37a6977/0000000000000000

Všechny tyto informace jsem poslal na Support, včetně řady jasných dotazů. Na žádný dotaz jsem nedostal odpověď a jejich reakce jsou mimo. Doplním článek, pokud se situace změní.

Doplněno 19.4. 2021

Po třech týdnech jsem dostal od Fortinet Supportu reakci:

We suspect the reason why the proposal is rejected is somehow affected by the fact that the fortigate is part of an HA cluster. Would it be possible to fail over the units, swap the roles and confirm if the problem remains?

Tedy to, co jsem jim již nějakou dobu psal. Zkusit vypnout VDOM Partitioning (Virtual clustering) jsem zvažoval od doby, kdy jsem objevil chyby s HA, ale měl jsem obavu, jak moc to ovlivní provoz. Čekal jsem, že podpora přijde s lepším řešením, a z debug logu poznají, co přesně je problém. Nakonec jsem to zkusil a vypnutí popsal do FortiGate High Availability cluster a Virtual Domains (VDOM).

Mohu potvrdit, že po vypnutí VDOM Partitioning, kdy FGCP cluster začal fungovat jako klasický Active-Passive, začaly všechny IPsec VPN tunely fungovat korektně. Rekey IPsec SA (Phase 2) probíhá správně, nenavazuje se znovu IKE SA. V debug logu nejsou žádné zprávy o ignorování nebo chybějícím IKE SA. Ping v tunelu nemá žádný výpadek.

Znamená to tedy, že VDOM Partitioning (Virtual clustering), který mi přijde jako pěkná vlastnost, nefunguje dobře. Je to škoda, že Fortinet má řadu vlastností (které jsou tu již léta), které je lepší nepoužívat. Osobně mi vypnutí VDOM Partitioning nepřijde jako řešení problému, ale jako Workaround. Uvidím, jak bude reagovat podpora.

Doplněno 26.4. 2021

Reakce podpory byla opět směšná. Chtěli, abych znovu zkusil zapnout VDOM Partitioning, zda se problém vrátí. Pořád nechápu, že ve Fortinetu nejsou schopni si problém vyzkoušet ve svém labu. Udělal jsem pár testů.

Zapnul jsem VDOM Partitioning, ale priority obou clusterů nastavil stejně, takže pořád zůstaly všechny VDOM na stejném FortiGate (Master byl pro oba clustery stejný). Změnil jsem prioritu pro druhý virtuální cluster, takže se VDOM s IPsec VPN tunely přesunula na druhý node. Okamžitě se projevil popisovaný problém IPsec VPN.

Vrátil jsem prioritu pro druhý virtuální cluster, VDOM se přesunula zpět (všechny byly na stejné jednotce). V tu chvíli problémy zmizely a IPsec VPN fungovala korektně.

Doplněno 29.4. 2021

Odmítl jsem dělat bezplatného testera Fortinetu a odsouhlasil jsem jim uzavření ticketu bez vyřešení.

Reálné příklady výstupu informačních příkazů

FW2 (FWEXT) # get vpn ipsec tunnel summary

'VPNtest' Y.Y.Y.Y:0 selectors(total,up): 1/1 rx(pkt,err): 1/0 tx(pkt,err): 10/0

FW2 (FWEXT) # get vpn ipsec tunnel name VPNtest

gateway
  name: 'VPNtest'
  type: route-based
  local-gateway: X.X.X.X:0 (static)
  remote-gateway: Y.Y.Y.Y:0 (static)
  mode: ike-v2
  interface: 'Internet1' (59)
  rx  packets: 1  bytes: 172  errors: 0
  tx  packets: 10  bytes: 840  errors: 0
  dpd: disabled
  selectors
    name: 'VPNtest'
    auto-negotiate: disable
    mode: tunnel
    src: 0:0.0.0.0/0.0.0.0:0
    dst: 0:0.0.0.0/0.0.0.0:0
    SA
      lifetime/rekey: 600/150   
      mtu: 1422
      tx-esp-seq: 1
      replay: disabled
      qat: 0
      inbound
        spi: 154ccf99
        enc:  aes-cb  53a58d31cf4cd87514472d525089af1be2e3df8a661d29976baf748035becae6
        auth: sha512 df7d3307ff818668ee31a6f9a49d394b1c869d0f6c106f3af1231b97ba7e1a1afd0307ded0ae243c90ba16195d7ff393fb4a3450849374cb30ec703f8ee8823a
      outbound
        spi: bf67d15d
        enc:  aes-cb  061c2415262bbe26fce6ac8eb69f57563a49957931fc6d639d4217c2ae572b42
        auth: sha512  3babf1d32e39324d26ac4b9a3a1490706f6052151ac8a9de6b44488b63a5f53188056943f172b8b94e2d8dc548575504ed0b28a9493db5200d7c98685862dc49
      NPU acceleration: none

FW2 (FWEXT) # diagnose vpn ike config list summary

vd: FWEXT/2
name: VPNtest
serial: 3
version: 2
status.admin: up
status.operational: up
type: static
local: X.X.X.X
remote: Y.Y.Y.Y
mode: main
dpd: disabled
auth: psk
dhgrp:  21
xauth: none
interface: Internet1
virtual-interface-addr: 192.168.199.2 -> 192.168.199.1
auto-discovery-sender: disable
auto-discovery-receiver: disable
phase2s:
  VPNtest proto 0 src 0.0.0.0/0.0.0.0:0 dst 0.0.0.0/0.0.0.0:0  dhgrp 14  keep-alive  route-new
policy: yes

FW2 (FWEXT) # get vpn ike gateway VPNtest

vd: FWEXT/2
name: VPNtest
version: 2
interface: Internet1 59
addr: X.X.X.X:500 -> Y.Y.Y.Y:500
created: 489s ago
IKE SA  created: 1/1  established: 1/1  time: 0/0/0 ms
IPsec SA  created: 1/1  established: 1/1  time: 0/0/0 ms

  id/spi: 1169 e870277e2268318c/acb0001b24748673
  direction: responder
  status: established 489-489s ago = 0ms
  proposal: aes-256-sha512
  SK_ei: 3a83d24fab8f492e-ad914b1c46678cf5-3888fc9960303321-9feebc6df28fa2e6
  SK_er: a401942671d47623-6a4f692609b2ca87-59f2c1461cc6ed07-4390453c2697171b
  SK_ai: 14912c8eec3b0331-a9ee44ed7a3de18d-139206b22aa983ac-5f9067063500fa2a-0fce49e5baea07bf-3127112da547f587-35539d4d71c960a2-7ab822ca0963d51d
  SK_ar: d06391ab26ef3653-a3d5cda87eb44fb9-e738204c986dcabc-efa75f6e5d9cd38f-a44c45b7ead4989d-410dc247d496fed7-91ee40d7757dc7dc-ab1310a7ad744f8b
  lifetime/rekey: 86400/85640
  DPD sent/recv: 00000000/00000000

FW2 (FWEXT) # diagnose vpn ike gateway list name VPNtest

vd: FWEXT/2
name: VPNtest
version: 2
interface: Internet1 59
addr: X.X.X.X:500 -> Y.Y.Y.Y:500
virtual-interface-addr: 192.168.199.2 -> 192.168.199.1
created: 535s ago
PPK: no
IKE SA: created 1/1  established 1/1  time 0/0/0 ms
IPsec SA: created 1/1  established 1/1  time 0/0/0 ms

  id/spi: 1169 e870277e2268318c/acb0001b24748673
  direction: responder
  status: established 535-535s ago = 0ms
  proposal: aes256-sha512
  child: no
  SK_ei: 3a83d24fab8f492e-ad914b1c46678cf5-3888fc9960303321-9feebc6df28fa2e6
  SK_er: a401942671d47623-6a4f692609b2ca87-59f2c1461cc6ed07-4390453c2697171b
  SK_ai: 14912c8eec3b0331-a9ee44ed7a3de18d-139206b22aa983ac-5f9067063500fa2a-0fce49e5baea07bf-3127112da547f587-35539d4d71c960a2-7ab822ca0963d51d
  SK_ar: d06391ab26ef3653-a3d5cda87eb44fb9-e738204c986dcabc-efa75f6e5d9cd38f-a44c45b7ead4989d-410dc247d496fed7-91ee40d7757dc7dc-ab1310a7ad744f8b
  PPK: no
  message-id sent/recv: 0/2
  lifetime/rekey: 86400/85594
  DPD sent/recv: 00000000/00000000

FW2 (FWEXT) # diagnose vpn tunnel list name VPNtest

list ipsec tunnel by names in vd 2
------------------------------------------------------
name=VPNtest ver=2 serial=3 X.X.X.X:0->Y.Y.Y.Y:0 dst_mtu=1500
bound_if=59 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/520 options[0208]=npu frag-rfc  run_state=0 accept_traffic=1 overlay_id=0
proxyid_num=1 child_num=0 refcnt=13 ilast=191 olast=191 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=off on=0 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=VPNtest proto=0 sa=1 ref=2 serial=14
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  SA:  ref=3 options=25 type=00 soft=0 mtu=1422 expire=26/0B replaywin=0
       seqno=1 esn=0 replaywin_lastseq=00000000 itn=0 qat=0 hash_search_len=1
  life: type=01 bytes=0/0 timeout=580/600
  dec: spi=154ccf99 esp=aes key=32 53a58d31cf4cd87514472d525089af1be2e3df8a661d29976baf748035becae6
       ah=sha512 key=64 df7d3307ff818668ee31a6f9a49d394b1c869d0f6c106f3af1231b97ba7e1a1afd0307ded0ae243c90ba16195d7ff393fb4a3450849374cb30ec703f8ee8823a
  enc: spi=bf67d15d esp=aes key=32 061c2415262bbe26fce6ac8eb69f57563a49957931fc6d639d4217c2ae572b42
       ah=sha512 key=64 3babf1d32e39324d26ac4b9a3a1490706f6052151ac8a9de6b44488b63a5f53188056943f172b8b94e2d8dc548575504ed0b28a9493db5200d7c98685862dc49
  dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
  npu_flag=00 npu_rgwy=Y.Y.Y.Y npu_lgwy=X.X.X.X npu_selid=20 dec_npuid=0 enc_npuid=0
  run_tally=1

Reálné příklady debug logů IPsec VPN tunelu

Vytvořil jsem testovací Site to Site IPsec VPN mezi FortiGate clusterem s FortiOS 6.2.7 (IP X.X.X.X), VPN se jmenuje VPNfg, a starým FortiGate s FortiOS 5.6.8 (IP Y.Y.Y.Y), VPN se jmenuje VPNfg2.

Směr z FortiGate cluster na samostatný FortiGate

Pokud se VPN navazuje z FortiGate cluster (Initiator) na starý FortiGate (Responder), tak vše vypadá, že funguje dobře. Níže jsou debug logy.

Navázání tunelu (SA_INIT) - Initiator 

ike 2:VPNfg:VPNfg: chosen to populate IKE_SA traffic-selectors
ike 2:VPNfg: no suitable IKE_SA, queuing CHILD_SA request and initiating IKE_SA negotiation
ike 2:VPNfg:4039: sent IKE msg (SA_INIT): X.X.X.X:500->Y.Y.Y.Y:500, len=260, id=45a1740c06c3cfc5/0000000000000000
ike 2:VPNfg: HA del IKE SA 9f5b9daecb715a9f/0a9e39dfd071718c
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=SA_INIT_RESPONSE id=45a1740c06c3cfc5/1680a67638fca00e len=260
ike 2:VPNfg:4039: initiator received SA_INIT response
ike 2:VPNfg:4039: processing notify type FRAGMENTATION_SUPPORTED
ike 2:VPNfg:4039: incoming proposal:
ike 2:VPNfg:4039: proposal id = 1:
ike 2:VPNfg:4039:   protocol = IKEv2:
ike 2:VPNfg:4039:      encapsulation = IKEv2/none
ike 2:VPNfg:4039:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:VPNfg:4039:         type=INTEGR, val=AUTH_HMAC_SHA2_512_256
ike 2:VPNfg:4039:         type=PRF, val=PRF_HMAC_SHA2_512
ike 2:VPNfg:4039:         type=DH_GROUP, val=ECP521.
ike 2:VPNfg:4039: matched proposal id 1
ike 2:VPNfg:4039: proposal id = 1:
ike 2:VPNfg:4039:   protocol = IKEv2:
ike 2:VPNfg:4039:      encapsulation = IKEv2/none
ike 2:VPNfg:4039:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:VPNfg:4039:         type=INTEGR, val=AUTH_HMAC_SHA2_512_256
ike 2:VPNfg:4039:         type=PRF, val=PRF_HMAC_SHA2_512
ike 2:VPNfg:4039:         type=DH_GROUP, val=ECP521.
ike 2:VPNfg:4039: lifetime=86400
ike 2:VPNfg:4039: initiator preparing AUTH msg
ike 2:VPNfg:4039: sending INITIAL-CONTACT
ike 2:VPNfg:4039: sent IKE msg (AUTH): X.X.X.X:500->Y.Y.Y.Y:500, len=288, id=45a1740c06c3cfc5/1680a67638fca00e:00000001
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=AUTH_RESPONSE id=45a1740c06c3cfc5/1680a67638fca00e:00000001 len=272
ike 2:VPNfg:4039: initiator received AUTH msg
ike 2:VPNfg:4039: peer identifier IPV4_ADDR Y.Y.Y.Y
ike 2:VPNfg:4039: auth verify done
ike 2:VPNfg:4039: initiator AUTH continuation
ike 2:VPNfg:4039: authentication succeeded
ike 2:VPNfg:4039: processing notify type MESSAGE_ID_SYNC_SUPPORTED
ike 2:VPNfg:4039: established IKE SA 45a1740c06c3cfc5/1680a67638fca00e
ike 2:VPNfg: HA send IKE connection add X.X.X.X->Y.Y.Y.Y
ike 2:VPNfg:4039: HA send IKE SA add 45a1740c06c3cfc5/1680a67638fca00e
ike 2:VPNfg: set oper up
ike 2:VPNfg: schedule auto-negotiate
ike 2:VPNfg:4039:12090: peer proposal:
ike 2:VPNfg:4039:12090: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:12090: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12090: comparing selectors
ike 2:VPNfg:4039:VPNfg:12090: matched by rfc-rule-2
ike 2:VPNfg:4039:VPNfg:12090: phase2 matched by subset
ike 2:VPNfg:4039:VPNfg:12090: accepted proposal:
ike 2:VPNfg:4039:VPNfg:12090: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12090: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12090: autokey
ike 2:VPNfg:4039:VPNfg:12090: incoming child SA proposal:
ike 2:VPNfg:4039:VPNfg:12090: proposal id = 1:
ike 2:VPNfg:4039:VPNfg:12090:   protocol = ESP:
ike 2:VPNfg:4039:VPNfg:12090:      encapsulation = TUNNEL
ike 2:VPNfg:4039:VPNfg:12090:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:VPNfg:4039:VPNfg:12090:         type=INTEGR, val=SHA512
ike 2:VPNfg:4039:VPNfg:12090:         type=ESN, val=NO
ike 2:VPNfg:4039:VPNfg:12090:         PFS is disabled
ike 2:VPNfg:4039:VPNfg:12090: matched proposal id 1
ike 2:VPNfg:4039:VPNfg:12090: proposal id = 1:
ike 2:VPNfg:4039:VPNfg:12090:   protocol = ESP:
ike 2:VPNfg:4039:VPNfg:12090:      encapsulation = TUNNEL
ike 2:VPNfg:4039:VPNfg:12090:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:VPNfg:4039:VPNfg:12090:         type=INTEGR, val=SHA512
ike 2:VPNfg:4039:VPNfg:12090:         type=ESN, val=NO
ike 2:VPNfg:4039:VPNfg:12090:         PFS is disabled
ike 2:VPNfg:4039:VPNfg:12090: lifetime=600
ike 2:VPNfg:4039:VPNfg:12090: set sa life soft seconds=569.
ike 2:VPNfg:4039:VPNfg:12090: set sa life hard seconds=600.
ike 2:VPNfg:4039:VPNfg:12090: IPsec SA selectors #src=1 #dst=1
ike 2:VPNfg:4039:VPNfg:12090: src 0 7 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12090: dst 0 7 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12090: add IPsec SA: SPIs=154cda88/a2664922
ike 2:VPNfg:4039:VPNfg:12090: added IPsec SA: SPIs=154cda88/a2664922
ike 2:VPNfg: HA send IKEv2 message ID update send/recv=2/0
ike 2:VPNfg:4039:VPNfg:12090: sending SNMP tunnel UP trap
ike 2: HA add conn, unsupported type 144
ike 2: HA add conn, unsupported type 145
ike 2:VPNfg: HA IKE add conn
ike 2:VPNfg: HA add IKE SA 45a1740c06c3cfc5/1680a67638fca00e
ike 2:VPNfg:4039: HA add IKE SA ignored, already exists
ike 2:VPNfg:VPNfg: HA add IPsec SA 154cda88/a2664922 seq 47868c01 1
ike 2:VPNfg:VPNfg: src 0 7 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:VPNfg: dst 0 7 0:0.0.0.0-255.255.255.255:0
ike 2: HA receive seqno update send/recv=2/0

Navázání tunelu (SA_INIT) - Responder 

ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=SA_INIT id=45a1740c06c3cfc5/0000000000000000 len=260
ike 0:45a1740c06c3cfc5/0000000000000000:175: responder received SA_INIT msg
ike 0:45a1740c06c3cfc5/0000000000000000:175: received notify type FRAGMENTATION_SUPPORTED
ike 0:45a1740c06c3cfc5/0000000000000000:175: incoming proposal:
ike 0:45a1740c06c3cfc5/0000000000000000:175: proposal id = 1:
ike 0:45a1740c06c3cfc5/0000000000000000:175:   protocol = IKEv2:
ike 0:45a1740c06c3cfc5/0000000000000000:175:      encapsulation = IKEv2/none
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=INTEGR, val=AUTH_HMAC_SHA2_512_256
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=PRF, val=PRF_HMAC_SHA2_512
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=DH_GROUP, val=ECP521.
ike 0:45a1740c06c3cfc5/0000000000000000:175: matched proposal id 1
ike 0:45a1740c06c3cfc5/0000000000000000:175: proposal id = 1:
ike 0:45a1740c06c3cfc5/0000000000000000:175:   protocol = IKEv2:
ike 0:45a1740c06c3cfc5/0000000000000000:175:      encapsulation = IKEv2/none
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=INTEGR, val=AUTH_HMAC_SHA2_512_256
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=PRF, val=PRF_HMAC_SHA2_512
ike 0:45a1740c06c3cfc5/0000000000000000:175:         type=DH_GROUP, val=ECP521.
ike 0:45a1740c06c3cfc5/0000000000000000:175: lifetime=86400
ike 0:45a1740c06c3cfc5/0000000000000000:175: SA proposal chosen, matched gateway VPNfg2
ike 0: found VPNfg2 Y.Y.Y.Y 8 -> X.X.X.X:500
ike 0:VPNfg2:175: processing notify type FRAGMENTATION_SUPPORTED
ike 0:VPNfg2:175: responder preparing SA_INIT msg
ike 0:VPNfg2:175: sent IKE msg (SA_INIT_RESPONSE): Y.Y.Y.Y:500->X.X.X.X:500, len=260, id=45a1740c06c3cfc5/1680a67638fca00e
ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=AUTH id=45a1740c06c3cfc5/1680a67638fca00e:00000001 len=288
ike 0:VPNfg2:175: responder received AUTH msg
ike 0:VPNfg2:175: processing notify type INITIAL_CONTACT
ike 0:VPNfg2:175: processing notify type MESSAGE_ID_SYNC_SUPPORTED
ike 0:VPNfg2:175: peer identifier IPV4_ADDR X.X.X.X
ike 0:VPNfg2:175: auth verify done
ike 0:VPNfg2:175: responder AUTH continuation
ike 0:VPNfg2:175: authentication succeeded
ike 0:VPNfg2:175: responder creating new child
ike 0:VPNfg2:175:895: peer proposal:
ike 0:VPNfg2:175:895: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:895: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:895: comparing selectors
ike 0:VPNfg2:175:VPNfg2:895: matched by rfc-rule-2
ike 0:VPNfg2:175:VPNfg2:895: phase2 matched by subset
ike 0:VPNfg2:175:VPNfg2:895: accepted proposal:
ike 0:VPNfg2:175:VPNfg2:895: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:895: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:895: autokey
ike 0:VPNfg2:175:VPNfg2:895: incoming child SA proposal:
ike 0:VPNfg2:175:VPNfg2:895: proposal id = 1:
ike 0:VPNfg2:175:VPNfg2:895:   protocol = ESP:
ike 0:VPNfg2:175:VPNfg2:895:      encapsulation = TUNNEL
ike 0:VPNfg2:175:VPNfg2:895:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:VPNfg2:175:VPNfg2:895:         type=INTEGR, val=SHA512
ike 0:VPNfg2:175:VPNfg2:895:         type=ESN, val=NO
ike 0:VPNfg2:175:VPNfg2:895:         PFS is disabled
ike 0:VPNfg2:175:VPNfg2:895: matched proposal id 1
ike 0:VPNfg2:175:VPNfg2:895: proposal id = 1:
ike 0:VPNfg2:175:VPNfg2:895:   protocol = ESP:
ike 0:VPNfg2:175:VPNfg2:895:      encapsulation = TUNNEL
ike 0:VPNfg2:175:VPNfg2:895:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:VPNfg2:175:VPNfg2:895:         type=INTEGR, val=SHA512
ike 0:VPNfg2:175:VPNfg2:895:         type=ESN, val=NO
ike 0:VPNfg2:175:VPNfg2:895:         PFS is disabled
ike 0:VPNfg2:175:VPNfg2:895: lifetime=600
ike 0:VPNfg2:175: responder preparing AUTH msg
ike 0:VPNfg2:175: established IKE SA 45a1740c06c3cfc5/1680a67638fca00e
ike 0:VPNfg2:175: processing INITIAL-CONTACT
ike 0:VPNfg2:175: processed INITIAL-CONTACT
ike 0:VPNfg2: schedule auto-negotiate
ike 0:VPNfg2:174: IKE SA is a duplicate of 45a1740c06c3cfc5/1680a67638fca00e
ike 0:VPNfg2:174: schedule delete of IKE SA 9f5b9daecb715a9f/0a9e39dfd071718c
ike 0:VPNfg2:175:VPNfg2:895: set sa life soft seconds=580.
ike 0:VPNfg2:175:VPNfg2:895: set sa life hard seconds=600.
ike 0:VPNfg2:175:VPNfg2:895: IPsec SA selectors #src=1 #dst=1
ike 0:VPNfg2:175:VPNfg2:895: src 0 7 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:895: dst 0 7 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:895: add IPsec SA: SPIs=a2664922/154cda88
ike 0:VPNfg2:175:VPNfg2:895: added IPsec SA: SPIs=a2664922/154cda88
ike 0:VPNfg2:175:VPNfg2:895: sending SNMP tunnel UP trap
ike 0:VPNfg2:175: sent IKE msg (AUTH_RESPONSE): Y.Y.Y.Y:500->X.X.X.X:500, len=272, id=45a1740c06c3cfc5/1680a67638fca00e:00000001

Zprávy v průběhu (INFORMATIONAL) - Initiator

ike 2:VPNfg: HA IPsec send ESP seqno 47868c01
ike 2:VPNfg: HA IPsec master ignored unexpected ESP seqno update
ike 2:VPNfg:4039: have HA IKE SA, attempting message ID sync
ike 2:VPNfg:12096: sending IKEV2_MESSAGE_ID_SYNC NOTIFY msg
ike 2:VPNfg:4039:12096: send informational
ike 2:VPNfg:4039: sent IKE msg (INFORMATIONAL): X.X.X.X:500->Y.Y.Y.Y:500, len=112, id=45a1740c06c3cfc5/1680a67638fca00e
ike 2:VPNfg:4039: IKEV2_MESSAGE_ID_SYNC nonce=b645f272 expected send/recv msg IDs=6/1
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=INFORMATIONAL_RESPONSE id=45a1740c06c3cfc5/1680a67638fca00e len=112
ike 2:VPNfg:4039: received informational response
ike 2:VPNfg:12096: received NOTIFY acknowledgement
ike 2:VPNfg:4039:12096: processing informational acknowledgement
ike 2:VPNfg:4039: processing notify type MESSAGE_ID_SYNC
ike 2:VPNfg:4039: message ID sync response received nonce=b645f272 expected send/recv msg IDs=1/6
ike 2:VPNfg:4039: synced message IDs: send/recv=6/1
ike 2:VPNfg: HA send IKEv2 message ID update send/recv=6/1
ike 2: HA receive seqno update send/recv=6/1

Zprávy v průběhu (INFORMATIONAL) - Responder

ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=INFORMATIONAL id=45a1740c06c3cfc5/1680a67638fca00e len=112
ike 0:VPNfg2:175: received informational request
ike 0:VPNfg2:175: processing notify type MESSAGE_ID_SYNC
ike 0:VPNfg2:175: message ID sync request received nonce=b645f272 expected send/recv msg IDs=6/1
ike 0:VPNfg2:175: current send/recv msg IDs=0/2 updated to new send/recv msg IDs=1/6
ike 0:VPNfg2:175: sent IKE msg (INFORMATIONAL_RESPONSE): Y.Y.Y.Y:500->X.X.X.X:500, len=112, id=45a1740c06c3cfc5/1680a67638fca00e

Provedení Rekey (CREATE_CHILD) - Initiator

ike 2:VPNfg:VPNfg: IPsec SA a2664922/154cda88 rekey 59 X.X.X.X->Y.Y.Y.Y:0
ike 2:VPNfg:VPNfg: using existing connection
ike 2:VPNfg:VPNfg: config found
ike 2:VPNfg:VPNfg: IPsec SA connect 59 X.X.X.X->Y.Y.Y.Y:500 negotiating
ike 2:VPNfg:4039: have HA IKE SA, attempting message ID sync
ike 2:VPNfg:12103: sending IKEV2_MESSAGE_ID_SYNC NOTIFY msg
ike 2:VPNfg:4039:12103: send informational
ike 2:VPNfg:4039: sent IKE msg (INFORMATIONAL): X.X.X.X:500->Y.Y.Y.Y:500, len=112, id=45a1740c06c3cfc5/1680a67638fca00e
ike 2:VPNfg:4039: IKEV2_MESSAGE_ID_SYNC nonce=1a2b0a55 expected send/recv msg IDs=14/1
ike 2:VPNfg:4039:VPNfg:12102: IKEv2 queuing create-child request
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=INFORMATIONAL_RESPONSE id=45a1740c06c3cfc5/1680a67638fca00e len=112
ike 2:VPNfg:4039: received informational response
ike 2:VPNfg:12103: received NOTIFY acknowledgement
ike 2:VPNfg:4039:12103: processing informational acknowledgement
ike 2:VPNfg:4039: processing notify type MESSAGE_ID_SYNC
ike 2:VPNfg:4039: message ID sync response received nonce=1a2b0a55 expected send/recv msg IDs=1/14
ike 2:VPNfg:4039: synced message IDs: send/recv=14/1
ike 2:VPNfg: HA send IKEv2 message ID update send/recv=14/1
ike 2:VPNfg:4039:12102 initiating CREATE_CHILD exchange
ike 2:VPNfg:4039:VPNfg:12102: PFS enabled
ike 2:VPNfg:4039:12102 rekey in progress for SPI 154cda88
ike 2:VPNfg:4039: sent IKE msg (CREATE_CHILD): X.X.X.X:500->Y.Y.Y.Y:500, len=384, id=45a1740c06c3cfc5/1680a67638fca00e:0000000e
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=CREATE_CHILD_RESPONSE id=45a1740c06c3cfc5/1680a67638fca00e:0000000e len=368
ike 2:VPNfg:4039: received create-child response
ike 2:VPNfg:4039: initiator received CREATE_CHILD msg
ike 2:VPNfg:4039:VPNfg:12102: found child SA SPI 154cda8e state=3
ike 2:VPNfg:4039:VPNfg:12102: PFS enabled, group=21
ike 2:VPNfg:4039:12102: peer proposal:
ike 2:VPNfg:4039:12102: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:12102: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12102: comparing selectors
ike 2:VPNfg:4039:VPNfg:12102: matched by rfc-rule-2
ike 2:VPNfg:4039:VPNfg:12102: phase2 matched by subset
ike 2:VPNfg:4039:VPNfg:12102: accepted proposal:
ike 2:VPNfg:4039:VPNfg:12102: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12102: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12102: autokey
ike 2:VPNfg:4039:VPNfg:12102: incoming child SA proposal:
ike 2:VPNfg:4039:VPNfg:12102: proposal id = 1:
ike 2:VPNfg:4039:VPNfg:12102:   protocol = ESP:
ike 2:VPNfg:4039:VPNfg:12102:      encapsulation = TUNNEL
ike 2:VPNfg:4039:VPNfg:12102:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:VPNfg:4039:VPNfg:12102:         type=INTEGR, val=SHA512
ike 2:VPNfg:4039:VPNfg:12102:         type=DH_GROUP, val=ECP521
ike 2:VPNfg:4039:VPNfg:12102:         type=ESN, val=NO
ike 2:VPNfg:4039:VPNfg:12102: matched proposal id 1
ike 2:VPNfg:4039:VPNfg:12102: proposal id = 1:
ike 2:VPNfg:4039:VPNfg:12102:   protocol = ESP:
ike 2:VPNfg:4039:VPNfg:12102:      encapsulation = TUNNEL
ike 2:VPNfg:4039:VPNfg:12102:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:VPNfg:4039:VPNfg:12102:         type=INTEGR, val=SHA512
ike 2:VPNfg:4039:VPNfg:12102:         type=DH_GROUP, val=ECP521
ike 2:VPNfg:4039:VPNfg:12102:         type=ESN, val=NO
ike 2:VPNfg:4039:VPNfg:12102: lifetime=600
ike 2:VPNfg: schedule auto-negotiate
ike 2:VPNfg:4039:VPNfg:12102: set sa life soft seconds=572.
ike 2:VPNfg:4039:VPNfg:12102: set sa life hard seconds=600.
ike 2:VPNfg:4039:VPNfg:12102: IPsec SA selectors #src=1 #dst=1
ike 2:VPNfg:4039:VPNfg:12102: src 0 7 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12102: dst 0 7 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:4039:VPNfg:12102: add IPsec SA: SPIs=154cda8e/a2664923
ike 2:VPNfg:4039:VPNfg:12102: added IPsec SA: SPIs=154cda8e/a2664923
ike 2:VPNfg: HA send IKEv2 message ID update send/recv=15/1
ike 2:VPNfg:4039:VPNfg:12102: scheduling rekeyed SPI 154cda88 for deletion
ike 2:VPNfg:4039:VPNfg:12102: rekey in progress, old SPI 154cda88
ike 2: HA receive seqno update send/recv=14/1
ike 2:VPNfg:VPNfg: HA add IPsec SA 154cda8e/a2664923 seq 47868c01 1
ike 2:VPNfg:VPNfg: src 0 7 0:0.0.0.0-255.255.255.255:0
ike 2:VPNfg:VPNfg: dst 0 7 0:0.0.0.0-255.255.255.255:0
ike 2: HA receive seqno update send/recv=15/1

Provedení Rekey (CREATE_CHILD) - Responder

ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=INFORMATIONAL id=45a1740c06c3cfc5/1680a67638fca00e len=112
ike 0:VPNfg2:175: received informational request
ike 0:VPNfg2:175: processing notify type MESSAGE_ID_SYNC
ike 0:VPNfg2:175: message ID sync request received nonce=1a2b0a55 expected send/recv msg IDs=14/1
ike 0:VPNfg2:175: current send/recv msg IDs=1/6 updated to new send/recv msg IDs=1/14
ike 0:VPNfg2:175: sent IKE msg (INFORMATIONAL_RESPONSE): Y.Y.Y.Y:500->X.X.X.X:500, len=112, id=45a1740c06c3cfc5/1680a67638fca00e
ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=CREATE_CHILD id=45a1740c06c3cfc5/1680a67638fca00e:0000000e len=384
ike 0:VPNfg2:175: received create-child request
ike 0:VPNfg2:175: responder received CREATE_CHILD exchange
ike 0:VPNfg2:175: processing notify type REKEY_SA
ike 0:VPNfg2:175:VPNfg2:895: rekeying child SA SPI 154cda88
ike 0:VPNfg2:175: responder creating new child
ike 0:VPNfg2:175:898: peer proposal:
ike 0:VPNfg2:175:898: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:898: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:898: comparing selectors
ike 0:VPNfg2:175:VPNfg2:898: matched by rfc-rule-2
ike 0:VPNfg2:175:VPNfg2:898: phase2 matched by subset
ike 0:VPNfg2:175:VPNfg2:898: accepted proposal:
ike 0:VPNfg2:175:VPNfg2:898: TSi_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:898: TSr_0 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:898: autokey
ike 0:VPNfg2:175:VPNfg2:898: incoming child SA proposal:
ike 0:VPNfg2:175:VPNfg2:898: proposal id = 1:
ike 0:VPNfg2:175:VPNfg2:898:   protocol = ESP:
ike 0:VPNfg2:175:VPNfg2:898:      encapsulation = TUNNEL
ike 0:VPNfg2:175:VPNfg2:898:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:VPNfg2:175:VPNfg2:898:         type=INTEGR, val=SHA512
ike 0:VPNfg2:175:VPNfg2:898:         type=DH_GROUP, val=ECP521
ike 0:VPNfg2:175:VPNfg2:898:         type=ESN, val=NO
ike 0:VPNfg2:175:VPNfg2:898: matched proposal id 1
ike 0:VPNfg2:175:VPNfg2:898: proposal id = 1:
ike 0:VPNfg2:175:VPNfg2:898:   protocol = ESP:
ike 0:VPNfg2:175:VPNfg2:898:      encapsulation = TUNNEL
ike 0:VPNfg2:175:VPNfg2:898:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:VPNfg2:175:VPNfg2:898:         type=INTEGR, val=SHA512
ike 0:VPNfg2:175:VPNfg2:898:         type=DH_GROUP, val=ECP521
ike 0:VPNfg2:175:VPNfg2:898:         type=ESN, val=NO
ike 0:VPNfg2:175:VPNfg2:898: lifetime=600
ike 0:VPNfg2:175:VPNfg2:898: PFS enabled, group=21
ike 0:VPNfg2: schedule auto-negotiate
ike 0:VPNfg2:175:VPNfg2:898: set sa life soft seconds=580.
ike 0:VPNfg2:175:VPNfg2:898: set sa life hard seconds=600.
ike 0:VPNfg2:175:VPNfg2:898: IPsec SA selectors #src=1 #dst=1
ike 0:VPNfg2:175:VPNfg2:898: src 0 7 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:898: dst 0 7 0:0.0.0.0-255.255.255.255:0
ike 0:VPNfg2:175:VPNfg2:898: add IPsec SA: SPIs=a2664923/154cda8e
ike 0:VPNfg2:175:VPNfg2:898: added IPsec SA: SPIs=a2664923/154cda8e
ike 0:VPNfg2:175:VPNfg2:898: responder preparing CREATE_CHILD message
ike 0:VPNfg2:175: sent IKE msg (CREATE_CHILD_RESPONSE): Y.Y.Y.Y:500->X.X.X.X:500, len=368, id=45a1740c06c3cfc5/1680a67638fca00e:0000000e

Smazání starého IPsec SA po Rekey (CREATE_CHILD) - Initiator

ike 2:VPNfg:4039:VPNfg:12090: sending delete for IPsec SA SPI 154cda88
ike 2:VPNfg:4039:12104: send informational
ike 2:VPNfg:4039: sent IKE msg (INFORMATIONAL): X.X.X.X:500->Y.Y.Y.Y:500, len=96, id=45a1740c06c3cfc5/1680a67638fca00e:0000000f
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=INFORMATIONAL_RESPONSE id=45a1740c06c3cfc5/1680a67638fca00e:0000000f len=96
ike 2:VPNfg:4039: have HA IKE SA, attempting message ID sync
ike 2:VPNfg:4039: removing old active request before message ID sync

Smazání starého IPsec SA po Rekey (CREATE_CHILD) - Responder

ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=INFORMATIONAL id=45a1740c06c3cfc5/1680a67638fca00e:0000000f len=96
ike 0:VPNfg2:175: received informational request
ike 0:VPNfg2:175: processing delete request (proto 3)
ike 0:VPNfg2:VPNfg2:898: send SA_DONE SPI 0x154cda8e
ike 0:VPNfg2: deleting IPsec SA with SPI 154cda88
ike 0:VPNfg2:VPNfg2: deleted IPsec SA with SPI 154cda88, SA count: 1
ike 0:VPNfg2:175: sending delete ack
ike 0:VPNfg2:175: sent IKE msg (INFORMATIONAL_RESPONSE): Y.Y.Y.Y:500->X.X.X.X:500, len=96, id=45a1740c06c3cfc5/1680a67638fca00e:0000000f

Směr ze samostatného FortiGate na FortiGate cluster

Ovšem pokud se navazuje VPN tunel na cluster (jako Responder), tak je s Rekey podobný problém, jako mezi FortiGate a Cisco Firepower. Sice debug zprávy vypadají jinak, ale neproběhne Rekey, ale nové navázání tunelu.

Pozn.: I toto se vyřešilo vypnutím VDOM Partitioning.

Provedení Rekey (CREATE_CHILD) - Initiator

ike 0:VPNfg2:VPNfg2: IPsec SA 154cda9f/a2664929 rekey 8 Y.Y.Y.Y->X.X.X.X:0
ike 0:VPNfg2:VPNfg2: using existing connection
ike 0:VPNfg2:VPNfg2: config found
ike 0:VPNfg2:VPNfg2: IPsec SA connect 8 Y.Y.Y.Y->X.X.X.X:500 negotiating
ike 0:VPNfg2:180:911 initiating CREATE_CHILD exchange
ike 0:VPNfg2:180:VPNfg2:911: PFS enabled
ike 0:VPNfg2:180:911 rekey in progress for SPI a2664929
ike 0:VPNfg2:180: sent IKE msg (CREATE_CHILD): Y.Y.Y.Y:500->X.X.X.X:500, len=384, id=d2cb08542b820ffa/86d4dee21876d9b8:00000002
ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=INFORMATIONAL id=d2cb08542b820ffa/86d4dee21876d9b8 len=112
ike 0:VPNfg2:180: received informational request
ike 0:VPNfg2:180: processing notify type MESSAGE_ID_SYNC
ike 0:VPNfg2:180: message ID sync request received nonce=69bd80e2 expected send/recv msg IDs=10/2
ike 0:VPNfg2:180: current send/recv msg IDs=2/4 updated to new send/recv msg IDs=3/10
ike 0:VPNfg2:180: sent IKE msg (INFORMATIONAL_RESPONSE): Y.Y.Y.Y:500->X.X.X.X:500, len=112, id=d2cb08542b820ffa/86d4dee21876d9b8
ike 0:VPNfg2:180: sent IKE msg (RETRANSMIT_CREATE_CHILD): Y.Y.Y.Y:500->X.X.X.X:500, len=384, id=d2cb08542b820ffa/86d4dee21876d9b8:00000003

Několikrát se opakuje, že se vysílá žádost RETRANSMIT_CREATE_CHILD a přichází INFORMATIONAL. Až vyprší Lifetime IPsec SA (a ještě se vymění několik zpráv). 

ike 0:VPNfg2: IPsec SA 154cda9f/a2664929 hard expired 8 Y.Y.Y.Y->X.X.X.X:0 SA count 0 of 0
ike 0:VPNfg2:180:VPNfg2:910: sending delete for IPsec SA SPI a2664929
ike 0:VPNfg2:180::912: wait for pending request VPNfg2:911
ike 0:VPNfg2: sending SNMP tunnel DOWN trap for VPNfg2

Pak se ukončí celý tunel a následně se kompletně znovu naváže (SA_INIT).

ike 0:VPNfg2:180: d2cb08542b820ffa/86d4dee21876d9b8 negotiation of IKE SA failed due to retry timeout
ike 0:VPNfg2:180: expiring IKE SA d2cb08542b820ffa/86d4dee21876d9b8
ike 0:VPNfg2: deleting
ike 0:VPNfg2: flushing 
ike 0:VPNfg2:180:912: send informational
ike 0:VPNfg2:180: sent IKE msg (INFORMATIONAL): Y.Y.Y.Y:500->X.X.X.X:500, len=96, id=d2cb08542b820ffa/86d4dee21876d9b8:0000000a
ike 0:VPNfg2: flushed 
ike 0:VPNfg2:180:913: send informational
ike 0:VPNfg2:180: sent IKE msg (INFORMATIONAL): Y.Y.Y.Y:500->X.X.X.X:500, len=96, id=d2cb08542b820ffa/86d4dee21876d9b8:0000000a
ike 0:VPNfg2: deleted
ike 0:VPNfg2: set oper down
ike 0:VPNfg2: schedule auto-negotiate
ike 0:VPNfg2: carrier down
ike 0: comes X.X.X.X:500->Y.Y.Y.Y:500,ifindex=8....
ike 0: IKEv2 exchange=INFORMATIONAL id=d2cb08542b820ffa/86d4dee21876d9b8 len=112
ike 0: invalid IKE request SPI d2cb08542b820ffa/86d4dee21876d9b8
ike 0:VPNfg2: auto-negotiate connection
ike 0:VPNfg2: created connection: 0xb447920 8 Y.Y.Y.Y->X.X.X.X:500.
ike 0:VPNfg2:VPNfg2: chosen to populate IKE_SA traffic-selectors
ike 0:VPNfg2: no suitable IKE_SA, queuing CHILD_SA request and initiating IKE_SA negotiation
ike 0:VPNfg2:181: sent IKE msg (SA_INIT): Y.Y.Y.Y:500->X.X.X.X:500, len=260, id=19d5a32fdf9340cf/0000000000000000

Provedení Rekey (CREATE_CHILD) - Responder

ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=CREATE_CHILD id=d2cb08542b820ffa/86d4dee21876d9b8:00000002 len=384
ike 2:VPNfg:4064: have HA IKE SA, attempting message ID sync
ike 2:VPNfg:12175: sending IKEV2_MESSAGE_ID_SYNC NOTIFY msg
ike 2:VPNfg:4064:12175: send informational
ike 2:VPNfg:4064: sent IKE msg (INFORMATIONAL): X.X.X.X:500->Y.Y.Y.Y:500, len=112, id=d2cb08542b820ffa/86d4dee21876d9b8
ike 2:VPNfg:4064: IKEV2_MESSAGE_ID_SYNC nonce=69bd80e2 expected send/recv msg IDs=10/2
ike 2:VPNfg:4064: request msgid = 2, expected 0
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=INFORMATIONAL_RESPONSE id=d2cb08542b820ffa/86d4dee21876d9b8 len=112
ike 2:VPNfg:4064: received informational response
ike 2:VPNfg:12175: received NOTIFY acknowledgement
ike 2:VPNfg:4064:12175: processing informational acknowledgement
ike 2:VPNfg:4064: processing notify type MESSAGE_ID_SYNC
ike 2:VPNfg:4064: message ID sync response received nonce=69bd80e2 expected send/recv msg IDs=3/10
ike 2:VPNfg:4064: synced message IDs: send/recv=10/3
ike 2:VPNfg: HA send IKEv2 message ID update send/recv=10/3
ike 2: HA receive seqno update send/recv=10/3
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=CREATE_CHILD id=d2cb08542b820ffa/86d4dee21876d9b8:00000003 len=384
ike 2:VPNfg:4064: have HA IKE SA, attempting message ID sync

Také na této straně vyprší Lifetime IPsec SA.

ike 2:VPNfg: IPsec SA a2664929/154cda9f hard expired 59 X.X.X.X->Y.Y.Y.Y:0 SA count 0 of 0
ike 2:VPNfg:4064:VPNfg:12162: sending delete for IPsec SA SPI 154cda9f
ike 2:VPNfg:4064:12179: send informational
ike 2:VPNfg:4064: sent IKE msg (INFORMATIONAL): X.X.X.X:500->Y.Y.Y.Y:500, len=96, id=d2cb08542b820ffa/86d4dee21876d9b8:0000005e

Vymění se ještě řada zpráv INFORMATIONAL, až přijde poslední INFORMATIONAL od Initiator a pak SA_INIT. 

ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=INFORMATIONAL id=d2cb08542b820ffa/86d4dee21876d9b8:0000000a len=96
ike 2:VPNfg:4064: have HA IKE SA, attempting message ID sync
ike 2:VPNfg:12185: sending IKEV2_MESSAGE_ID_SYNC NOTIFY msg
ike 2:VPNfg:4064:12185: send informational
ike 2:VPNfg:4064: sent IKE msg (INFORMATIONAL): X.X.X.X:500->Y.Y.Y.Y:500, len=112, id=d2cb08542b820ffa/86d4dee21876d9b8
ike 2:VPNfg:4064: IKEV2_MESSAGE_ID_SYNC nonce=ca7683af expected send/recv msg IDs=766/9
ike 2:VPNfg:4064: request msgid = 10, expected 0
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=INFORMATIONAL id=d2cb08542b820ffa/86d4dee21876d9b8:0000000a len=96
ike 2:VPNfg:4064: request msgid = 10, expected 0
ike 2: comes Y.Y.Y.Y:500->X.X.X.X:500,ifindex=59....
ike 2: IKEv2 exchange=SA_INIT id=19d5a32fdf9340cf/0000000000000000 len=260
zobrazeno: 11646krát | Komentáře [2]

Autor:

Související články:

Fortinet FortiGate a další

Bezpečnostní řešení firmy Fortinet. Nejvíce zaměřeno na Next Generation Firewall (NGFW) FortiGate.

VPN - Virtual Private Network

Série článků, která obsahuje obecný popis technologie VPN. Rozebírá jednotlivé typy VPN, jako je Site to Site VPN a Remote Access VPN. A popisuje konfigurace na různých zařízeních.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

  1. [1] Vlada

    Dekuji!

    Čtvrtek, 06.05.2021 15:15 | odpovědět
  2. [2] Zbyněk

    Jako už mnohokrát ... a opět ... dozvídáme se od Vás přesně to, co je pro první nastavení třeba, s terminologií a vazbami, stručně, ale dokonale funkčně. Prostě informace od člověka, který věci rozumí (pokud je to vůbec možné ;-) ) a navíc je opravdu nezávislý odborník se skutečnou praxí.

    Díky samozřejmě nejen za tento článek.

    Pondělí, 12.07.2021 17:26 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách