Site-to-site IPsec troubleshooting becomes manageable when you separate tunnel establishment from traffic forwarding. Phase 1 creates the IKE security association between peers. Phase 2 creates the IPsec security association for protected traffic. Routing and firewall policy then determine whether real packets actually enter and leave the tunnel.
The NSE 4 FortiOS 7.6 Administrator perspective is practical: a tunnel can be “up” while applications still fail, and a traffic problem can look like an IKE problem when the tunnel is merely idle. Work from the outside inward and identify exactly which stage is broken.
Start with reachability to the VPN peer
Before debugging cryptography, verify that each peer can reach the other’s public address over the expected path. Check the WAN interface, default or specific route, upstream NAT, and any local-in restrictions that could prevent IKE packets from reaching FortiGate.
IKE commonly uses UDP 500 and may use UDP 4500 when NAT traversal is involved. ESP may also matter depending on the topology. Packet capture can confirm whether negotiation traffic leaves one side and whether a response returns.
If no response comes back, changing proposals repeatedly is unlikely to help. The failure is still basic reachability, upstream filtering, wrong peer address, or a remote endpoint that is not listening where expected.
Phase 1 failures are usually identity or proposal disagreements
Phase 1 must establish a compatible IKE relationship. Verify IKE version, authentication method, pre-shared key or certificate, peer identity, proposal algorithms, Diffie-Hellman groups, and any local or peer IDs used to identify the endpoints.
Time and certificates matter when certificate authentication is used. An expired certificate, untrusted issuer, wrong identity, or significant clock problem can prevent negotiation even though network reachability is perfect.
Use IKE diagnostics to read the actual negotiation rather than guessing. A proposal mismatch, authentication failure, and unreachable peer produce different evidence. The more precisely you classify the error, the less likely you are to make unrelated changes that complicate both sides.
Phase 2 depends on matching protected traffic definitions
Once IKE succeeds, phase 2 negotiates IPsec SAs. The peers need compatible encryption and integrity settings, and their traffic selectors must agree on what networks or addresses should be protected.
Selector mismatches are a classic cause of tunnels that establish partially or fail when traffic begins. One side may define a local subnet as 10.10.0.0/16 while the other expects only 10.10.20.0/24. Route-based designs can use broader selectors, but both peers still need compatible expectations.
FortiOS diagnostic commands can show whether IKE and IPsec SAs are established and which selectors are active. That evidence is more useful than treating “phase 2 down” as a generic VPN error.
Routing decides whether traffic enters the tunnel
An established IPsec SA does not force every relevant packet into it. FortiGate still performs routing. In a route-based VPN, the destination must resolve toward the IPsec interface through a static, dynamic, or policy-derived route as appropriate.
Check for more-specific competing routes, SD-WAN rules, or policy routes that send the packet elsewhere. A tunnel may be fully healthy while the routing table chooses a different WAN path.
Return routing matters just as much. The remote network must know how to return traffic toward its side of the VPN. Asymmetric return paths often appear as one-way counters or sessions that never receive a reply.
Firewall policies must permit both the intended direction and services
Route-based VPN traffic normally needs firewall policy from the source interface or zone to the IPsec interface, with the correct source, destination, service, and action. The remote side needs equivalent policy for its own traffic direction.
Do not confuse tunnel negotiation with data-plane policy. Phase 1 can come up because IKE terminates on the FortiGate, while user traffic is still denied by a missing or mismatched firewall rule.
If the policy uses security profiles, inspect those logs as well. Application control, IPS, web filtering, or SSL inspection can affect traffic after the VPN and firewall policy are otherwise correct.
NAT can silently break site-to-site expectations
Site-to-site VPNs commonly preserve original private addresses so each side can recognize the protected subnets. An unintended source-NAT rule can change the source before it reaches the tunnel, causing selector, policy, or return-routing problems.
Document whether NAT is supposed to occur. If the design requires overlapping networks, deliberate translation may be necessary, but both sides must then agree on the translated prefixes. The general mechanics in NAT design are directly relevant because IPsec protects whatever addresses exist at the point where the VPN policy applies.
When troubleshooting, compare session information and packet captures to verify the actual source and destination before and after translation. Do not rely only on the configuration name.
Use counters and diagnostics to locate the direction of failure
FortiOS provides IKE gateway and tunnel diagnostics that show SAs, proposals, selectors, lifetimes, and packet counters. A tunnel with increasing outbound encrypt counters but no inbound decrypt counters suggests a different problem from a tunnel that has no traffic counters at all.
Packet capture on the LAN and WAN sides can show whether plaintext traffic reaches the FortiGate and whether encrypted traffic leaves. Debug flow can show the route and firewall policy selected for the inner packet. IKE debug can explain negotiation failures.
Use the narrowest diagnostic that answers the current question. Turning on every debug at once usually produces noise and makes a simple failure harder to see.
Separate VPN reliability from generic internet reliability
Loss, MTU problems, asymmetric paths, unstable WAN links, and NAT devices can all affect a tunnel even after the configuration is correct. The practical causes described in VPN reliability troubleshooting can therefore overlap with FortiGate-specific diagnostics.
For route-based designs, also consider MTU and fragmentation when small packets work but large transfers stall. Path MTU discovery can fail when intermediate devices block required ICMP messages, and encapsulation reduces the effective payload size.
A related IPsec over GRE configuration can help reinforce the distinction between encrypted transport and the routing design built over it, even though FortiGate uses its own configuration model.
Follow the same order every time
A reliable sequence is peer reachability, phase 1, phase 2, route, firewall policy, NAT, session state, and packet counters. That order keeps you from rewriting phase 1 because an application server lacks a return route or from adding policies when the peers never authenticated.
Record the known-good state for important tunnels: peer addresses, expected proposals, selectors, routing, policies, and typical counters. Baselines make incident response faster because the team can compare today’s failure with yesterday’s working design.
The goal of VPN troubleshooting is not to make the dashboard icon green. It is to prove that protected traffic enters the correct tunnel, is encrypted and transported successfully, is accepted by the remote FortiGate, reaches the destination, and returns over the expected path.
Tunnel monitoring and dead-peer detection should match the failure you need to detect. DPD helps identify an unreachable IKE peer, but an established peer can still have an application-path problem behind it. For critical links, combine tunnel state with traffic or route monitoring so operations can distinguish “peer alive” from “service reachable.”
Overlapping address space deserves explicit design. If both sites use the same RFC1918 subnet, normal routing cannot uniquely identify the remote network. NAT, virtual routing domains, or address renumbering may be required, and the translated prefixes must be reflected consistently in policies and selectors.
Dynamic routing over route-based IPsec adds another troubleshooting layer. The tunnel can be established while BGP or OSPF adjacency is down, or the routing protocol can learn a route that competes with a static path. Confirm the control-plane neighbor and the resulting forwarding table separately from IPsec status.
Rekey events can expose mismatched lifetimes or interoperability problems that are invisible immediately after a manual tunnel restart. If a tunnel works for a predictable period and then fails, examine IKE/IPsec lifetime, reauthentication, and remote-peer logs rather than assuming general instability.
Keep both peers’ clocks and logs aligned. Correlating one FortiGate’s IKE message with the other device’s response is much easier when timestamps are trustworthy. During a multi-vendor incident, collect the negotiation evidence from both ends before changing proposals so you do not erase the state that explains the original failure.
A complete VPN runbook should therefore include peer reachability tests, known-good phase 1 and phase 2 parameters, expected routes, firewall policies, NAT behavior, diagnostic commands, normal tunnel counters, and escalation contacts for the remote site. That documentation shortens incidents because the team starts from evidence rather than reconstructing the design under pressure.
For multi-site environments, naming and templates matter. Standard phase 1 and phase 2 names, address objects, and policy structure make it easier to compare a failing tunnel with a healthy peer. Unique ad hoc configurations increase the chance that small differences in proposals, selectors, or NAT behavior go unnoticed.
After recovery, confirm rekey and bidirectional application traffic rather than declaring success as soon as the tunnel icon turns green. A fix that only survives until the next rekey is not a stable resolution.
Security review should also verify cryptographic settings periodically. Algorithms and minimum standards evolve, and a tunnel that was acceptable when deployed may later require stronger proposals. Coordinate changes with the remote peer and test rekey behavior so security improvements do not create an avoidable outage.
Monitoring should distinguish tunnel availability from service availability. An IPsec SA can remain established while the remote application, route, or protected subnet is unavailable. Synthetic tests to important destinations can reveal this gap and prevent dashboards from reporting a healthy VPN when users still cannot reach the service the tunnel exists to carry.