Troubleshoot IPSec Errors with Site-to-Site VPN Logs

Prerequisites

Ensure that VPN logs are enabled on at least one of the tunnels provisioned by AWS when creating a VPN connection. For detailed instructions, see Enable VPN logs. You must create a CloudWatch log group beforehand and designate it as the destination for the logs.

Common Issues and Resolutions

Wrong IKE Version

When there's an inconsistency between the IKE version sent by the customer side and the IKE version configured on the VPN tunnel, you'll see the following pattern repeated in the logs:

{
    "event_timestamp": 1769197870982,
    "timestamp": "2026-01-23 19:51:10.982Z",
    "details": "received packet: from cgw-aaaabbbbccccddddd [UDP 500] to X.X.X.X [UDP 500] (204 bytes)",
    "dpd_enabled": true,
    "nat_t_detected": false,
    "ike_phase1_state": "down",
    "ike_phase2_state": "down"
}

{
    "event_timestamp": 1769197870983,
    "timestamp": "2026-01-23 19:51:10.983Z",
    "details": "sending packet: from X.X.X.X [UDP 500] to cgw-aaaabbbbccccddddd [UDP 500] (40 bytes)",
    "dpd_enabled": true,
    "nat_t_detected": false,
    "ike_phase1_state": "down",
    "ike_phase2_state": "down"
}

The IP address displayed in your logs belongs to the VPN terminator on the AWS side (either a Transit Gateway or Virtual Private Gateway), while the customer gateway ID indicates the VPN terminator on the customer side.

Resolution: Verify the customer configuration and ensure it uses the expected IKE version that was configured when the VPN tunnel was created on the AWS side. As a best practice, IKEv2 should be the preferred choice when possible due to improvements in security and performance. You can check the IKE versions configured for your VPN tunnel using the following AWS CLI command: aws ec2 describe-vpn-connections --vpn-connection-ids <vpn-connection-id> --query 'VpnConnections[0].Options.TunnelOptions[*].IkeVersions

Non-Matching Protocols on IKE Phase 1

If there's a mismatch in any of the protocols required for the IKE Phase 1 Security Association (SA), you'll see the following error:

{
    "event_timestamp": 1769200503893,
    "timestamp": "2026-01-23 20:35:03.893Z",
    "details": "No Proposal Match Found by AWS",
    "dpd_enabled": true,
    "nat_t_detected": false,
    "ike_phase1_state": "down",
    "ike_phase2_state": "down"
}

This error occurs when the encryption algorithm, integrity algorithm, or key exchange group selected on the client doesn't match any of the options configured when the VPN tunnel was created on the AWS side. Depending on your organization's security requirements, you may have disabled deprecated and insecure protocols. In the following example, the error is caused by defining a weak Diffie-Hellman group 2 (1024-bit MODP):

{
    "event_timestamp": 1769200503893,
    "timestamp": "2026-01-23 20:35:03.893Z",
    "details": "Evaluating proposals received from CGW: Encryption: AES128 Hash: SHA1 PRF: SHA1 DH Group(s): 2",
    "dpd_enabled": true,
    "nat_t_detected": false,
    "ike_phase1_state": "down",
    "ike_phase2_state": "down"
}

{
    "event_timestamp": 1769200503893,
    "timestamp": "2026-01-23 20:35:03.893Z",
    "details": "Processing configured proposals to find a matching configuration: Encryption: AES128, AES128-GCM-16, AES256, AES256-GCM-16 Hash: SHA1, SHA2-256, SHA2-384, SHA2-512 PRF: SHA1, SHA2-256, SHA2-384, SHA2-512 DH Group(s): 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24",
    "dpd_enabled": true,
    "nat_t_detected": false,
    "ike_phase1_state": "down",
    "ike_phase2_state": "down"
}

Resolution: Ensure that all three protocols (encryption, integrity, and DH group) on the customer side match valid options configured on the VPN tunnel. To get the full list of valid options, you can run the following AWS CLI command: aws ec2 describe-vpn-connections --vpn-connection-ids <vpn-connection-id> --query 'VpnConnections[0].Options.TunnelOptions[*].{Phase1Encryption:Phase1EncryptionAlgorithms, Phase1Integrity:Phase1IntegrityAlgorithms, Phase1DHGroups:Phase1DHGroupNumbers}'

Incorrect Pre-Shared Key

If the protocols selected for IKE Phase 1 are correct but the connection still fails, you may encounter this issue:

{
    "event_timestamp": 1769202904966,
    "timestamp": "2026-01-23 21:15:04.966Z",
    "details": "AWS tunnel detected a pre-shared key mismatch with cgw-aaaabbbbccccddddd",
    "dpd_enabled": true,
    "nat_t_detected": false,
    "ike_phase1_state": "down",
    "ike_phase2_state": "down"
}

When pre-shared key authentication is selected between peers, this error indicates an incorrect configuration on the client side.

Resolution: Check for configuration errors on the client side when the pre-shared key was provisioned, such as typos or an incorrect peer IP address.

Non-Matching Protocols on IKE Phase 2

If the Phase 1 SA is already established but you see the same "No Proposal Match" error:

{
    "event_timestamp": 1769205784907,
    "timestamp": "2026-01-23 22:03:04.907Z",
    "details": "No Proposal Match Found by AWS",
    "dpd_enabled": true,
    "nat_t_detected": true,
    "ike_phase1_state": "established",
    "ike_phase2_state": "down"
}

{
    "event_timestamp": 1769205784907,
    "timestamp": "2026-01-23 22:03:04.907Z",
    "details": "AWS tunnel Phase 2 was unable to establish while keeping Phase 1",
    "dpd_enabled": true,
    "nat_t_detected": true,
    "ike_phase1_state": "established",
    "ike_phase2_state": "down"
}

This indicates that Phase 2 has failed due to unmatched algorithms. You can distinguish Phase 1 errors from Phase 2 errors by checking whether the log shows ike_phase1_state as established.

Resolution: Ensure that the encryption algorithm, integrity algorithm, and DH group (if Perfect Forward Secrecy is enabled) configured on the client side match valid options in the VPN tunnel configuration. To check valid option of the AWS side, run the following AWS CLI command: To get the full list of valid options, you can run the following AWS CLI command: aws ec2 describe-vpn-connections --vpn-connection-ids <vpn-connection-id> --query 'VpnConnections[0].Options.TunnelOptions[*].{Phase2Encryption:Phase2EncryptionAlgorithms, Phase2Integrity:Phase2IntegrityAlgorithms, Phase2DHGroups:Phase2DHGroupNumbers}'

Missing Firewall Rule on Client Side

Most errors discussed so far are configuration-related, but you can also detect connectivity issues. In this scenario, the customer side initiates the connection by sending packets to the AWS side on port 500 (IKE protocol). As part of the flow, AWS sends packets back to the customer's VPN terminator on the same port. If the firewall rule on the client side isn't open, you'll see the following pattern in the logs:

{
    "event_timestamp": 1769209037833,
    "timestamp": "2026-01-23 22:57:17.833Z",
    "details": "sending packet: from X.X.X.X [UDP 500] to cgw-aaaabbbbccccddddd [UDP 500] (440 bytes)",
    "dpd_enabled": true,
    "nat_t_detected": true,
    "ike_phase1_state": "negotiating",
    "ike_phase2_state": "down"
}

The ike_phase1_state field will remain stuck in the negotiating state until packets can reach the client side.

Resolution: Ensure that the firewall rule on the client side allows communication from the AWS VPN public IP to UDP port 500.

References

• Site-to-Site VPN logs messages
• Site-to-Site VPN firewall rules