IPsec-VPN connections (VPN Gateway) - VPN Gateway - Alibaba Cloud Documentation Center

After you create a VPN Gateway, you must configure an IPsec-VPN connection in both Alibaba Cloud and your on-premises data center. This connects your data center to your VPC.

How it works

IPsec-VPN connections in Alibaba Cloud use a dual-tunnel mode by default. This mode includes an active tunnel and a standby tunnel. If the active tunnel is disrupted by network jitter or device failure, traffic automatically switches to the standby tunnel. This ensures business continuity and high network availability.

Tunnel roles: The system uses two different public IP addresses of the VPN Gateway to establish two tunnels.
- Tunnel 1 (using IP address 1) is the active tunnel by default and carries all service traffic.
- Tunnel 2 (using IP address 2) is the standby tunnel and remains on standby.
The active/standby roles of the tunnels are fixed and cannot be changed.
Health checks and failover: The system automatically performs health checks on the active tunnel. If the active tunnel fails, the VPN Gateway automatically switches traffic to the standby tunnel. After the active tunnel recovers, traffic automatically switches back.
Zone-disaster recovery: The two tunnels of an IPsec-VPN connection are deployed in different zones by default. If one zone fails, the tunnel in the other zone remains available. This provides cross-zone disaster recovery. In regions that support only one zone, both tunnels are deployed in the same zone. These deployments do not support zone-level disaster recovery but still provide link redundancy.

Create an IPsec-VPN connection

1. Configure the IPsec-VPN connection

Before you begin, make sure that you have created a VPN Gateway instance and a customer gateway instance.

Console

Go to the IPsec-VPN Connections page in the VPC console, click Bind VPN Gateway, and complete the following configurations:

IPsec Settings

Select the Region and the VPN gateway instance that you want to attach.
Routing Mode:
- Destination Routing Mode (Default): Forwards traffic based on the destination IP address. This mode is easy to configure and suitable for scenarios where routes are learned dynamically through BGP or configured statically on the VPN Gateway.
- Protected Data Flows: Forwards traffic based on source and destination IP addresses. This pattern is suitable for complex network scenarios where you want to enable communication only between specific network segments. After you select this pattern, you must configure the Local Network (the VPC CIDR block that requires communication) and the Remote Network (the on-premises data center CIDR block that requires communication).
  After you configure an IPsec-VPN connection, the system automatically generates a policy-based route. In this route, the Source CIDR Block is the connection's Local Network, the Destination CIDR Block is the connection's Remote Network, and the next hop is the IPsec-VPN connection. The route can be published to a VPC route table but is not published by default.
  - When you configure interesting traffic on your on-premises gateway device, make sure that the CIDR blocks are consistent with those on the Alibaba Cloud side, but swapped.
  - You can add multiple network segments by clicking the Add icon. If you configure multiple network segments, the IKE protocol version must be set to IKEv2.
Effective Immediately: Select Yes to enable the connection quickly or avoid traffic delays. Select No if you want to save resources and traffic is infrequent.

Tunnel Settings

Important

When you create a dual-tunnel IPsec-VPN connection, you must configure both tunnels. If you configure or use only one tunnel, you cannot benefit from the active/standby link redundancy and zone-disaster recovery capabilities of the IPsec-VPN connection.

Enable BGP: Specifies whether to use BGP dynamic routing.
- Disabled (Default): Uses static routing. This is suitable for simple network topologies.
- Enabled: Suitable for complex network topologies that require automatic route distribution and learning. Prerequisite: The associated customer gateway must have an ASN configured.
Local ASN: The autonomous system number (ASN) for the Alibaba Cloud side when BGP is enabled. The two tunnels use the same ASN. The default value is 45104. The value range is 1 to 4294967295. We recommend that you use a private ASN when you configure the ASN for the on-premises peer device.

Tunnel 1 (Active) and Tunnel 2 (Standby) configurations:

Customer Gateway: Select the customer gateway instance that represents your on-premises gateway device. Both tunnels can be associated with the same customer gateway.
Pre-Shared Key: The key used for identity authentication. The keys for both tunnels must be identical to the configuration on the on-premises gateway device. If you leave this blank, the system generates a random key.

Click to view Encryption Configuration

