- Forums
- Knowledge Base
- Customer Service
- FortiGate
- FortiClient
- FortiAP
- FortiAnalyzer
- FortiADC
- FortiAuthenticator
- FortiBridge
- FortiCache
- FortiCarrier
- FortiCASB
- FortiConnect
- FortiConverter
- FortiCNP
- FortiDAST
- FortiDDoS
- FortiDB
- FortiDNS
- FortiDeceptor
- FortiDevSec
- FortiDirector
- FortiEDR
- FortiExtender
- FortiGate Cloud
- FortiGuard
- FortiHypervisor
- FortiInsight
- FortiIsolator
- FortiMail
- FortiManager
- FortiMonitor
- FortiNAC
- FortiNAC-F
- FortiNDR (on-premise)
- FortiNDRCloud
- FortiPAM
- FortiPortal
- FortiProxy
- FortiRecon
- FortiRecorder
- FortiSandbox
- FortiSASE
- FortiScan
- FortiSIEM
- FortiSOAR
- FortiSwitch
- FortiTester
- FortiToken
- FortiVoice
- FortiWAN
- FortiWeb
- Wireless Controller
- RMA Information and Announcements
- FortiCloud Products
- ZTNA
- 4D Documents
- Customer Service
- Community Groups
- Blogs
FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
- Fortinet Community
- Knowledge Base
- FortiGate
- Troubleshooting Tip: IKEv2 IPSec tunnel flaps at e...
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
| Description | This article covers a specific scenario where, due to a PFS mismatch, an IKEv2 tunnel will result in a tunnel flap at each IPSec rekey even though it comes up initially. |
| Scope |
FortiGate, IPSec tunnel, IKEv2, PFS. |
| Solution |
In contrast to IKEv1: when there is a PFS mismatch on an IPSec tunnel configured to use IKEv2, the tunnel will initially come up as expected. It will continue to function and pass traffic without any issues until an IPSec rekey. During the IPSec rekey, the tunnel will go down, resulting in traffic disruption.
This is a misconfiguration. The reason why the tunnel comes up the first time is that there is only one traffic selector (for example: 0.0.0.0/0.0.0.0 to 0.0.0.0/0.0.0.0 i.e. any to any). After, the RFC for IKEv2 allows for the first IPSec SA to come up as part of completing the IKE_AUTH exchange. As a result, following the completion of the first four messages being exchanged, the IKE and the IPSec SA (Security Association) come up and can start passing traffic over the tunnel. This is because PFS settings are not exchanged in IKE_AUTH.
However, during an IPSec rekey, the CREATE_CHILD_SA exchange is used. Because this is when the PFS settings are sent to the peer, the mismatch will be found, the rekey will fail, and the tunnel will go down.
The solution is to configure the IKEv2 IPSec tunnel properly, with PFS settings matched at both ends.
Example of issue debugs: Example 1: This device is the initiator for the CREATE_CHILD_SA exchange:
2023-10-19 10:36:04.712413 ike 0:pmbho-rto:7018725: received create-child request
Example 2: This device is the responder for the CREATE_CHILD_SA exchange:
2023-10-19 10:36:02.710224 ike 0:pmbho-rto:pmbho-rto: IPsec SA connect 9 10.11.11.11->10.12.12.12:0 |
Broad. Integrated. Automated.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Security Research
Company
News & Articles
Copyright 2024 Fortinet, Inc. All Rights Reserved.