Hello!
I've encountered an issue with an IPSEC tunnel setup between our "Site A" and a customer's location, "Site B." Despite extensive troubleshooting, I've been unable to find a solution, and I'm hoping the community here might have some insights.
Here's the problem: the tunnel refuses to establish (both phase 1 and phase 2) unless a device on "Site B" initiates a ping to "Site A." Strangely, the reverse doesn't work; initiating a ping from "Site A" to "Site B" doesn't bring the tunnel up.
Furthermore, if there's no ongoing traffic on the tunnel, it automatically goes down after a certain period (around 10-15 minutes). Even though I've verified that the configurations on both sides are identical and have tinkered with Keepalive Frequency, Auto-negotiate, and Autokey Keep Alive settings, the issue persists.
I'm at a bit of a loss here, and I was wondering if any of you out there might have encountered a similar problem or could offer some guidance on where I should focus my troubleshooting efforts. Any pointers or tips would be greatly appreciated!
Thanks in advance for your time and assistance!
Is Site A and Site B Fortigates? Some vendors need additional setting on interface level to act as responder for tunnel , if Site B is one of such device unless it is configured to accept VPN negotiations it will always act as Initiator and you may see this behavior.
Thanks for the swift response!
At "Site A," we're using a Fortigate, while at "Site B," there's a Fortigate followed by a VMWare NSX-t where the IPSEC tunnel is initiated.
I'll reach out to our customer at "Site B" to ask about any additional settings that might be necessary for the VMWare NSX-t to function as a responder.
Appreciate the suggestion, and I'll keep you posted on any updates.
Thanks again!
We also need to make sure Fortigate at SiteB have 2 separate firewall policies allowing ESP and UDP 500/4500 from Site A to Site B and the reverse.
Hello again!
I've just confirmed with "Site B" that the VMWare NSX-T is configured to function as both the initiator and acceptor for VPN connections. Additionally, they've established incoming firewall rules on the FortiGate for both ESP 500 and UDP 4500.
To address the connectivity issue temporarily, we've implemented a continuous ping from Site B to Site A. This has maintained the tunnel's stability for the past couple of days. I recall reading somewhere that Fortinet products used to have a ping generator in the past. Has this been replaced by the Keepalive Frequency setting?
Thanks!
There is no ping generator, we need to use the keepalive feature along with auto-negotiate to keep the tunnel UP without actual data through the tunnel.
Ref: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-the-IPSec-auto-negotiate-and-keepali...
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 |
---|---|
1737 | |
1108 | |
752 | |
447 | |
240 |
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.