This topic provides answers to some frequently asked questions about IPsec-VPN connection failures and negotiation failures.
FAQ
IPsec-VPN negotiation issues
What can I do if the system prompts that Phase 1 negotiations failed?
What can I do if the system prompts that Phase 2 negotiations failed?
What do I do if the system prompts that Phase 2 negotiations succeeded but health checks failed?
IPsec-VPN connectivity issues
What can I do if the system prompts that Phase 1 negotiations failed?
You can troubleshoot the issue based on the error code and log data of the IPsec-VPN connection displayed in the VPN Gateway console. For more information, see Troubleshoot IPsec-VPN connection issues.
The following table describes some common causes of Phase 1 negotiation failures on the peer gateway device of an IPsec-VPN connection.
Cause | Solution |
The peer gateway is not working as expected. | Check the peer gateway device. For more information, consult the supplier of the peer gateway device. |
IPsec-VPN configurations are not added to the peer gateway device. | Add IPsec-VPN configurations to the peer gateway device and make sure that the peer gateway device and the IPsec-VPN connection use the same configurations. For more information, see Configure local gateways. |
Access control policies on the peer gateway device do not allow UDP ports 500 and 4500. | Check the access control policies on the peer gateway device and make sure that the following conditions are met:
|
Due to the limits imposed by the supplier of the peer gateway device, IPsec negotiations can be triggered only when inbound traffic is detected. | Check whether the limits apply to the peer gateway device. If the limits apply to the peer gateway device, consult the supplier about how to trigger IPsec negotiations. |
What can I do if the system prompts that Phase 2 negotiations failed?
You can troubleshoot the issue based on the error code and log data of the IPsec-VPN connection displayed in the VPN Gateway console. For more information, see Troubleshoot IPsec-VPN connection issues.
What can I do if the system prompted that Phase 2 negotiations succeeded but now keeps prompting that Phase 2 negotiations failed?
The following table describes the possible causes and the solutions.
Category | Cause | Solution |
Gateway device exceptions | The Alibaba Cloud VPN gateway has overdue payments. | Top up your account or add a new payment method. For more information, see Alibaba Cloud payment methods. |
The peer gateway device has exceptions. | Check the peer gateway device. For more information, consult the supplier of the peer gateway device. | |
The access control policies on the peer gateway device are changed. | Check the access control policies on the peer gateway device. Make sure that the policies allow data transfer between the virtual private cloud (VPC) and the data center. | |
IPsec-VPN configuration changes | The IPsec-VPN configurations of the peer gateway device are deleted. | Add IPsec-VPN configurations to the peer gateway device and make sure that the peer gateway device and the IPsec-VPN connection use the same configurations. For more information, see Configure local gateways. |
The configurations of the peer gateway device are modified and are different from the configurations of the IPsec-VPN connection. | Make sure that the peer gateway device and the IPsec-VPN connection use the same configurations. | |
A parameter of the IPsec-VPN configuration on the peer gateway device is set to multiple values. For example, the Encryption Algorithm parameter of IKE Configurations is set to aes and aes192. | Specify only one value for each parameter when you configure an IPsec-VPN connection on Alibaba Cloud Check the IPsec-VPN configurations of the peer gateway device. Make sure that each parameter is set to only one value. In addition, make sure that the peer gateway device and the IPsec-VPN connection use the same value for each parameter. | |
The configurations of the IPsec-VPN connection are modified and are different from the configurations of the peer gateway device. | Make sure that the peer gateway device and the IPsec-VPN connection use the same configurations. For more information, see the "Modify an IPsec-VPN connection" section of the Create and manage IPsec-VPN connections in single-tunnel mode. | |
An IPv4 gateway and a network ACL are newly configured for the VPC associated with the IPsec-VPN connection. | Check the IPv4 gateway and the network ACL configured for the VPC. Make sure that the IPv4 gateway and network ACL allow data transfer between the VPC and the data center. For more information, see IPv4 gateway overview and Overview of network ACLs. | |
IP address change of the peer gateway device | The IP address used by the peer gateway device to create an IPsec-VPN connection is changed. As a result, the IP address of the customer gateway on Alibaba Cloud is different from the one used by the peer gateway device. | Make sure that the IP address of the customer gateway on Alibaba Cloud is the same as the one used by the peer gateway device to create an IPsec-VPN connection. |
The peer gateway device uses multiple IP addresses. As a result, the IP address of the customer gateway on Alibaba Cloud is different from the one used by the peer gateway device to create an IPsec-VPN connection. | Make sure that the IP address of the customer gateway on Alibaba Cloud is the same as the one used by the peer gateway device to create an IPsec-VPN connection. | |
The peer gateway device uses dynamic IP addresses. As a result, the IP address of the customer gateway on Alibaba Cloud is different from the one used by the peer gateway device to create an IPsec-VPN connection. | Configure a static IP address for the peer gateway device. Make sure that the IP address of the customer gateway on Alibaba Cloud is the same as the one used by the peer gateway device to create an IPsec-VPN connection. |
What can I do if the system prompts that Phase 2 negotiations succeeded but intermittently failed?
The following table describes the possible causes and the solutions.
Category | Cause | Solution |
IPsec-VPN configuration changes | The IPsec-VPN connection and the peer gateway device use different values for the DH Group paramete, or PFS for some gateway devices of IPsec-VPN Configurations. | Check the DH Group parameter or PFS of IPsec-VPN Configurations on the IPsec-VPN connection and the peer gateway device. Make sure that the same value is used for the DH Group parameter or PFS. For more information about how to modify the configuration of an IPsec-VPN connection, see the "Modify an IPsec-VPN connection" section of the Create and manage IPsec-VPN connections in single-tunnel mode. |
A parameter of the IPsec-VPN configuration on the peer gateway device is set to multiple values. For example, the Encryption Algorithm parameter of IKE Configurations is set to aes and aes192. | Specify only one value for each parameter when you configure an IPsec-VPN connection on Alibaba Cloud Check the IPsec-VPN configurations of the peer gateway device. Make sure that each parameter is set to only one value. In addition, make sure that the peer gateway device and the IPsec-VPN connection use the same value for each parameter. | |
A traffic-based security association (SA) lifetime is configured for the peer gateway device. | The IPsec-VPN connection on Alibaba Cloud supports only a time-based SA lifetime and does not support a traffic-based SA lifetime. We recommend that you leave the traffic-based SA lifetime empty on the peer gateway device or set the lifetime to 0 bytes. | |
Poor network quality | Dead peer detection (DPD) packets, health check packets, or IPsec packets time out and are dropped due to the poor network quality between the IPsec-VPN connection and the peer gateway device. This interrupts the IPsec-VPN connection. | Check the network connectivity if the IPsec-VPN connection is interrupted. |
Limits on the IPsec-VPN connection | Due to the limits imposed by the supplier of the peer gateway device, IPsec negotiations can be triggered only when inbound traffic is detected. | Check whether the limits apply to the peer gateway device. If the limits apply to the peer gateway device, consult the supplier about how to trigger IPsec negotiations. |
When establishing a dual-tunnel IPsec-VPN connection, the same protected data flow is used for the two tunnels. However, only one tunnel can successfully complete negotiation if the peer gateway has relevant limits, such as Cisco ASA firewall gateways. | Contact the manufacturer to check whether such limits exist. If such limits exist, modify the IPsec-VPN configurations of the peer gateway. For more information, see Configuration examples. |
What can I do if the system prompts that Phase 2 negotiations succeeded but the BGP negotiation is in the Abnormal state?
The following table describes the possible causes and the solutions.
Category | Cause | Solution |
Incorrect BGP configurations | The BGP IP address configured on the peer gateway device is invalid. | Check the BGP configurations of the IPsec-VPN connection and the peer gateway device. Make sure that the BGP IP address of the IPsec-VPN connection and the BGP IP address of the peer gateway device fall within the same CIDR block and do not conflict with each other. The CIDR block to which the BGP IP address belongs must fall within the CIDR block 169.254.0.0/16 with a subnet mask length of 30. |
IPsec-VPN connection issues | Due to the connectivity exceptions of the IPsec-VPN connection, the local gateway cannot receive BGP packets from the peer gateway device. | Check the connectivity of the IPsec-VPN connection and check whether the local gateway receives BGP packets from the peer gateway device. You can view the traffic monitoring data of the IPsec-VPN connection. If no traffic is detected, it indicates that the local gateway does not receive BGP packets from the peer gateway device. |
IPsec negotiations are interrupted. | View the logs of the IPsec-VPN connection to check whether the Phase 2 negotiations succeed. If the IPsec negotiations are in an unstable state, check the logs to troubleshoot. For more information, see Troubleshoot IPsec-VPN connection issues. |
What can I do if the system prompts that Phase 2 negotiations succeeded but health checks failed?
The following table describes the possible causes and the solutions.
Category | Cause | Solution |
Issues related to destination IP addresses of health checks | The destination IP address of the health check cannot be accessed. | Run the If the destination IP address cannot access the source IP address, check the configuration of the destination IP address. |
The host associated with the destination IP address has exceptions and cannot respond to ICMP packets from the IPsec-VPN connection. | Check whether the host associated with the destination IP address is working as expected. For more information, consult the supplier of the gateway device. | |
The route configurations and security policies for the destination IP address are changed. For example, the security policies do not allow the source IP address, destination IP address, or ICMP packets. | Make sure that the route configurations and the security policies for the destination IP address meet the following requirements:
| |
The destination IP address does not respond to health check probes through the same path through which the destination IP address receives probes. | Run the | |
IPsec-VPN connection issues | IPsec negotiations are interrupted. | View the logs of the IPsec-VPN connection to check whether the Phase 2 negotiations succeed. If the IPsec negotiations are in an unstable state, check the logs to troubleshoot. For more information, see Troubleshoot IPsec-VPN connection issues. Note If the IPsec-VPN connection fails health checks, the system resets the IPsec tunnel. In scenarios in which active/standby connections are not used, we recommend that you use the DPD feature instead of the health check feature to check connectivity. For more information about the use scenarios of active/standby IPsec-VPN connections, see Use two public IP addresses to create active/standby IPsec-VPN connections and Use two customer gateways for high availability. |
What can I do if the state of an IPsec-VPN connection is "Phase 2 negotiations succeeded", but the Elastic Compute Service (ECS) instances in the virtual private cloud (VPC) cannot access the servers in the on-premises data center?
Cause
The VPC route configurations, security group rules, route configurations of the data center, or access control policies do not allow ECS instances in the VPC to access servers in the data center.
Solution
Troubleshoot the issue based on the following instructions:
VPC
Check the route configurations in the VPC route table. Make sure that a route is configured in the VPC route table to allow the ECS instances to access servers in the on-premises data center.
Check the rules of the security group to which the VPC belongs. Make sure that the rules allow servers in the on-premises data center to access the ECS instances.
Data center
Check the route configurations of the on-premises data center. Make sure that a route is configured to allow servers in the on-premises data center to respond to requests from the ECS instances.
Check the access control policy of the on-premises data center. Make sure that the access control policy allows the ECS instances to access servers in the on-premises data center.
If your on-premises network routes public IP addresses to an internal destination, you must specify the public CIDR block of the data center as the user CIDR block of the VPC. This way, the VPC can access the public CIDR block. For more information, see the "What is a user CIDR block?" in the FAQ topic and the "How do I configure a user CIDR block?" section of the FAQ topic.
What can I do if the state of an IPsec-VPN connection is "Phase 2 negotiations succeeded", but servers in the on-premises data center cannot access the ECS instances in the VPC?
Cause
The VPC route configurations, security group rules, route configurations of the data center, or access control policies do not allow servers in the data center to access ECS instances in the VPC.
Solution
Troubleshoot the issue based on the following instructions:
VPC
Check the route configurations in the VPC route table. Make sure that a route is configured in the VPC route table to allow the ECS instances to respond to requests from servers in the on-premises data center.
Troubleshoot the rules of the security group to which the VPC belongs. Make sure that the rules allow servers in the on-premises data center to access the ECS instances.
Data center
Check the route configurations of the on-premises data center. Make sure that a route is configured for the on-premises data center to allow data to be transmitted to the ECS instances through the IPsec-VPN connection.
Check the access control policy of the on-premises data center. Make sure that the access control policy allows servers in the on-premises data center to access the ECS instances.
What can I do if the state of the IPsec-VPN connection is "Phase 2 negotiations succeeded", but communication is successful only in some of the CIDR blocks?
Cause
In scenarios in which a data center is connected to a VPC by using IPsec-VPN, if the peer gateway device is provided by Cisco, H3C, or Huawei, the routing mode of the IPsec-VPN connection is set to Protected Data Flow, and multiple CIDR blocks are configured, only one CIDR block can be used for communication.
This is because an Alibaba Cloud VPN gateway is incompatible with the IPsec protocol used by the peer gateway device provided by Cisco, H3C, or Huawei. If an IPsec-VPN connection is established to connect multiple CIDR blocks, the VPN gateway uses a Security Association (SA) to negotiate with the customer gateway device. However, if the customer gateway device is configured with multiple CIDR blocks, the customer gateway device uses multiple SAs to negotiate with the VPN gateway.
Solution
For more information, see Configuration suggestions for multiple CIDR blocks.
What can I do if the system prompts that Phase 2 negotiations succeeded and I can ping the service, but the service or some ports are inaccessible?
Cause
The VPC security group rules or access control policies of the data center do not allow the IP address, protocol type, and port numbers.
Solution
Troubleshoot the issue based on the following instructions:
Check the VPC security group rules. Make sure that the security group rules allow the protocol, port numbers, and the IP address that is used for data transfer between the VPC and the data center.
Check the access control policies for the data center. Make sure that the access control policies allow the protocol, port numbers, and the IP address that is used for data transfer between the VPC and the data center.
If service policies and domain name resolution are also configured for the data center, we recommend that you also check them. Make sure that the protocol, port numbers, and the IP address that is used for data transfer between the VPC and the data center are allowed.
What can I do if the system prompts that Phase 2 negotiations succeeded, but private connections have packet loss and sometimes fail?
The following table describes the possible causes and the solutions.
Category | Cause | Solution |
VPN gateway specification issues | A sudden traffic surge occurs during data transfer, which exceeds the maximum bandwidth of the VPN gateway. You can view the traffic monitoring information of the VPN gateway in the VPN Gateway console to check whether a sudden traffic surge occurs. | You can upgrade the VPN gateway. For more information, see Upgrade or downgrade a VPN gateway. |
IPsec-VPN connection issues | IPsec negotiations are interrupted. | View the logs of the IPsec-VPN connection to check whether the Phase 2 negotiations succeed. If IPsec-VPN negotiations are in an unstable state and the IPsec tunnel is frequently reset, which results in network interruptions, check the logs of the IPsec-VPN connection to troubleshoot. For more information, see Troubleshoot IPsec-VPN connection issues. |
Issues related to maximum transmission unit (MTU) | The MTU configured on the data center exceeds 1,300 bytes. | If your VPN gateway was created before April 1, 2021 and the user MTU configured in the data center is larger than 1,300 bytes, IPsec-VPN connections may fail. In this case, we recommend that you update your VPN gateway to the latest version. For more information about how to upgrade a VPN gateway, see Upgrade a VPN gateway. |
During data transmission, the packet size exceeds the MTU, which causes packet fragmentation. | VPN Gateway can transmit packets that are fragmented, but cannot reassemble the fragments of packets. We recommend that you set the MTU to 1,399 bytes. For more information, see Set MTU values. |
What do I do if the system prompts that Phase 2 negotiations succeeded and private connections can be established, but the network latency is high?
The following table describes the possible causes and the solutions.
Category | Cause | Solution |
VPN gateway specification issues | A sudden traffic surge occurs during data transfer, which exceeds the maximum bandwidth of the VPN gateway. You can view the traffic monitoring information of the VPN gateway in the VPN Gateway console to check whether a sudden traffic surge occurs. | You can upgrade the VPN gateway. For more information, see Upgrade or downgrade a VPN gateway. |
Poor network quality | The network quality between the IPsec-VPN connection and the peer gateway device is poor, which causes high network latency and packet loss. | Run the If the network latency is high, you can perform probes in segments to pinpoint the cause. If the network quality of the public connection is poor, we recommend that you use Cloud Enterprise Network (CEN) and other services. |
Why do IPsec-VPN connections succeed even if the protected data flows of on-premises and cloud networks are different?
Cause
As shown in the following figure, if the protected data flows of the on-premises gateway device and the IPsec-VPN connection have an inclusion relation, and both the on-premises gateway device and the IPsec-VPN connection use IKEv2, Alibaba Cloud VPN Gateway assumes that their protected data flows are matched during Ipsec-VPN negotiations. If the on-premises gateway device also supports an inclusion relation, the IPsec-VPN negotiation succeeds despite the different protected data flows.
For example, Gateway Device 1 supports an inclusion relation. When a negotiation is performed between Gateway Device 1 and IPsec-VPN Connection 1, and between Gateway Device 1 and IPsec-VPN Connection 2, the local CIDR block 10.55.0.0/16 of Gateway Device 1 includes the peer CIDR block 10.55.193.0/24 of IPsec-VPN Connection 1 and the peer CIDR block 10.55.0.0/16 of IPsec-VPN Connection 2. In addition, the peer CIDR block 10.66.88.0/22 of Gateway Device 1 includes the local CIDR block 10.66.90.0/24 of IPsec-VPN Connection 1 and the local CIDR block 10.66.89.0/24 of IPsec-VPN Connection 2. In this case, Gateway Device 1 and Alibaba Cloud VPN Gateway assume that the protected data flows are matched, and the negotiations succeed.
If the on-premises gateway device does not support an inclusion relation, which means that the gateway device and Alibaba Cloud VPN Gateway do not assume that the protected data flows are matched, the IPsec-VPN negotiations fail. You need to check with the manufacturer of the local gateway device to check whether the local gateway device supports an inclusion relation.
If both the on-premises gateway device and the IPsec-VPN connection use IKEv1, the protected data flows on both sides must be the same and cannot have an inclusion relation. Otherwise, the IPsec-VPN connection fails.
Possible problems
As shown in the preceding figure, if multiple IPsec-VPN connections exist in a VPN gateway, and the CIDR blocks of the protected data flows of IPsec-VPN connections have an inclusion relation, traffic may not be forwarded in the expected path.
For an IPsec-VPN connection that is configured with protected data flows, after the IPsec-VPN connection is created, the system automatically adds related routes to the policy-based route table of the VPN gateway. Each route has the same policy priority. In the preceding scenario, the system adds the following routes to the policy-based route table of the VPN gateway.
Name | Source CIDR block | Destination CIDR block | Next hop | Weight | Priority |
Route 1 | 10.66.90.0/24 | 10.55.193.0/24 | IPsec-VPN Connection 1 | 100 | 10 |
Route 2 | 10.66.89.0/24 | 10.55.0.0/16 | IPsec-VPN Connection 2 | 100 | 10 |
Route 3 | 10.66.90.0/24 | 10.55.178.0/24 | IPsec-VPN Connection 3 | 100 | 10 |
Route 4 | 10.66.88.0/24 | 10.55.0.0/16 | IPsec-VPN Connection 4 | 100 | 10 |
Based on the match rules for policy-based routes, if multiple policy-based routes are assigned with the same priority, traffic is matched against the policy-based routes based on their sequence numbers. The VPN gateway uses the first matched policy-based route to forward traffic. For more information about the match rules, see the "Match rules for policy-based routes (excluding route priorities)" section of the Manage policy-based routes topic. Each route is assigned with a sequence number when the route is applied to the system. In most cases, routes that are configured earlier are applied to the system first and therefore have smaller sequence numbers than routes that are configured later. However, there is no strict ordering on which routes are applied first, resulting in some cases where routes that are configured later are applied to the system first and have smaller sequence numbers than routes that are configured earlier.
In the preceding scenario, the on-premises data center may send a request packet to the VPC over IPsec-VPN Connection 1, and the VPC may send a reply packet to the on-premises data center over IPsec-VPN Connection 4. In this case, Route 4 may be sent to the system. As a result, the priority of Route 4 is higher than that of Route 1.
Solution
Add CIDR blocks that do not have an inclusion relation to the on-premises data center and the IPsec-VPN connection. We recommend that you configure the same CIDR block for two sides to enhance the stability of IPsec-VPN connections.
Add accurate protected data flows when you create IPsec-VPN connections. Make sure that multiple IPsec-VPN connections under a VPN gateway do not overlap.
Configure different policy priorities and weight values for policy-based routes to ensure that a protected data flow can be matched to only one policy-based route.
If your VPN gateway does not support policy priority configuration, you can upgrade the VPN gateway. An upgraded VPN gateway supports policy priority configuration for policy-based routes. For more information, see Upgrade a VPN gateway.