An IPsec tunnel can show an established negotiation state while a protected application still fails. That is the single most useful distinction in FortiGate site-to-site VPN troubleshooting. The active FortiOS 7.6 Administrator exam expects candidates to understand IPsec concepts, the VPN wizard, redundant or partially meshed tunnels, logs and operational fault scenarios. A strong answer accounts for both security negotiation and actual packet forwarding over the configured tunnel.
The design goal is controlled connectivity between defined networks without unnecessarily exposing traffic or relying on one transport path. The operational goal is to determine whether an observed failure belongs to key negotiation, selectors, routing, firewall policy, NAT, underlay connectivity or the destination itself.
Understand the roles of IKE and protected data traffic
IPsec uses negotiated security relationships to protect eligible traffic between peers. Internet Key Exchange (IKE) establishes agreement on authentication and cryptographic parameters and supports creation of the relevant security associations. Protected application packets then traverse the IPsec path when they match the configured design. Failure in either stage can prevent use of the VPN.
For an administrator, that means two sets of evidence. Negotiation logs help identify why peers cannot agree on parameters, credentials or reachability. Data-plane captures and routing information help explain why a negotiated tunnel does not carry the desired application flow. The IPsec security association model provides conceptual grounding, but FortiOS 7.6 configuration details should be checked against current Fortinet documentation.
Plan key and certificate management deliberately. Authentication material should be protected and rotated using approved procedures; peers must agree on supported settings. A mismatch or expired certificate can prevent negotiation before a firewall policy for the protected network even becomes relevant.
Use the VPN wizard as a starting point, not a substitute for design
FortiOS provides supported wizard paths for common VPN scenarios. Wizards can build related tunnel, route or policy objects to reduce setup errors, but a candidate should still be able to explain what those objects do and verify that the resulting definitions match the real topology.
Before using a wizard, document each peer’s reachable endpoint, the protected local and remote networks, intended authentication, available underlay and desired return route. This prevents a common failure in which a tunnel appears established but the connected application subnet is missing from a route or security rule.
The distinction between a remote public endpoint and a protected private prefix is fundamental. Reachability to the public peer enables negotiation; reachability to the private application requires the encrypted forwarding path and matching policies. Do not mistake a successful ping to the peer’s public address for proof that internal users can reach the remote database.
Consider selectors, phase relationships and route eligibility
Peer configurations must agree on the intended protected traffic. Phase-related settings and traffic selectors define what can be carried through the negotiated tunnel under the selected design. A mismatch may allow some services while preventing others, or cause negotiation failures for particular traffic. Review the actual peers’ settings and current FortiOS policy/route model instead of changing them indiscriminately.
With route-based IPsec, the tunnel is represented through an interface and routing determines whether a destination should use it. A correct IPsec peer configuration cannot compensate for a route that points toward an unrelated internet connection. Conversely, an installed route to the tunnel is not enough if the corresponding firewall policy rejects the session.
When investigating, draw the outbound and return paths separately. The near-side FortiGate can send a protected packet into a working tunnel while the far-side internal router sends a response through another gateway. That asymmetry produces a failure that should be diagnosed from packet and route evidence, not from repeated IKE resets.
Plan redundancy around real failure domains
A fully meshed arrangement establishes connectivity among many sites, while a partially meshed design provides selected direct relationships and may rely on transit through hubs for other traffic. The architecture should match application needs, operational capacity and failure tolerance. More tunnels are not automatically better if their route priorities and monitoring are ambiguous.
Redundant site-to-site paths can involve two ISPs, two peers, two tunnels or alternate intermediate sites. Distinguish these failure domains. Two tunnels over one provider may survive a peer configuration issue but not a physical provider outage. Two independent underlays improve transport diversity, but routing and firewall-policy logic must still select the surviving path correctly.
A practical design worksheet records each tunnel’s peer endpoints, underlay interface, protected networks, route selection, health monitoring and allowed services. That document lets an engineer explain which link should carry new traffic when a failure happens and what interruption might affect already established sessions.
Check both sides of the tunnel on an application failure
A useful first-pass sequence is to verify that both peers are reachable through the underlay; inspect negotiation and established security associations; check the near-side route and firewall policy; observe traffic sent through the tunnel; verify receipt and a valid route on the far side; then inspect the application’s own listener and access controls.
For example, a branch can reach one server across the tunnel but not a newly added subnet. This suggests examining the protected network definitions, selectors and far-side route/policy before assuming that the entire tunnel is down. If no application works after an ISP failure, the underlay path and route to the peer are stronger first hypotheses.
Fortinet’s 7.6 static-routing documentation links to common IPsec and redundant-routing arrangements. The relationship matters because tunnel success and destination routing are separate; changing a tunnel’s crypto proposals cannot fix a more-specific route installed toward the wrong next hop.
Interpret VPN logs without overclaiming
Negotiation logs can report failures related to peer reachability, authentication or policy agreement. Data-plane and firewall logs may show whether selected sessions matched the required route and security rule. The meaning of a particular event depends on which peer generated it and when. A log entry that reports negotiation success is not an audit of every protected application.
When a tunnel flaps, correlate timestamps with ISP status, peer reboot, configuration change and route selection. A recurring negotiation failure after an address change may be explained by a stale peer definition or reachable endpoint; repeated timeouts during provider instability suggest a different cause. Use logs from both peers where approved and possible.
Session logs may use translated or original addresses depending on the chosen observation point. An investigation should explicitly identify these representations, especially where IPsec spans overlapping private address ranges and NAT is part of the approved design.
NAT should be intentional in VPN designs
Some site-to-site routes carry private addresses without translation. Others require address translation because networks overlap, business policy calls for controlled source identities or partner systems expect particular ranges. Apply NAT only when the addressing design justifies it; unnecessary NAT can make troubleshooting harder and reduce the remote application’s visibility of the original client.
If two organizations both use 10.0.0.0/8 internally, an overlap strategy may involve translating one side or using distinct mapped prefixes. Whatever method is selected must be consistent with tunnel selectors, policies and return routing. A one-sided change that affects only the sending firewall can cause the receiving peer to reject traffic or route it incorrectly.
For general context, site-to-site VPN tunnel operation explains why the IPsec relationship must be paired with normal network forwarding. In an exam-specific article, always return to the versioned FortiGate design rather than assuming another vendor’s VPN policy model applies unchanged.
Respond to partial failover and intermittent connectivity
Consider a branch with two tunnels to headquarters. The primary ISP fails and routing should shift to a backup tunnel. New client connections succeed but one long-running application session breaks. The possible explanation includes session state and source-path changes rather than total VPN failure. Verify the route and active tunnel for new packets, then investigate the application’s recovery behavior separately.
In another case, the backup tunnel negotiates correctly but no protected traffic passes. Inspect whether the destination prefix is routed into it and whether firewall policies reference the correct tunnel interface. This is a common gap between “tunnel up” and “service available.” A tunnel-status icon provides useful information but not a complete service validation.
Health monitoring should be aligned with the actual destination. A check against only the remote peer public IP can remain healthy even when an internal datacenter network behind that peer is unavailable. Use an appropriate combination of route status, negotiated tunnel state and application-specific monitoring to support resilience claims.
Operate IPsec with change control and a rollback path
VPN changes can disrupt entire branch offices. Before updating phase settings, protected networks or routing, preserve the current FortiGate configuration and identify which peer and dependency will be changed. Coordinate updates across both administrative teams when each site has a separate owner, and define how to regain management connectivity if the primary secure path fails.
Post-change verification should include peer agreement, new session forwarding, permitted application connectivity in both directions, relevant event/log records and behavior during an authorized controlled failure. If those tests were not performed, the deployment should not be described as independently validated merely because the configuration objects look complete.
For exam preparation, the strongest case studies name a precise failure, two plausible hypotheses and the evidence that distinguishes them. If a branch app fails, ask whether IPsec negotiation succeeded, whether the route selected the right tunnel, whether a firewall policy allowed the traffic and whether the return path exists. This sequence turns site-to-site VPN from a memorized wizard into a defensible network design and troubleshooting skill.