The VPN diagnostic output from the FortiGate hub (Exhibit 1) shows that Phase 2 is established, but the hub has only decrypted 3 packets (dec:pkts/bytes=3/120). This extremely low count indicates that the FortiSASE spoke is not forwarding the user's ICMP traffic into the IPsec tunnel. In FortiSASE Secure Private Access (SPA) architectures, dynamic routing via BGP over the IPsec tunnel is required to advertise hub subnets to the SASE nodes. If FortiSASE does not receive the BGP route for the webserver's destination subnet, it cannot route the ping traffic toward the hub. Exhibit 2 confirms the firewall policy explicitly allows ICMP, meaning routing is the point of failure.

A: The FortiSASE Secure Private Access policy exhibit explicitly shows the configured Service is set to ALL_ICMP, which natively permits ping traffic.

B: The diagnostic output shows src: 0.0.0.0-255.255.255.255 and dst: 0.0.0.0-255.255.255.255. These are universal wildcard selectors (0.0.0.0/0) that do not restrict any subnet traffic.

D: If NAT were the missing component, the packets would still route into the tunnel, meaning the hub's decrypted packet count (dec:pkts) would be actively incrementing rather than stuck at 3.

Fortinet, Inc. FortiSASE Administration Guide: Secure Private Access (SPA) Hub configuration. (Section: Configuring BGP routing for SPA). Details the requirement of BGP peering over IPsec dial-up interfaces to exchange routes between the FortiGate hub and FortiSASE security PoPs.

Fortinet, Inc. FortiOS CLI Reference. (Section: diagnose vpn tunnel list). Explains the interpretation of IPsec tunnel statistics, specifically that dec:pkts represents inbound ESP packets decrypted by the local gateway.