Before We Start: This Bug Will Make You Question Your Life Choices
FortiGate IPsec VPN tunnels are great when they work. When they start dropping randomly? That’s a special kind of hell. I’ve seen too many posts on Reddit where someone gets the tunnel up, it works for a while, then dies without warning. One poor soul on r/fortinet said his tunnel would go down randomly and wouldn’t come back up until he rebooted the device. Sound familiar?
Then there’s the r/india post from a few weeks ago—a guy discovered his ISP was doing HTTPS MITM on TLS 1.2, and the culprit was a FortiGate on the ISP’s side. That thing wasn’t just breaking VPNs; it was reading traffic without anyone knowing. Extreme case, sure, but it proves a point: FortiGate VPNs have more edge cases than a diamond.
This isn’t some “comprehensive guide” fluff. This is the stuff I’ve learned the hard way, mixed with the collective trauma from Reddit. We’re going from symptoms to root cause to CLI commands that actually fix things. Let’s go.
Symptom Recognition: “Down” Is Just the Beginning
When your tunnel drops, the first thing you see is that red “Down” status in the GUI. Don’t stop there. The symptoms are more nuanced than that.
Here’s what I’ve seen in the wild:
| Symptom | Typical Behavior | Likely Root Cause |
|---|---|---|
| Tunnel completely dead | diagnose vpn tunnel list shows down | Phase 1 or Phase 2 negotiation failure |
| Intermittent drops | Traffic works, then dies, then recovers | DPD timeout or NAT-T issues |
| Tunnel shows Up but no ping | Status is green, internal resources unreachable | Missing routes or Phase 2 selector mismatch |
| One-way traffic only | Traffic flows one direction, fails the other | Missing firewall policy for return traffic |
| Requires reboot to recover | Tunnel drops and won’t rebuild until restart | IKE process deadlock or memory leak (old firmware) |
Last year I hit a production issue where the tunnel was Up, but all cross-site database connections timed out. The root cause? The Phase 2 local address was wrong, so encrypted packets were getting silently dropped. The GUI showed nothing wrong. CLI told the real story.
Root Cause Analysis: Why Your Tunnel Keeps Screwing You
Phase 1 Negotiation Failure
This is the #1 culprit. IKEv1 and IKEv2 negotiate a laundry list of parameters: encryption algorithm, hash algorithm, DH group, lifetime. One mismatch and the tunnel won’t come up.
The worst one I’ve seen: both sides configured AES256-SHA256, but one was using IKEv1 and the other IKEv2. The logs just said “negotiate failed” with zero context.
Phase 2 Selector Mismatch
This one’s sneaky. Phase 2 requires the local and remote address ranges to match exactly. If you’ve got 10.0.0.0/24 on your side and the peer has 10.0.0.0/23, the tunnel might come up, but traffic will get silently dropped.
DPD Configuration Issues
Dead Peer Detection is great until it’s not. Too short an interval and network jitter kills your tunnel. Too long and you won’t know the peer is dead. The default of 10 seconds with 3 retries is masochistic on lossy links.
NAT-T Failures
If both ends have NAT devices, NAT Traversal must be enabled. I’ve seen people disable it thinking they don’t need it, then watch their tunnel drop every few minutes because the NAT box drops ESP packets.
ISP-Level Shenanigans
This is the one that makes you want to throw your laptop. The r/india guy’s ISP was using a FortiGate to MITM TLS 1.2 traffic. While that’s not directly about VPN drops, it proves ISPs can and will mess with your traffic. Some ISPs actively drop ESP protocol packets, forcing you to use UDP-encapsulated IPsec.
The Hardcore Fix: Step-by-Step CLI Commands
Forget the GUI. If you want to fix this, you live in the CLI now.
Step 1: Check Current Tunnel Status
diagnose vpn tunnel list
This lists all VPN tunnels and their states. If you see state: down, keep reading.
For more detail:
diagnose vpn ike gateway list
This shows Phase 1 gateway details, including peer IP, encryption algorithms, and DPD status.
Step 2: Enable Debug Logging
diagnose debug application ike -1
diagnose debug enable
The -1 flag means all tunnels. You can also specify a specific tunnel name.
Wait a few seconds, then disable:
diagnose debug disable
Look for these keywords in the output:
no proposal chosen: Phase 1 parameter mismatchpeer not responsive: Peer unreachable, likely firewall or NAT issueDPD timeout: DPD timed out, check network stabilityIPsec SA negotiation failed: Phase 2 negotiation failure
Step 3: Verify Phase 1 Configuration
show vpn ipsec phase1-interface
Check every parameter against the peer:
type: static or dynamicinterface: must match your WAN interfacepeertype: any or specificproposal: encryption algorithms must matchdhgrp: DH group must matchkeylife: lifetime, default 86400 seconds
Here’s a trap I fell into: both sides had aes256-sha256, but one was using dh-group 14 and the other dh-group 2. The logs didn’t highlight it. I had to compare line by line.
Step 4: Verify Phase 2 Configuration
show vpn ipsec phase2-interface
Focus on:
src-addr-typeanddst-addr-type: subnet or ipsrc-start-ipandsrc-end-ip: local subnet rangedst-start-ipanddst-end-ip: remote subnet rangeprotocol: 0 for all, or specific protocol
Classic mistake: the Phase 2 local and remote addresses are swapped on one side. If your local is 10.0.1.0/24 and remote is 10.0.2.0/24, the peer must have the opposite.
Step 5: Force Tunnel Rebuild
If the tunnel is stuck, don’t reboot yet. Try this:
execute vpn tunnel down <tunnel_name>
Wait a few seconds, then:
execute vpn tunnel up <tunnel_name>
This forces a renegotiation. If that doesn’t work, clear all IKE SAs:
diagnose vpn ike restart
Warning: this resets all IKE connections. Every VPN tunnel will go down.
Step 6: Check Routes and Firewall Policies
Tunnel is up but traffic doesn’t flow? Check the routing table:
get router info routing-table
Make sure the route to the peer subnet points to the VPN tunnel interface.
Then check firewall policies:
show firewall policy
Ensure there’s a policy allowing VPN traffic. Common mistake: srcintf and dstintf are swapped.
Step 7: Optimize DPD and NAT-T
If the tunnel drops frequently, tune the DPD parameters:
config vpn ipsec phase1-interface
edit <tunnel_name>
set dpd on-idle
set dpd-retryinterval 10
set dpd-retrycount 5
end
on-idle only sends DPD probes when there’s no traffic, reducing network overhead.
NAT-T configuration:
config vpn ipsec phase1-interface
edit <tunnel_name>
set nattraversal enable
set keepalive 10
end
keepalive 10 sends a NAT-T keepalive every 10 seconds, preventing NAT timeout.
Performance and Security Trade-offs
When tuning DPD and NAT-T, you’re balancing performance against reliability.
| Parameter | Aggressive | Conservative | Use Case |
|---|---|---|---|
| DPD interval | 3 seconds | 30 seconds | Aggressive for HA, conservative for unstable links |
| DPD retry count | 3 | 10 | Few retries for fast failover, many for jitter tolerance |
| NAT-T keepalive | 5 seconds | 30 seconds | Short interval prevents NAT timeout, long saves bandwidth |
| Phase 2 lifetime | 3600 seconds | 86400 seconds | Shorter is more secure, longer reduces rekey overhead |
My go-to for public internet links: DPD interval 10 seconds, 5 retries, NAT-T keepalive 10 seconds. Works well in most environments.
Alternatives: When to Ditch IPsec
IPsec is powerful, but it’s also a configuration nightmare. If you’re done with it, consider:
- WireGuard: Simpler, faster, but requires FortiGate 7.2+. The r/homelab crowd on Reddit is all over Tailscale, which is basically WireGuard with training wheels.
- SSL VPN: Easier to configure than IPsec, but worse performance. Good for remote access, not site-to-site.
- SD-WAN: If you’ve got the budget, FortiGate’s SD-WAN can automatically pick the best link and reduce the impact of VPN drops.
But honestly? IPsec is still the standard for site-to-site. The trick is to configure it right and tune it properly. Don’t expect set-and-forget.
Community War Stories
Reddit’s been a goldmine of real-world pain:
- Someone on r/networking had VPN connected but RDP wouldn’t work. After hours of debugging, they found the firewall policy didn’t allow port 3389. We’ve all been there.
- A post on r/fortinet described tunnels that required a full device reboot to recover. Fortinet’s official fix? Upgrade to 7.2.4 or later—older versions had a memory leak in the IKE process.
- The r/india ISP hijacking post is extreme, but it’s a reminder: your VPN traffic can be interfered with. If your tunnel keeps dropping, try changing ports or protocols.
FAQ
Q: Why does my FortiGate VPN tunnel show Up but I can’t ping the peer?
A: Most common causes are Phase 2 selector mismatch or missing routes. Check get router info routing-table to confirm the route points to the VPN interface, then use diagnose vpn tunnel list to verify the Phase 2 local/remote address ranges. Another possibility: firewall policy srcintf and dstintf are reversed.
Q: My tunnel drops frequently. How do I diagnose it?
A: Enable IKE debug logging: diagnose debug application ike -1 and diagnose debug enable. Look for DPD timeout or peer not responsive. If it’s DPD timeout, adjust the DPD interval and retry count. If you see no proposal chosen, check Phase 1 parameter matching.
Q: I have to reboot the device to restore the tunnel. What’s the fix?
A: This is a known issue in older FortiGate firmware, usually caused by IKE process deadlock or memory leak. First, try execute vpn tunnel down and execute vpn tunnel up to force a rebuild. If that doesn’t work, upgrade to 7.2.4 or later. Fortinet fixed this in version 7.2.4.6880.
Q: Should I enable NAT-T?
A: If at least one end of the VPN is behind NAT, yes. Use config vpn ipsec phase1-interface to set set nattraversal enable and set keepalive 10. When in doubt, enable it by default—most public internet environments have NAT somewhere.
Q: Do Phase 1 and Phase 2 parameters need to match exactly?
A: Phase 1 encryption, hash, DH group, and lifetime must match exactly. Phase 2 encryption and hash must also match, but lifetime can differ (the shorter one is used). Phase 2 local/remote address ranges must match exactly—no overlaps or gaps.
References and Community Insights
This guide synthesizes knowledge from:
- Fortinet official documentation: Troubleshooting Tip: IPsec VPN tunnels (v7.2+)
- Reddit communities: r/fortinet, r/networking, r/india VPN discussions
- Personal production experience managing FortiGate VPNs
Special shoutout to the r/india poster whose ISP hijacking story serves as a reminder that network security has no silver bullets. Every layer matters.