IKE Configurations:
- Version: The recommended version is ikev2. IKEv2 simplifies the SA negotiation process and provides better support for multi-segment scenarios.
- Negotiation Mode:
  - main (Default): In main mode, identity information is encrypted during transmission, which makes the negotiation process more secure than aggressive mode.
  - aggressive: Aggressive mode provides faster negotiation and has a high success rate.
  After successful negotiation, the security of data transmission is the same for both modes.
- Encryption Algorithm: The encryption algorithm used in Phase 1 negotiation. It must be the same as the one on the on-premises gateway device.
  The supported encryption algorithms are aes128 (default), aes192, aes256, des, and 3des.
  For VPN Gateway instances with a bandwidth of 200 Mbps or higher, we recommend using the aes128, aes192, or aes256 encryption algorithms instead of the 3des encryption algorithm.
  - AES is a symmetric-key cryptography algorithm that provides high-strength encryption and decryption. It has a minor impact on network latency, throughput, and forwarding performance while ensuring secure data transmission.
  - 3des is the Triple Data Encryption Algorithm. It has a longer encryption time, higher algorithm complexity, and is more computationally intensive, which reduces forwarding performance compared to AES.
- Authentication Algorithm: The authentication algorithm used in Phase 1 negotiation. It must be the same as the one on the on-premises gateway device.
  The supported authentication algorithms are sha1 (default), md5, sha256, sha384, and sha512.
  On some on-premises gateway devices, you may need to specify the PRF algorithm. The PRF algorithm must be the same as the IKE authentication algorithm.
- DH Group (Perfect Forward Secrecy): Select the Diffie-Hellman key exchange algorithm for Phase 1 negotiation.
  group1, group2 (default), group5, and group14 represent DH1, DH2, DH5, and DH14 of the DH group, respectively.
- SA Life Cycle (seconds): Specifies the lifetime of the security association (SA) that is negotiated in Phase 1. The default value is 86400. The value range is 0 to 86400.
- LocalId: The identifier for the local end of the tunnel. By default, the tunnel's IP address is used as the local identifier.
  This parameter is only an identifier for the Alibaba Cloud side during IPsec-VPN negotiation and has no other function. It supports IP address or Fully Qualified Domain Name (FQDN) format and cannot contain spaces. We recommend using a private IP address as the local tunnel identifier.
  If you use the FQDN format for LocalId, such as example.aliyun.com, the peer ID of the IPsec-VPN connection on the on-premises gateway device must be the same as the value of LocalId. We recommend that you set the negotiation mode to aggressive.
- RemoteId: The identifier for the remote end of the tunnel. By default, the IP address in the associated customer gateway is used as the remote identifier.
  This parameter is only an identifier for the on-premises gateway device during IPsec-VPN negotiation and has no other function. It supports IP address or FQDN format and cannot contain spaces. We recommend using a private IP address as the remote tunnel identifier.
  If you use the FQDN format for RemoteId, such as example.aliyun.com, the local ID of the IPsec-VPN connection on the on-premises gateway device must match the value of RemoteId. We recommend that you set the negotiation mode to aggressive.
IPsec Configurations:
- Encryption Algorithm: The encryption algorithm for Phase 2 negotiation.
  The supported encryption algorithms are aes128 (default), aes192, aes256, des, and 3des.
  For VPN Gateway instances with a bandwidth of 200 Mbps or higher, we recommend using the aes128, aes192, or aes256 encryption algorithms instead of the 3des encryption algorithm.
  - AES is a symmetric-key cryptography algorithm that provides high-strength encryption and decryption. It has a minor impact on network latency, throughput, and forwarding performance while ensuring secure data transmission.
  - 3des is the Triple Data Encryption Algorithm. It has a longer encryption time, higher algorithm complexity, and is more computationally intensive, which reduces forwarding performance compared to AES.
- Authentication Algorithm: The authentication algorithm for Phase 2 negotiation.
  The supported authentication algorithms are sha1 (default), md5, sha256, sha384, and sha512.
- DH Group (Perfect Forward Secrecy): The Diffie-Hellman key exchange algorithm for Phase 2 negotiation.
  - disabled: The DH key exchange algorithm is not used.
    - For clients that do not support PFS, select disabled.
    - If you select any group other than disabled, the Perfect Forward Secrecy (PFS) feature is enabled by default. This requires the key to be updated during each re-negotiation. Therefore, you must also enable the PFS feature on the corresponding client.
  - group1, group2 (default), group5, and group14 represent the DH groups DH1, DH2, DH5, and DH14, respectively.
