A site-to-site IPsec VPN may be fully configured yet carry no useful application traffic. Peer authentication can succeed while phase-two traffic selectors disagree; the tunnel can establish while a return route is absent; or an SD-WAN or failover design can choose a path the far end does not accept. Fortinet’s current NSE 4 FortiOS 7.6 Administrator exam emphasizes meshed or partially redundant IPsec VPNs, their logs and troubleshooting. Approach each symptom by identifying which layer has proven successful and which has not.
Separate IKE negotiation from protected data traffic
IPsec phase one establishes the secure IKE relationship between peers. Verify reachable public peer addresses, peer identity, compatible proposals, authentication credentials or certificates, and the intended network path. The FortiOS 7.6.0 phase-one reference explains the initiator/responder negotiation and resulting IKE security association. A phase-one failure cannot be fixed by adding a LAN-to-LAN firewall accept rule; the peers have not yet established the control channel they need.
Phase two establishes security associations for protected traffic and must align with the intended traffic selectors or proxy IDs and compatible cryptographic parameters. One peer accepting phase one does not prove that phase-two proposals match. When both phases are up yet a ping fails, test route selection, firewall policy, NAT treatment, source address and return traffic before rotating credentials without evidence.
Route-based VPNs use virtual interfaces and policies
A route-based IPsec configuration supplies a virtual interface that participates in routing and is referenced by policies. The FortiOS 7.6 VPN security-policy guide describes directional accept policies for traffic between private interfaces and the virtual IPsec interface. One-way success is therefore unsurprising when the reverse-direction policy, remote route or selector is missing. Site-to-site policy decisions should be narrow and normally avoid unintended address translation across the protected networks.
Plan both ends of the topology, not only the local FortiGate. For example, headquarters may route 10.20.0.0/16 toward a branch while the branch firewall has a more specific application subnet or overlapping address object. Check whether source and destination addresses survive any local SNAT or VIP rules. The existing NAT and Central SNAT guide covers the translation order; the firewall policy walkthrough explains how a permitted tunnel session still needs a matching service and interface pair.
Why partial redundancy needs route design
For two branches and headquarters, a primary tunnel may use ISP A and a backup tunnel ISP B. Configure suitable peer reachability, routing priorities or SD-WAN choices, and independent policy paths. If two tunnels are logically up, the active forwarding path still depends on routing and associated SD-WAN rules. Link health alone is not sufficient: confirm the backup can reach the target prefix and that both peers will return traffic consistently over the expected path.
A meshed topology adds alternate branch-to-branch connections, which can reduce dependence on headquarters but complicate routes, selectors, scale and security policy. A hub-and-spoke design centralizes policy and may simplify administration, but headquarters must handle the chosen traffic load and resilience requirements. The routing and SD-WAN article explains the relationship between route eligibility, performance SLA measurements and selected members. Avoid assuming that creating a second VPN object automatically produces failover.
Read VPN logs and negotiation stages
VPN events can identify failed authentication, proposal mismatches, dead-peer detection, phase-two negotiation problems and tunnel state changes. Collect the minimum relevant peer, timestamp, error and negotiation phase. When a tunnel never establishes, verify that IKE packets reach the peer through any upstream NAT and access controls. When a tunnel is established but packets disappear, compare the protected source/destination tuple, virtual interface counters, forward-traffic policy and return route on both sides.
The FortiGate logs and FortiAnalyzer guide explains how to correlate local VPN events with centrally stored records. A packet sniffer on an external interface can show whether encrypted traffic reaches a peer, while a scoped debug flow capture can clarify processing of the inner packet after decryption. Do not enable persistent unrestricted debug logging on a production perimeter simply to gather more output.
Contrast the exam baseline with SSL VPN upgrades
Site-to-site IPsec is distinct from SSL VPN remote-access tunneling. FortiOS 7.6.0 retains SSL VPN modes documented for that release; later 7.6.3 removes the proprietary SSL VPN tunnel mode and renames web mode Agentless VPN. That operational change makes IPsec migration important, but it should not be falsely described as a new phase-one behavior in the 7.6.0 NSE 4 exam. The existing SSL VPN-to-IPsec transition article clarifies that version-sensitive remote-access case.
For remote access, user authentication and device posture add further requirements. Do not transplant a site-to-site pre-shared key and branch selectors into an end-user scenario without adapting identity, address assignment and policy. For cloud workloads, IPsec establishes protected connectivity, but the cloud route tables and workload security controls still decide which packets encounter the chosen virtual firewall or service.
A reproducible two-link failure test
Build two test FortiGate peers with LAN subnets and two simulated WAN paths. Verify that phase one and phase two establish on the primary path, then confirm an allowed TCP application succeeds in both directions. Capture working IKE and traffic logs. Disable only the primary test path and document which backup tunnel is selected, how quickly application connectivity returns, which sessions reset, and whether DNS and NAT-dependent applications behave differently.
Repeat with a deliberately wrong phase-two selector, then with an absent return route. Explain why the symptoms and correct repairs differ. Before declaring success, restore every intended route and firewall policy and verify no accidental any-to-any rule remains. The transferable exam skill is to say precisely: peer reachable, IKE authenticated, phase-two negotiated, route selected, policies matched, return path valid.