AWS Guide: Fixing Site-to-Site VPN Tunnel Up but No Traffic Flow

Select Language:

If you’re noticing that your VPN tunnel shows as up but isn’t passing traffic—such as traffic sent but none received, with destinations unreachable—this usually comes down to a mismatch in the Phase 2 traffic selectors, also known as proxy IDs.

Here’s how you can troubleshoot this issue:

Start by enabling VPN logging to Amazon CloudWatch. You can do this in the VPC console under VPN Connections by selecting your connection, choosing ‘Modify VPN tunnel logging,’ and turning on logging. Once that’s set, check the logs for Phase 2 security association (SA) events. Look for log entries that include “/Phase 2 SA/”. These entries will tell you what traffic selectors (proxy IDs) are being used.

In the logs, focus on the ‘traffic selectors’ field. The ideal setup expects 0.0.0.0/0 on both sides, which means the VPN is accepting all traffic from and to any IP addresses. However, if your gateway shows narrower selectors like 192.168.1.0/24 ↔ 10.0.0.0/16, that’s likely the problem. Packets outside these ranges get ignored by the virtual private gateway (VGW), causing traffic issues.

For more detailed steps, refer to AWS’s troubleshooting guide on IPsec and Phase 2 issues.

If your tunnel appears to be Up but isn’t passing traffic, a few common causes could be:

Traffic Selector Mismatch: Especially common with policy-based VPNs on FortiGate devices, where AWS supports only one pair of encryption domains. The fix is to set FortiGate’s Phase 2 selectors to 0.0.0.0/0 on both ends or switch to a route-based VPN with a virtual tunnel interface.
Asymmetric Routing: If Tunnel 2 is down and you’re using static routing, AWS may send reply traffic through Tunnel 2, which isn’t working. Ensure FortiGate routes all traffic via Tunnel 1’s inside IP until Tunnel 2 is active again.
PFS Mismatch: When Diffie-Hellman groups don’t match, the rekey process in Phase 2 silently fails. Confirm that PFS is enabled and both sides use groups 2, 5, or 14.

To force re-negotiation of Phase 2, you can:

In AWS, modify your VPN tunnel settings to set ‘Startup action’ to ‘Start’—this makes AWS initiate a new handshake. You can revert it back to ‘Add’ once the tunnel stabilizes.
On FortiGate, use the command diagnose vpn tunnel flush <tunnel-name> to reset the tunnel directly.

Before making changes, it’s best to enable VPN logs and review the negotiated traffic selectors. Often, a mismatch in proxy IDs is the root cause if the AWS side is set to 0.0.0.0/0 but your on-premise device uses narrower selectors.

By following these steps, you can identify and resolve common VPN issues quickly and effectively.