I have had many site-to-site IPsec tunnels working fine for several years until I upgraded to FortiOS 7.4.2. Shortly afterward, my tunnels began dropping connections on random Phase 2 connections. I have had to bring down the phases or entire tunnel to get traffic flowing again many times. I opened a ticket with Fortinet and had three technicians working with me at various times but none found a solution.
I finally downgraded to 7.4.1 and all my problems went away. There is obviously a bug in 7.4.2 and I hope Fortinet finds and acknowledges it and fixes it for the next release.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Created on 03-07-2024 10:06 AM Edited on 03-07-2024 10:07 AM
It sounds like you have another issue. When there are multiple phase 2, is it normal to only have the traffic of the first phase 2? Other phase 2 unable to pass traffic successfully? Or is there no phase 2 established? Is there some debug information? Can you share your configuration file?
FortiGate # diagnose debug application ike -1
FortiGate # diagnose debug enable
# diagnose sniffer packet any "host x.x.x.x" 4 0 l
Thanks
Kangming
TAC said 7.2.8 is supposed to be released on March 11th and addresses the 7.2.7 known issue with ipsec performance. That was the only reason we upgraded to 7.4.3 over 7.2.7 in the first place.
I will wait for that version.
Could you share ticket id? Thanks.
Thanks
Kangming
9296054
TAC now says the 14th.
Let's hope so
Created on 07-24-2024 10:30 PM Edited on 07-24-2024 10:31 PM
It seems that we are experiencing the same after test upgrading a couple of FortiGates from 7.2.X to 7.4.x .
We have multiple IPSec dialup connections to our HQ from remote FortiGates, after upgrading to 7.4.x only the first tunnel gets established with Phase2. They are behind NAT and connecting to our HQ IPSec interface VPN by with tunnel-id differentiate them.
If I deactivate the first IPSec tunnel, then the next one automatically gets established. We use this with SDWAN for multiple carriers like to our HQ and finds this as a strange behaviour since we have had no issues with this setup for ages.
It does not seem that 7.4.4 fixed this issue for us either.
Created on 07-25-2024 05:46 AM Edited on 07-25-2024 06:08 AM
For dial ups they changed how the routing is done for some reason. Starting after 7.2.5.
On all of your phase1s "set add-route disable"
On all of your phase2s "set route-overlap allow"
You either do both of those settings on all dial up phase1s and phase2s or you create specific phase2s that do not overlap. You only have to do this on the hub side of the dial up ipsec vpn. We have one hub with 1146 ipsec dial up tunnels and another with 200 and every single one of them cleared up after doing this.
Created on 07-27-2024 04:03 PM Edited on 07-27-2024 04:04 PM
Thanks for the tip, but I don't think that will solve the issue as we are using BGP for IPSec routing and it is currently working with FOS 7.2.7 running at both Hub and several Spoke FortiGates.
I will try to open a ticket for this and see if I have any luck solving this issue.
These settings will not drop BGP learned routes. They stop the phase 1 from adding the SA to the routing table and also allow you to overlap SA's.
If you are doing 0.0.0.0 for source and destination in your phase 2 config only one tunnel will ever come up without those two settings.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1688 | |
1087 | |
752 | |
446 | |
227 |
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.
Copyright 2024 Fortinet, Inc. All Rights Reserved.