- SA Life Cycle (seconds): Specifies the lifetime of the SA negotiated in Phase 2. The default value is 86400. The value range is 0 to 86400.
- DPD: Dead Peer Detection. We recommend that you always enable this feature (default). It promptly detects peer failures and triggers a switchover, which is key to achieving high availability.
  After you enable DPD, the IPsec-VPN connection sends DPD messages to detect whether the peer device is active. If no response is received within the specified time, the peer is considered disconnected. The IPsec-VPN connection then deletes the ISAKMP SA and the corresponding IPsec SA, and the secure tunnel is also deleted. After a DPD timeout, the IPsec-VPN connection automatically reinitiates IPsec-VPN tunnel negotiation. The DPD message timeout is 30 seconds.
  For some existing VPN Gateway instances that use IKEv2, the DPD timeout may be 130 seconds or 3600 seconds. In this case, you can upgrade the VPN Gateway instance to the latest version.
- NAT Traversal: We recommend that you keep this enabled by default. When enabled, the IKE negotiation process skips the verification of the UDP port number and can discover NAT gateway devices in the encrypted communication channel.

BGP Configuration (Optional)

If you have enabled BGP, you must complete the BGP configuration for each tunnel.

Confirm the configuration

Carefully review the configuration and then click OK at the bottom of the page.
In the dialog box that appears, click Cancel. You can configure the routing later.
In the Actions column of the target IPsec-VPN connection, click Generate Peer Configuration. In the IPsec-VPN Connection Configuration dialog box, copy the configuration and save it locally to configure the on-premises gateway device.

API

Call the CreateVpnConnection operation to create an IPsec-VPN connection.

2. Configure VPN gateway and VPC routes

Configure the routes as described in Configure routes for a VPN gateway.

3. Configure the on-premises gateway device

Use the peer configuration that you downloaded in the "Configure the IPsec-VPN connection" step to complete the IPsec and BGP (if enabled) configurations on your on-premises gateway device, such as a firewall or router. For specific configuration instructions, see the documentation for your device. For an example, see Configure an on-premises gateway device.

Manage IPsec-VPN connections

Enable or disable BGP

Before you enable BGP for an IPsec-VPN connection, make sure that the associated customer gateway has an ASN configured. If it does not, you must delete and recreate the IPsec-VPN connection and associate it with a customer gateway that has an ASN configured.

The following BGP configuration items are related to the IPsec-VPN connection:

Local ASN: The autonomous system number (ASN) for the Alibaba Cloud side when BGP is enabled. The two tunnels use the same ASN. The default value is 45104. The value range is 1 to 4294967295. We recommend that you use a private ASN when you configure the ASN for the on-premises peer device.
Tunnel CIDR Block: The interconnection address block used to establish a BGP neighbor connection. For a single VPN Gateway instance, the CIDR block for each tunnel must be unique. It must be a /30 subnet within 169.254.0.0/16, and cannot be 169.254.0.0/30, 169.254.1.0/30, 169.254.2.0/30, 169.254.3.0/30, 169.254.4.0/30, 169.254.5.0/30, or 169.254.169.252/30.
Local BGP IP address: The BGP IP address on the Alibaba Cloud side. It must belong to the tunnel CIDR block. For example, in the 169.254.10.0/30 CIDR block, you can use 169.254.10.1.

For information about BGP feature support status, route advertisement principles, and limits, see Configure BGP dynamic routing.

Console

Enable BGP

When you create an IPsec-VPN connection, you can enable Border Gateway Protocol (BGP) by selecting Enable BGP and configuring the Local ASN, Tunnel CIDR Block, and Local BGP IP address.
For an existing IPsec-VPN connection, you can click Enable BGP in the IPsec Connections section on the instance details page.

Disable BGP

On the IPsec-VPN connection details page, in the IPsec Connections section, turn off the Enable BGP switch.

API

When creating a new IPsec-VPN connection, set the EnableTunnelsBgp parameter of the CreateVpnConnection operation to enable BGP, and configure BGP options for each tunnel by setting the TunnelOptionsSpecification -> TunnelBgpConfig parameter.
For an existing IPsec-VPN connection, set the EnableTunnelsBgp parameter of the ModifyVpnConnectionAttribute operation to enable or disable BGP, and configure BGP options for each tunnel by setting the TunnelOptionsSpecification -> TunnelBgpConfig parameter.

