Site-to-Site VPN Tunnel shows UP but no traffic flows in either direction

Hello.

The "Tunnel status" in the AWS console alone does not allow you to list Phase 1 and Phase 2 SAs in the way that the FortiGate diagnose vpn tunnel list command does.
When you enable the tunnel activity log for each tunnel, details of the IKE/IPsec negotiation are output to CloudWatch Logs.
I recommend checking this log for any configuration mismatches with the on-premises environment.
https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-logs.html
https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-logs.html#sample-log-ikev1

The symptom pattern — Tunnel 1 UP, traffic sent but 0 bytes received, DestinationHostUnreachable from EC2 — most likely points to a Phase 2 traffic selector (proxy-ID) mismatch.

How to verify Phase 2 SA status from AWS:

Enable Site-to-Site VPN logging to CloudWatch (VPC Console → VPN Connections → Actions → Modify VPN tunnel logging). Once enabled, check the log stream for Phase 2 SA events:

fields @timestamp, details | filter details like /Phase 2 SA/ | sort @timestamp desc | limit 20

Look for the traffic selectors field. AWS expects 0.0.0.0/0 ↔ 0.0.0.0/0. If the customer gateway side shows narrow selectors (e.g., 192.168.1.0/24 ↔ 10.0.0.0/16), that's the root cause — packets outside those selectors are silently dropped by the VGW.

Ref: Troubleshooting IPsec/Phase 2 issues (https://docs.aws.amazon.com/vpn/latest/s2svpn/Troubleshooting.html)

What causes a tunnel to show UP but not pass traffic:

1. Traffic selector mismatch (most common with FortiGate policy-based VPNs) — AWS supports only one encryption domain pair. Fix: set FortiGate Phase 2 selectors to 0.0.0.0/0 on both local and remote, or switch to a route-based VPN with a virtual tunnel interface.
2. Asymmetric routing — With Tunnel 2 DOWN and static routing, AWS may attempt to send return traffic via Tunnel 2 (blackhole). Fix: verify FortiGate routes traffic only via Tunnel 1's inside IP until Tunnel 2 is restored.
3. PFS mismatch — If DH groups don't match, the Phase 2 rekey (every 3600s) fails silently. Fix: confirm PFS enabled with DH group 2, 5, or 14 on FortiGate.

Ref: VPN tunnel instability and inactivity (https://repost.aws/knowledge-center/vpn-tunnel-instability-inactivity)

Forcing Phase 2 renegotiation:

From AWS: Modify VPN tunnel options → set Startup action to Start (forces AWS to initiate). Revert to Add after stabilizing. Alternatively, modifying any tunnel parameter (DPD timeout, lifetime) triggers a reset.

From FortiGate (most reliable):

diagnose vpn tunnel flush <tunnel-name>

Ref: Modify Site-to-Site VPN tunnel options (https://docs.aws.amazon.com/vpn/latest/s2svpn/modify-vpn-tunnel-options.html)

Recommended first step: Enable VPN logs and check what traffic selectors were actually negotiated. Given a FortiGate with a 0.0.0.0/0 static route on the AWS side, a proxy-ID mismatch is the most common cause of this exact symptom.

──────────────────────────────

Question 1: How to check the Phase 2 SA status from the AWS side

You can directly verify the actual establishment status of the Phase 2 SA by enabling AWS Site-to-Site VPN logs (CloudWatch Logs). After enabling logging, look for an entry similar to the following in the CloudWatch Logs log stream:

AWS tunnel Phase 2 SA is established with SPI ...

This log records the traffic selectors (encryption domains) actually negotiated by the CGW (FortiGate). By default, the AWS side (route-based VPN) proposes a traffic selector of 0.0.0.0/0 = 0.0.0.0/0. If the FortiGate negotiates Phase 2 using specific subnets (e.g., a restricted selector like 10.0.1.0/24 = 172.31.0.0/16), a situation may arise where the tunnel itself comes "UP," but actual traffic is dropped because it does not match the encryption domain as expected.

Question 2: Reasons why traffic does not flow even though the tunnel is UP

Traffic selector (encryption domain) mismatch (a very common cause with FortiGate)

Since AWS uses a route-based VPN, it permits only one SA pair each for inbound and outbound traffic. If the FortiGate proposes Phase 2 with multiple encryption domains (multiple subnet pairs) in a manner similar to policy-based VPNs, AWS may reject some of them with a "TS_UNACCEPTABLE" error, resulting in a scenario where communication to specific intended destinations fails. Please verify that the FortiGate Phase 2 selectors are correctly configured for the "entire subnet" (0.0.0.0/0 or a broad CIDR).

Question 3: How to force a Phase 2 renegotiation from AWS

Although there is no direct "renegotiate" button in the console, you can effectively force a tunnel reset and re-establishment by using the modify-vpn-tunnel-options API.