Scope: FortiOS 7.4 documentation, IPv4 route-based site-to-site IPsec. The topology and examples are illustrative. Confirm syntax and output on your build and in the correct VDOM.
An established IKE connection tells you the peers can negotiate. It does not prove that a particular application flow matches an IPsec security association or has a working return path. Test one flow from an actual LAN client before changing the tunnel.
Symptom and test flow
In this example, Site A client 10.10.10.25 cannot reach Site B server 10.20.20.50 on TCP port 443 through tunnel HQ-BRANCH. Record the source, destination, protocol, port, time, and whether the failure affects one host or an entire subnet. Use the real application port. A successful ping does not prove HTTPS works.
1. Confirm the IPsec SA covers the flow
get vpn ipsec tunnel summary
diagnose vpn tunnel listFind HQ-BRANCH and the relevant Phase 2 entry. Check that an active SA exists and that its traffic selectors cover the actual addresses and protocol. At the peer, the corresponding local and remote selectors are reversed. For broad selectors, continue to routing and policy checks. Tunnel diagnostic output can contain cryptographic key material. Keep the raw output private and redact it before sharing.
2. Follow the route and policy on both peers
get router info routing-table allOn Site A, check that the route for 10.20.20.50 leads to the expected tunnel or SD-WAN path. On Site B, check the return route to 10.10.10.25. Also check policy routes and SD-WAN rules where configured. The routing table alone does not show which of those rules a specific flow matched.
For a connection initiated from Site A, check the LAN-to-tunnel policy on Site A and the tunnel-to-LAN policy on Site B. Verify source, destination, service, and rule order. Replies to the same stateful session do not need a separate reverse policy. A new connection initiated from Site B does. If the design preserves original addresses, check that policy NAT or Central SNAT is not translating the flow unexpectedly.
3. Compare counters and capture both directions
Record the tunnel’s encrypt and decrypt counters, generate a few TCP connection attempts from the LAN client, then compare both peers. Counters may also include unrelated traffic. Correlate changes with a filtered capture.
diagnose sniffer packet any 'host 10.10.10.25 and host 10.20.20.50 and tcp port 443' 4 20Run the capture on both peers, one at a time or with two sessions. Verbosity 4 shows interface names, and 20 caps the number of matching packets. Press Ctrl+C if fewer matches arrive. This filter targets the original, clear-text addresses. If intentional NAT is in use, adjust the filter to the addresses visible at the capture point.
No client SYN at Site A: check the endpoint, default gateway, VLAN, and upstream path. SYN at Site A but no matching traffic at Site B: compare tunnel counters, selectors, routing and policy on both sides. SYN reaches the server but no SYN-ACK returns: check whether the service is listening, the host firewall, and the server’s return gateway.
A quiet CPU capture is inconclusive on hardware-offloaded paths. Check the platform’s offload behavior and corroborate with counters or an endpoint capture before drawing a conclusion. This workflow does not require clearing SAs, restarting the tunnel, or changing offload settings.
4. Verify the fix
Repeat the same test from 10.10.10.25 to 10.20.20.50:443. Confirm the TCP handshake and that the actual application responds. Verify the expected egress path and bidirectional traffic. If the issue was intermittent, repeat under the same conditions that triggered it.
Fortinet references
IPsec diagnostic commands · Packet capture · CLI troubleshooting cheat sheet · VPN and ASIC offload
Related guides
Troubleshooting the peer firewall? See the Palo Alto IPsec troubleshooting guide or the Check Point IPsec troubleshooting guide.