Docs

VPN Connet

Troubleshooting

IPsec-VPN connection troubleshooting

VPN Connect enable communication between a cloud VPC and an on-premises data center, as well as between cloud VPCs. This article uses the connection between a cloud VPC and an on-premises data center as an example to illustrate troubleshooting IPsec-VPN connections.

1. IPsec-VPN connection status shows "The first stage of negotiation was unsuccessful"

Possible reasons

IKE negotiation is in progress. Please be patient.

IKE negotiation failed. Refer to the solutions below for troubleshooting.

Solutions

IKE negotiation failure generally results from inconsistent configuration between the on-premises VPN gateway and the IPsec-VPN connection configuration on VolcanoEngine. Follow these steps to troubleshoot.

On the "VPN Connect console > VPN Connection" page, check the following configuration parameters one by one.

Confirm that the on-premises data center's VPN gateway configuration matches the IPsec-VPN connection settings. If any parameters differ, update them to be consistent.

Please confirm the key exchange protocol version is "ikev2" under the "aggressive" negotiation mode. If configured as "aggressive" and "ikev1", the on-premises side will deny the connection request after the peer initiates negotiation for security reasons. If the peer also denies the on-premises side's negotiation initiation, the first stage negotiation will fail.

On the "VPN Connect console > Customer Gateway" page, check whether the IP address associated with the IPsec-VPN connection's customer gateway is the static public IP address of the on-premises data center gateway.

If the configuration is incorrect, recreate the customer gateway with the correct IP address and then recreate the IPsec-VPN connection associated with the newly created customer gateway.

Check the on-premises VPN gateway status on the on-premises data center to ensure it is normal.

If the on-premises VPN gateway status is abnormal and unresponsive, investigate or consult the device vendor to restore the VPN gateway functionality.

II. IPsec-VPN connection status shows "The second stage of negotiations was unsuccessful"

Possible reasons

IPsec negotiation has not been triggered.

IPsec negotiation is in progress; please be patient.

IPsec negotiation failed. Please refer to the solution for troubleshooting.

Solution

IPsec negotiation failure is often due to inconsistent on-premises VPN gateway configuration and the "IPsec-VPN connection" settings in the VolcanoEngine VPN connection. You may use the following methods for troubleshooting.

After creating the IPsec-VPN connection, the VPN tunnel does not open immediately. The second-stage negotiation process passively activates and establishes the communication tunnel only after traffic passes through or the ping command is executed.

On the "VPN Connect console > VPN Connection" page, click "Modify" of the target IPsec-VPN connection. On the modification page, check the following configurations:

Check the connection information. In "Protected Data Flows" mode, ensure the private network segments on both ends of the IPsec-VPN connection gateways are correct and consistent.

If the private network segments of the two gateways are incorrect or inconsistent, modify them to the correct and consistent segments.

Check the IPsec Config to ensure the on-premises data center's VPN gateway and the IPsec negotiation phase authentication algorithm, encryption algorithm, and DH algorithm configuration in the IPsec-VPN connection are consistent.

If there are inconsistent parameter settings, please unify them.

In the "Protected Data Flows" mode, you may create multiple IPsec-VPN connections using both large and small CIDR blocks. Check the IPsec-VPN connection configuration to ensure that the IKE configuration of multiple IPsec-VPN connections using different CIDR blocks is exactly the same. This is because when one IPsec-VPN connection is established, and other IPsec-VPN connections have overlapping route CIDR blocks with the first one, multiple IPsec-VPN connections will share the same SA. Therefore, multiple IPsec-VPN connections must maintain identical IKE configurations.

For example, a on-premises data center (private CIDR block: 10.0.0.0/8) connects to two subnets in the cloud VPC (private CIDR blocks: 192.168.0.0/24 and 192.168.0.0/26) via IPsec-VPN connection 1 and IPsec-VPN connection 2 respectively. The IKE configurations of IPsec-VPN connection 1 and IPsec-VPN connection 2 must be exactly the same.

3. IPsec-VPN connection status shows "The second stage of negotiation was successful", but access still fails

Possible reasons

Scenario 1: The on-premises data center cannot access Elastic Compute Service (ECS) in the VPC

The on-premises route does not direct traffic to the VPC through the IPsec VPN tunnel, or the on-premises ACL configuration does not allow traffic to the VPC to enter the IPsec VPN tunnel.

The security group of the target ECS has no rule allowing access from the on-premises data center private CIDR block.

Scenario 2: ECSs in the VPC cannot access the on-premises data center

No related route entry found in the VPC route table.

Security settings of the on-premises data center do not allow VPC access traffic.

Scenario 3: Neither on-premises data center nor ECSs in the VPC can access

