An IPsec tunnel can be “up” and still fail the business purpose it was built for. IKE may authenticate successfully while Phase 2 selectors do not match. Security associations may exist while routes point elsewhere. Routes may be correct while firewall policy blocks the interesting subnets. The tunnel indicator is therefore only one checkpoint in a longer data path.
This is why the current NSE 4 FortiOS 7.6 Administrator path benefits from a failure-oriented mental model. Rather than memorizing wizard fields, operators should understand how identity, cryptographic negotiation, traffic selectors, routing, policy, NAT, and return-path symmetry combine to deliver traffic. A general IPsec foundation helps, but FortiGate troubleshooting requires following the actual session.
A practical VPN review begins with a protected relationship: which networks or users must reach which resources, which peer is trusted, what traffic must remain private, and how will both ends prove that the same relationship was negotiated? The configuration should express that relationship clearly enough that failure can be isolated layer by layer.
Phase 1 proves peer trust, not application reachability
Phase 1 establishes the IKE relationship. The peers negotiate compatible parameters, authenticate each other, and create the secure control channel used to build IPsec security associations. A Phase 1 failure usually points toward reachability to the peer, identity, authentication material, IKE version, proposals, or policy that affects negotiation traffic.
When Phase 1 succeeds, the operator has proved only that the gateways can establish an authenticated relationship. Nothing yet proves that a client subnet, server network, or application can use the tunnel. Treating an IKE success message as “VPN working” skips the layers where many production incidents actually live.
Phase 2 must describe the same protected traffic on both sides
Phase 2 determines how data traffic is protected. Selector mismatches are common when one side defines a broad network and the other defines a narrow subnet, when address objects changed, or when a new network was added on only one peer. The result can be a tunnel that partly works: some applications succeed while new or less common subnets fail.
The diagnostic question is simple but often overlooked: do both peers agree about the traffic that should enter this security association? Compare local and remote selectors as a pair, not as independent configuration screens. In route-based designs with broader selectors, verify that routing and policy take over the responsibility that narrower selectors would otherwise express.
Routing decides whether interesting traffic ever reaches IPsec
If the destination route points to the internet interface instead of the tunnel, no amount of cryptographic debugging will fix the user flow. Likewise, a more specific route can override a default tunnel path, and dynamic routing can change forwarding after a topology event. VPN troubleshooting must therefore include the forwarding table before configuration changes are made.
Route-based VPNs are powerful because they make the tunnel behave like an interface, but that also means ordinary routing mistakes become VPN incidents. The most useful question is not “is the tunnel up?” but “for this exact destination, which next hop and interface does FortiGate select right now?”
Firewall policy still governs traffic crossing the tunnel
FortiGate does not stop enforcing policy because traffic is encrypted. Policies must allow the relevant source, destination, service, and interface direction. Return traffic must also be compatible with policy and state. A tunnel can therefore establish normally while application traffic is denied at the firewall layer.
This is where broad emergency rules are dangerous. An “allow any” policy may restore service and conceal the actual mismatch, leaving a larger trust boundary than intended. Better practice is to identify the missing policy relationship, correct only that relationship, and keep logging enabled long enough to prove the intended sessions—not unrelated traffic—are passing.
NAT and overlapping address space create problems that look cryptographic
Site-to-site VPNs often connect organizations that did not coordinate address plans. Overlapping RFC1918 networks can make the same destination mean two different places. NAT can resolve the ambiguity, but it introduces translated identities that must be reflected in routing, selectors, policy, and troubleshooting.
Even without overlap, accidental source NAT can break expectations when the remote peer is configured to accept the original subnet. The safe method is to trace the packet before and after translation and compare that with the traffic selectors. If the address entering IPsec is not the address the peer expects, the problem is architectural rather than cryptographic.
MTU and fragmentation failures often appear only after basic tests pass
A ping or small TCP handshake can work while large transfers fail because encryption adds overhead and reduces effective payload size. Path MTU discovery, fragmentation policy, MSS clamping, provider behavior, and intermediate filtering can all influence the outcome. Users then report a “slow VPN” or an application that freezes only on specific transactions.
The clue is that reachability exists but payload size changes the result. Test progressively larger traffic and compare behavior across paths. This is also why generic VPN failure discussions such as anatomy of a VPN failure are most useful when they lead to a concrete hypothesis instead of a checklist of possible causes.
Asymmetric return paths can make stateful inspection look inconsistent
A packet can traverse the tunnel toward a server while the reply follows another firewall, another tunnel, or a direct internet route. From the user’s perspective the VPN is intermittent; from each device’s perspective the observed half of the flow may look valid. Stateful firewalls require both directions of the session to align with the expected path.
Multi-WAN and SD-WAN deployments make this especially important. The design should define how return traffic is attracted to the same security boundary and what happens when the preferred path fails. When symmetry cannot be guaranteed, the architecture needs an explicit alternative rather than relying on chance.
Remote-access IPsec changes the authentication and endpoint story
FortiOS 7.6.3 shifted remote access toward IPsec, including the ability to transport IPsec over TCP 443. That puts more attention on user authentication, endpoint configuration, address assignment, split-tunnel decisions, and identity-aware policy. The cryptographic tunnel is only one control in a broader remote-access system.
For modern deployments, the key is to distinguish site-to-site trust from user/device trust. A branch gateway usually represents a managed network boundary; a remote endpoint represents a user, device posture, and changing access context. The same IPsec technology can serve both, but the surrounding controls and evidence should be different.
A realistic failure sequence shows why this ordering matters. A company adds a second internal subnet behind one peer. IKE remains healthy and existing users continue working, so the change appears safe. New users cannot reach the new subnet. An operator clears the tunnel repeatedly, then changes proposals, because the dashboard says the VPN is the problem. The actual fault is a Phase 2 selector or route that never included the new network. The repeated resets add disruption without changing the condition that prevents the packet from entering the correct security association.
The same discipline applies to security hardening. Stronger proposals, certificate authentication, local-in policy for unwanted IKE traffic, and reduced peer exposure can improve the tunnel’s control boundary, but each hardening step should be tested against interoperability and recovery. An IPsec design is not secure merely because it uses modern cryptography; it must also restrict which peers can negotiate, which networks can traverse the tunnel, and which operators can alter that trust. The approved comparison of IPsec and other VPN approaches is useful only after those specific trust requirements are understood.
Finally, tunnel monitoring should include business-level tests. A simple IKE or ping monitor can confirm infrastructure availability while the application is broken by DNS, authentication, or a server-side dependency. Combining tunnel state with route, session, and synthetic application checks gives the team a much better definition of “VPN healthy.”
High availability adds one more layer that deserves explicit testing. If a FortiGate cluster fails over, the VPN design should preserve or rapidly restore the required security associations, routes, and policy state without creating a second outage longer than the original device failure. Test peer behavior, dynamic routing convergence, and application recovery during planned HA events. A tunnel architecture that works perfectly on a single appliance but becomes unpredictable during cluster failover is not production-ready.
The clean troubleshooting order is peer → SA → route → policy → session → application
A repeatable investigation starts by proving peer reachability and Phase 1, then verifying Phase 2/security associations for the intended traffic. Next confirm the route into the tunnel, firewall policy and NAT, then inspect live session behavior and finally the application itself. Each step should either confirm the current hypothesis or narrow the next one.
That sequence prevents the most expensive kind of VPN troubleshooting: changing several crypto parameters, clearing tunnels, and restarting clients until service returns without understanding why. A FortiGate administrator should be able to explain not just that the tunnel is up, but how a particular packet became protected, forwarded, allowed, returned, and accepted by the application.