Modify tunnel configurations

Console

Go to the IPsec-VPN Connections page in the VPC console, switch to the target region, and click the target IPsec-VPN connection ID.
On the IPsec-VPN connection details page, find the target tunnel, and in the Actions column, click Edit.
On the edit page, modify the tunnel configuration and then click OK.
For descriptions of the tunnel configuration items, see Tunnel and encryption configurations.

API

Call the ModifyTunnelAttribute operation to modify tunnel configurations.

Modify IPsec-VPN connection configurations

If an IPsec-VPN connection is attached to a VPN Gateway instance, you cannot modify the associated VPN Gateway instance. You can only modify the Routing Mode and Effective Immediately settings.

Console

Go to the IPsec-VPN Connections page in the VPC console, switch to the destination region, and click Edit in the Actions column of the target IPsec-VPN connection.
On the Modify IPsec-VPN Connection page, modify settings such as the IPsec-VPN connection name and remote CIDR block, and then click OK.
For detailed descriptions of the parameters, see Create an IPsec-VPN connection.

API

Call the ModifyVpnConnectionAttribute operation to modify IPsec-VPN connection configurations.

Delete an IPsec-VPN connection

Console

Go to the IPsec-VPN Connections page in the VPC console, switch to the destination region, and click Delete in the Actions column of the target IPsec-VPN connection.
In the dialog box that appears, confirm the information, and then click OK.

API

Call the DeleteVpnConnection operation to delete an IPsec-VPN connection.

Billing

An IPsec-VPN connection is free of charge. However, you are charged for the associated VPN Gateway instance. For more information, see IPsec-VPN billing.

FAQ

Why does the tunnel status show "Phase 1 Negotiation Failed"?

If you have completed the IPsec configurations on both the Alibaba Cloud and on-premises sides, the common reasons are as follows:

Pre-shared key mismatch: Carefully check the pre-shared keys on the Alibaba Cloud side and on your on-premises gateway device. Make sure that they are identical, including case and special characters.
IKE parameter mismatch: Check whether the IKE version, negotiation mode, encryption algorithm, authentication algorithm, DH group, and other parameters are identical on both ends.
Network issues: Check whether the public IP address of your on-premises gateway device is reachable and whether any firewall or carrier policies are blocking UDP ports 500 and 4500.

The tunnel status is normal (Phase 2 negotiation succeeded), but I cannot ping the server on the other end. Why?

A successful tunnel negotiation only means that the encrypted channel is established. To check whether data can pass through, inspect the following:

Route configuration: Check whether the Alibaba Cloud VPC route table and your on-premises data center's route table are correctly configured to direct traffic to the IPsec-VPN connection.
Security groups and network ACLs: Check whether the security group of the ECS instance in the VPC allows ICMP or other service traffic from your local CIDR block.
On-premises firewall policy: Check whether the firewall in your on-premises data center allows traffic from the VPC CIDR block.

I want to use BGP dynamic routing, but the "Enable BGP" option is unavailable during configuration. What should I do?

This occurs because the customer gateway that you associated with the IPsec-VPN connection was not configured with an Autonomous System Number (ASN). You must delete the current IPsec-VPN connection, create a new customer gateway with an ASN, and then create a new IPsec-VPN connection that uses the new customer gateway.

Can I set Tunnel 2 as the active tunnel?

No, you cannot. Tunnel 1 (using VPN Gateway IP address 1) is always the active tunnel, and Tunnel 2 (using VPN Gateway IP address 2) is always the standby tunnel. These roles cannot be changed.

Can I create a single-tunnel IPsec-VPN connection?

After you purchase a new VPN Gateway instance, you can only create dual-tunnel IPsec-VPN connections. Single-tunnel IPsec-VPN connections are no longer supported.
If you have an existing single-tunnel VPN Gateway instance, you can only create single-tunnel IPsec-VPN connections for that instance. We recommend that you upgrade the IPsec-VPN connection to dual-tunnel mode as soon as possible to benefit from a high-availability IPsec-VPN connection. After the upgrade, the VPN Gateway instance no longer supports creating single-tunnel IPsec-VPN connections.

Create an IPsec-VPN connection for a single-tunnel VPN Gateway instance

1. Configure the IPsec-VPN connection

Before you begin, make sure that you have created a customer gateway instance.