The public IP of the on-premises data center's VPN gateway is a private IP implemented via NAT, but NAT traversal is not enabled when creating the IPsec-VPN connection.

Solution

Scenario 1: The on-premises data center cannot access ECSs inside the VPC

Check the on-premises data center route entries and ACL settings to confirm that the traffic from the on-premises data center to the VPC is allowed into the IPsec VPN tunnel. If the relevant configurations do not allow traffic into the IPsec VPN tunnel, configure to allow the traffic manually.

Check the security group of the target ECS instance. Confirm the security group rules allow access from the on-premises data center private CIDR block. If there is no related security group rule, manually add the appropriate security group rule. For procedure, see Adding a security group rule.

Scenario two: ECSs in the VPC cannot access the on-premises data center

Check the route entries in the VPC route table and confirm there is a route entry with the next hop set to the "VPN gateway" used by the IPsec-VPN connection, which is unreachable.

The routing information in the VPC route table enables network communication between the on-premises VPC and the VPN gateway. Generally, after the VPN gateway route is configured successfully, the system automatically synchronizes this route to the system route table of the VPC associated with the VPN gateway, routing traffic in the VPC to the VPN gateway. If the VPC uses a custom route table, you must manually add the VPN gateway route information to the VPC's custom route table. For specific operations, see Add route.

Check the firewall/iptables settings on the peer VPN gateway and ensure that access from the VPC's private network segment is allowed.

Ensure that the VPN gateway's routing configuration and the setup within the cloud VPC are interconnected. The on-premises and peer network segments in the protected data flows mode of the IPsec-VPN connection must match the source and destination segments to be accessed.

Scenario three: Neither the on-premises data center nor ECSs within the VPC can access

If the IP address configured when creating a customer gateway is obtained via NAT, you must enable and configure NAT traversal on the on-premises VPN gateway device. For details, see Modifying configuration for IPsec-VPN connection. Under "Advanced configuration", turn on the NAT traversal switch to enable this feature. Also, NAT traversal must be enabled on the VPN gateway device at the on-premises data center.

4. IPsec-VPN connection status is "The second stage of negotiation was successful", but some communications are abnormal in multi-CIDR scenarios

Possible reasons

The IKE key exchange protocol version is set incorrectly; the recommended version is ikev2.

In multi-CIDR scenarios, the mainstream mode uses a single connection and single SA. Some other modes may have multiple SAs under a single connection, causing some communications to be abnormal.

Solution

On the "VPN Connect console > VPN Connection" page, click the target IPsec-VPN connection name to enter the "Overview" page. Check whether the IKE key exchange protocol version is "ikev2".

If not, change it to "ikev2". For detailed steps, see Modifying configuration for IPsec-VPN connection. When the routing mode is "Protected Data Flows", the IKE key exchange protocol version must be "ikev2".

If your IKE protocol version is correct but some communications still fail, check the SA status of the on-premises data center-side VPN gateway.

Only one SA: Indicates normal status; check other configurations for correctness.

Multiple SAs: Indicates the on-premises data center-side VPN gateway uses a non-standard ikev2 protocol, connecting multiple subnets through multiple IPsec-VPN connections.

For example, if the on-premises data center originally connected two subnets (192.168.0.0/24, 10.0.0.0/8) to the cloud VPC (private subnet: 172.16.0.0/24) using one IPsec-VPN connection, now it needs two IPsec-VPN connections: IPsec-VPN connection 1 connects the on-premises data center subnet 192.168.0.0/24 with the cloud VPC, and IPsec-VPN connection 2 connects the on-premises data center subnet 10.0.0.0/8 with the cloud VPC. Ensure that the IKE configuration of IPsec-VPN connections 1 and 2 is identical.

5. IPsec-VPN connection succeeds, and VPN communication is normal, but packet loss occasionally occurs

Possible reasons

The IKE configuration or IPsec configuration uses authentication algorithms, encryption algorithms, or DH algorithms with lower security.

The actual traffic transmission exceeds the bandwidth limit specification of the on-premises or peer VPN gateway.

Solution

Modify the IPsec-VPN connection configuration to use higher security authentication algorithms, encryption algorithms, and DH algorithms. For specific changes, refer to Modifying configuration for IPsec-VPN connection.

Parameter	Description
Authentication algorithm	sha1 and md5 are relatively less secure. Select with caution. We recommend using more secure sha256, sha384, sha512.
Encryption algorithm	des and 3des are relatively less secure. Select with caution. We recommend using more secure aes, aes192, aes256.
DH algorithm	group1, group2, and group5 are relatively less secure. Select with caution. We recommend using the more secure group14.

Last updated: 2026.07.15 18:21:42