Console

Go to the IPsec-VPN Connections page in the VPN console, click Bind VPN Gateway, and complete the following configurations:

IPsec Settings

Select the Region and the VPN Gateway instance to attach.
Routing Mode:
- Destination-based Routing Mode (Default): Forwards traffic based on the destination IP address. This mode is easy to configure and suitable for scenarios where routes are learned dynamically through BGP or configured statically on the VPN Gateway.
- Protected Data Flows: Forwards traffic based on source and destination IP addresses. This pattern is suitable for complex network scenarios where you want to allow communication only between specific network segments. After you select this pattern, you must configure the Local Network (the VPC CIDR block that requires communication) and the Remote Network (the on-premises data center CIDR block that requires communication).
  After the IPsec-VPN connection is configured, a policy-based route is automatically created. In this route, the Source CIDR Block is the Local Network of the IPsec-VPN connection, the Destination CIDR Block is the Remote Network of the IPsec-VPN connection, and the next hop is the IPsec-VPN connection. The route can be published to a VPC route table but is not published by default.
  - When you configure interesting traffic on your on-premises gateway device, make sure that the CIDR blocks are consistent with those on the Alibaba Cloud side, but swapped.
  - You can click the icon to add multiple network segments. If you configure multiple network segments, you must select IKEv2 as the IKE protocol version.
Effective Immediately: Select Yes to enable the connection quickly or avoid traffic delays. Select No if you want to save resources and traffic is infrequent.

Tunnel Settings

Customer Gateway: Select the customer gateway instance that represents your on-premises gateway device.
Pre-Shared Key: The key used for identity authentication. The key must be identical to the configuration on the on-premises gateway device. If you leave this blank, the system generates a random key.
Enable BGP: Specifies whether to use BGP dynamic routing.
- Disabled (Default): Uses static routing. This is suitable for simple network topologies.
- Enabled: Suitable for complex network topologies that require automatic route distribution and learning. Prerequisite: The associated customer gateway must have an ASN configured.
Local ASN: The ASN for the Alibaba Cloud side after you enable BGP. The default value is 45104. The value range is 1 to 4294967295. When you configure the ASN for the on-premises peer device, we recommend that you use a private ASN.

Click to view Encryption Configuration

IKE Configurations:
- Version: We recommend that you use ikev2. IKEv2 simplifies the Security Association (SA) negotiation process and provides better support for multi-segment scenarios.
- Negotiation Mode: After successful negotiation, the security of data transmission is the same for both modes.
  - main (Default): In main mode, identity information is encrypted during transmission, which makes the negotiation process more secure than aggressive mode.
  - aggressive: Aggressive mode provides faster negotiation and has a high success rate.
- Encryption Algorithm: The encryption algorithm used in Phase 1 negotiation. It must be the same as the one on the on-premises gateway device.
  The supported encryption algorithms are aes128 (default), aes192, aes256, des, and 3des.
  If a VPN Gateway instance has a bandwidth of 200 Mbps or higher, we recommend using the aes128, aes192, or aes256 encryption algorithms. We do not recommend the 3des encryption algorithm.
  - AES is a symmetric-key cryptography algorithm that provides high-strength encryption and decryption. It has a minor impact on network latency, throughput, and forwarding performance while ensuring secure data transmission.
  - 3des is the Triple Data Encryption Algorithm. Its longer encryption time, higher algorithm complexity, and large computational overhead reduce forwarding performance compared to AES.
- Authentication Algorithm: The authentication algorithm used in Phase 1 negotiation. It must be the same as the one on the on-premises gateway device.
  The supported authentication algorithms are sha1 (default), md5, sha256, sha384, and sha512.
  On some on-premises gateway devices, you may need to specify the PRF algorithm. The PRF algorithm must be the same as the IKE authentication algorithm.
- DH Group (Perfect Forward Secrecy): Select the Diffie-Hellman key exchange algorithm for Phase 1 negotiation.
  group1, group2 (default), group5, and group14 correspond to DH1, DH2, DH5, and DH14, respectively.
- SA Life Cycle (seconds): Specifies the lifetime of the Security Association (SA) that is negotiated in Phase 1. The default value is 86400. The value range is 0 to 86400.
- LocalId: The identifier for the local end of the tunnel. By default, the tunnel's IP address is used as the local identifier.
  This parameter is only an identifier for the Alibaba Cloud side during IPsec-VPN negotiation and has no other function. It supports IP address or FQDN format and cannot contain spaces. We recommend using a private IP address as the local tunnel identifier.
  If you use the FQDN format for LocalId, such as example.aliyun.com, the peer ID of the IPsec-VPN connection on the on-premises gateway device must match the value of LocalId. We recommend that you set the negotiation mode to aggressive.
- RemoteId: The identifier for the remote end of the tunnel. By default, the IP address in the associated customer gateway is used as the remote identifier.
  This parameter is only an identifier for the on-premises gateway device during IPsec-VPN negotiation and has no other function. It supports IP address or FQDN format and cannot contain spaces. We recommend using a private IP address as the remote tunnel identifier.
  If RemoteId uses the FQDN format, such as example.aliyun.com, the local ID of the IPsec-VPN connection on the on-premises gateway device must match the value of RemoteId, and we recommend that you set the negotiation mode to aggressive.
IPsec Configurations:
- Encryption Algorithm: The encryption algorithm for Phase 2 negotiation.
  The supported encryption algorithms are aes128 (default), aes192, aes256, des, and 3des.
  For VPN Gateway instances with a bandwidth of 200 Mbps or higher, we recommend using the aes128, aes192, or aes256 encryption algorithms instead of the 3des encryption algorithm.
  - AES is a symmetric-key cryptography algorithm that provides high-strength encryption and decryption. It has a minor impact on network latency, throughput, and forwarding performance while ensuring secure data transmission.
  - 3des is the Triple Data Encryption Algorithm. It has a longer encryption time, higher algorithm complexity, and is more computationally intensive, which reduces forwarding performance compared to AES.
- Authentication Algorithm: The authentication algorithm for Phase 2 negotiation.
  The supported authentication algorithms are sha1 (default), md5, sha256, sha384, and sha512.
- DH Group (Perfect Forward Secrecy): The Diffie-Hellman key exchange algorithm for Phase 2 negotiation.
  - disabled: Indicates that the DH key exchange algorithm is not used.
    - For clients that do not support PFS, select disabled.
    - If you select any group other than disabled, the Perfect Forward Secrecy (PFS) feature is enabled by default. This requires the key to be updated during each re-negotiation. Therefore, the PFS feature must also be enabled on the corresponding client.
  - group1, group2 (default), group5, and group14 represent the DH groups DH1, DH2, DH5, and DH14, respectively.
- SA Life Cycle (seconds): Specifies the lifetime of the security association (SA) negotiated in Phase 2. The default value is 86400. The value range is 0 to 86400.
- DPD: Dead Peer Detection. We recommend that you always enable this feature (default). It promptly detects peer failures and triggers a switchover.
  After you enable DPD, the IPsec-VPN connection sends DPD messages to detect whether the peer device is active. If no response is received within the specified time, the peer is considered disconnected. The IPsec-VPN connection then deletes the ISAKMP SA and the corresponding IPsec SA, and the secure tunnel is also deleted. After a DPD timeout, the IPsec-VPN connection automatically reinitiates IPsec-VPN tunnel negotiation. The DPD message timeout is 30 seconds.
  For some existing VPN Gateway instances that use IKEv2, the DPD timeout may be 130 seconds or 3600 seconds. In this case, you can upgrade the VPN Gateway instance to the latest version.
- NAT Traversal: We recommend that you keep this enabled by default. When enabled, the IKE negotiation process skips the verification of the UDP port number and can discover NAT gateway devices in the encrypted communication channel.

BGP Configuration (Optional)

If you have enabled BGP, you must complete the BGP configuration for the tunnel.

Health Check

This feature is disabled by default. We do not recommend that you configure health checks for an IPsec-VPN connection in a non-active/standby scenario. If you configure a health check, you must ensure that the Destination IP Address supports ICMP replies. You must also add a route in your on-premises data center that has the Source IP Address as the destination CIDR block, a 32-bit subnet mask, and the IPsec-VPN connection as the next hop. This ensures that the health check for the IPsec-VPN connection works as expected.

Confirm the configuration

Carefully review the configuration and then click OK at the bottom of the page.
In the dialog box that appears, click Cancel to configure the routing later.
In the Actions column of the target IPsec-VPN connection, click Generate Peer Configuration, copy the configuration, and save it locally to configure the on-premises gateway device.