Multi-client communication-VPN Gateway(VPN)-阿里云帮助中心

By default, when you use SSL-VPN to connect multiple clients to a VPC, clients connected to the same VPN gateway can communicate with the VPC and with each other.

Use cases

A company needs to scale its server resources as its business grows. To reduce hardware costs, the company deploys servers on Alibaba Cloud and requires a solution to meet the following connectivity requirements:

On-premises servers (Client 2 and Client 3) must communicate with servers in the VPC over a private network.
Employees on business trips (Client 1) need remote access to all internal server resources.

SSL-VPN can meet these connectivity requirements. By creating a VPN gateway in the VPC and installing VPN software on Client 1, Client 2, and Client 3, you can establish SSL-VPN connections between each client and the VPC. This setup enables encrypted, private communication among the clients and the ECS instance.

Prerequisites

You have created a VPC and deployed services on ECS instances within it.
Client 1, Client 2, and Client 3 have access to the internet.

Procedure

Step 1: Create a VPN gateway

Log on to the VPN gateway console.
On the VPN Gateways page, click Create VPN Gateway.
On the VPN gateway (Subscription) page, configure the VPN gateway with the following settings, and then click Buy Now and complete the payment.
- Region and zone: Select the region for the VPN gateway. This example uses China (Hangzhou).
  Note
  Ensure the VPN gateway and the VPC are in the same region.
- Gateway Type: Select Standard.
- Network Type: Select Internet.
- VPC: Select the VPC.
- vSwitch 1: Select a vSwitch from the VPC.
- vSwitch 2: Select a second vSwitch from the VPC.
  If a region has multiple zones, you must specify two vSwitches in different zones. Each vSwitch must have at least one available IP address. If your vSwitches do not meet the requirements, create new vSwitches.
- IPsec-VPN: Select Close.
- SSL-VPN: Select Enable.
- SSL-VPN Connections: Select the maximum number of clients that can connect simultaneously.
The settings listed are specific to this tutorial. For all other settings, keep the default values or leave them empty. See Create and manage a VPN gateway.
Return to the VPN Gateways page to view the created VPN gateway.
The status of a newly created VPN gateway is Preparing. After about 1 to 5 minutes, the status changes to Normal. The Normal status indicates that the VPN gateway is initialized and ready.

Step 2: Create an SSL server

In the left navigation pane, choose Interconnections > VPN > SSL Servers.
In the top navigation bar, select the region of the SSL server.
Note
Ensure the SSL server is in the same region as the VPN gateway.
On the SSL Server page, click Create SSL Server.
In the Create SSL Server panel, configure the SSL server with the following settings, and then click OK.
- VPN Gateways: Select the VPN gateway that you created.
- Local CIDR Block: Enter the CIDR block of the VPC that clients will access. This example uses 192.168.0.0/16.
- Client CIDR Block: Enter the CIDR block from which clients will be assigned IP addresses. This example uses 10.0.99.0/24.
  Important
  - The subnet mask of the client CIDR block must be 16 to 29 bits in length.
  - The client CIDR block must not overlap with the Local Network, the VPC CIDR block, or any CIDR blocks routed on the client.
  - Use private CIDR blocks such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, or their subnets. To use a public IP range, configure it as a user-defined CIDR block in the VPC for proper routing. VPC FAQ and VPC FAQ.
  - After you create the SSL server, the system adds a route for the client CIDR block to the VPC route table. Do not manually add this route, as it may disrupt SSL-VPN traffic.
  The settings listed are specific to this tutorial. For all other settings, keep the default values or leave them empty. See Create and manage an SSL server.

Step 3: Create SSL clients and download certificates

Follow the steps below to create an SSL client and download its certificate for each of Client 1, Client 2, and Client 3.

In the navigation pane on the left, choose Interconnections > VPN > SSL Clients.
On the SSL Client page, click Create SSL Client.
In the Create SSL Client panel, enter a name for the SSL client, select the SSL server that you created, and then click OK.
On the SSL Client page, find the SSL client that you created and click Download Certificate in the Actions column.
Save the downloaded SSL client certificate locally. You will need it to configure the client.

Step 4: Configure the clients

Install the VPN software and SSL client certificate on each client to establish an SSL-VPN connection to the VPC.

In this tutorial, Client 1 and Client 2 use Windows Server 2025 Datacenter Edition 64-bit, and Client 3 uses Ubuntu 24.04 64-bit. If your client uses macOS or Android, see Configure a client.

Client 1 and Client 2

Download the OpenVPN client for your Windows version and follow the on-screen instructions to install it.
- Windows 64-bit system (Intel/AMD): OpenVPN client (Windows 64-bit).
- Windows ARM64 system: OpenVPN client (Windows ARM64).
Unzip the downloaded ssl client certificate package and copy all extracted files to the OpenVPN configuration directory.
- Default path: C:\Program Files\OpenVPN\config
- Note: If you changed the installation path, copy the files to the config folder in your actual installation directory.
Open the config.ovpn file with a text editor and add the following line to the end of the file: disable-dco.
The Data Channel Offload (DCO) feature introduced in OpenVPN 2.6 is incompatible with some Windows systems, such as specific versions of Windows 10 and 11. This configuration disables DCO to resolve potential connection issues on these devices.
Right-click the OpenVPN icon in the system tray, and then click Connect to establish a VPN connection.
If the state changes to Connected and an IP address is assigned, the connection is successful.

Client 3

Log on to the client and open a command-line window.
Run the following commands to install the OpenVPN client and create the conf directory.
```
apt-get update
apt-get install -y openvpn
mkdir -p /etc/openvpn/conf
```
Extract the downloaded SSL client certificate and copy the files to the /etc/openvpn/conf/ directory.
Change to the /etc/openvpn/conf/ directory and run the following command to establish the SSL-VPN connection.
```
openvpn --config /etc/openvpn/conf/config.ovpn --daemon
```

After you complete these configurations, log on to the VPN Gateway console. On the SSL server details page, you can view the virtual IP address assigned to each client. Clients use these virtual IP addresses to communicate with the VPC and with each other.

On the SSL Connections tab, the Virtual Address column in the connection list shows the virtual IP address assigned to each client (such as 10.0.99.6, 10.0.99.14, and 10.0.99.10). All connections are in the Running state.

Step 5: Test the connectivity

After the SSL-VPN connection is successfully established, any two nodes among Client 1, Client 2, Client 3, and the ECS instance can communicate with each other, provided that their security groups and local firewalls permit the traffic. This tutorial demonstrates how to verify connectivity between Client 1 and Client 2, Client 3, and the ECS instance as an example.

Note

Before you test the connectivity, ensure the access control rules for Client 1, Client 2, and Client 3, as well as the security group rules for the ECS instance, allow ICMP traffic from nodes in the Client CIDR Block.

Test access from Client 1 to Client 2, Client 3, and the ECS instance.

Log on to Client 1 and open a Command Prompt window.
In the Command Prompt window, run the ping <virtual_IP_of_client_or_IP_of_ECS> -S <virtual_IP_of_Client_1> command to ping Client 2, Client 3, and the ECS instance by using the virtual IP address of Client 1 as the source.

If Client 1 receives reply packets, it indicates that Client 1 can access Client 2, Client 3, and the ECS instance.

C:\Users\Administrator>ipconfig

Windows IP Configuration


Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fexxx                    %3
   IPv4 Address . . . . . . . . . . . : 17xxx
   Subnet Mask . . . . . . . . . . . : 25xxx
   Default Gateway . . . . . . . . . :

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fexxx                    b8%10
   IPv4 Address . . . . . . . . . . . : 10.0.99.6
   Subnet Mask . . . . . . . . . . . : 255.255.255.252
   Default Gateway . . . . . . . . . :

C:\Users\Administrator>ping 10.0.99.10 -S 10.0.99.6

Pinging 10.0.99.10 from 10.0.99.6 with 32 bytes of data:
Reply from 10.0.99.10: bytes=32 time=14ms TTL=128
Reply from 10.0.99.10: bytes=32 time<1ms TTL=128
Reply from 10.0.99.10: bytes=32 time<1ms TTL=128
Reply from 10.0.99.10: bytes=32 time=23ms TTL=128

Ping statistics for 10.0.99.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 23ms, Average = 16ms

C:\Users\Administrator>ping 10.0.99.14 -S 10.0.99.6

Pinging 10.0.99.14 from 10.0.99.6 with 32 bytes of data:
Reply from 10.0.99.14: bytes=32 time=13ms TTL=64
Reply from 10.0.99.14: bytes=32 time<1ms TTL=64
Reply from 10.0.99.14: bytes=32 time<1ms TTL=64
Reply from 10.0.99.14: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.99.14:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 16ms, Average = 13ms

C:\Users\Administrator>ping 192.168.50.67 -S 10.0.99.6

Pinging 192.168.50.67 from 10.0.99.6 with 32 bytes of data:
Reply from 192.168.50.67: bytes=32 time=5ms TTL=63
Reply from 192.168.50.67: bytes=32 time<1ms TTL=63
Reply from 192.168.50.67: bytes=32 time=7ms TTL=63
Reply from 192.168.50.67: bytes=32 time<1ms TTL=63

Ping statistics for 192.168.50.67:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 7ms, Average = 5ms

Log on to Client 2, Client 3, and the ECS instance respectively, and run commands to test access to Client 1. Receiving reply packets confirms that the ECS instance, Client 2, and Client 3 can communicate with Client 1.

Client 2

ipconfig: View the virtual IP address of the client.
ping <virtual_IP_of_Client_1> -S <virtual_IP_of_Client_2>: Ping Client 1 by using the virtual IP address of Client 2 as the source.

C:\Users\Administrator>ipconfig

Windows IP Configuration


Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe8xxx d1%6
   IPv4 Address. . . . . . . . . . . : 192xxx
   Subnet Mask . . . . . . . . . . . : 255xxx
   Default Gateway . . . . . . . . . : 192xxx

Ethernet adapter Ethernet 2:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80xxx ac%10
   IPv4 Address. . . . . . . . . . . : 10.0.99.10
   Subnet Mask . . . . . . . . . . . : 255.255.255.252
   Default Gateway . . . . . . . . . :

C:\Users\Administrator>ping 10.0.99.6 -S 10.0.99.10

Pinging 10.0.99.6 from 10.0.99.10 with 32 bytes of data:
Reply from 10.0.99.6: bytes=32 time=13ms TTL=128
Reply from 10.0.99.6: bytes=32 time=13ms TTL=128
Reply from 10.0.99.6: bytes=32 time=13ms TTL=128
Reply from 10.0.99.6: bytes=32 time=13ms TTL=128

Ping statistics for 10.0.99.6:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 13ms, Average = 13ms

Client 3

ifconfig: View the virtual IP address of the client.
ping <virtual_IP_of_Client_1> -I <virtual_IP_of_Client_3>: Ping Client 1 by using the virtual IP address of Client 3 as the source.

[root@xxx ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet xxx.xxx.xxx.55
        inet6 xxx
        ether xxx    txqueuelen 1000  (Ethernet)
        RX packets 2474679  bytes 640629531 (610.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2487018  bytes 745400919 (710.8 MiB)
        TX errors 0  dropped 0  overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 136  bytes 10888 (10.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 136  bytes 10888 (10.6 KiB)
        TX errors 0  dropped 0  overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.0.99.14  netmask 255.255.255.255  destination 10.0.99.13
        inet6 fe xxx  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 8752  bytes 734506 (717.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8884  bytes 740853 (723.4 KiB)
        TX errors 0  dropped 0  overruns 0  carrier 0  collisions 0

[root@xxx ~]# ping 10.0.99.6 -I 10.0.99.14
PING 10.0.99.6 (10.0.99.6) from 10.0.99.14 : 56(84) bytes of data.
64 bytes from 10.0.99.6: icmp_seq=1 ttl=128 time=14.4 ms
64 bytes from 10.0.99.6: icmp_seq=2 ttl=128 time=13.7 ms
64 bytes from 10.0.99.6: icmp_seq=3 ttl=128 time=13.7 ms
64 bytes from 10.0.99.6: icmp_seq=4 ttl=128 time=13.7 ms
^Z

[2]+  Stopped                 ping 10.0.99.6 -I 10.0.99.14

ECS instance

ifconfig: View the virtual IP address of the client.
ping <virtual_IP_of_Client_1>

[root@xxx ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.50.67  netmask 255.255.255.0  broadcast 192.168.50.255
        ether xxx  f7  txqueuelen 1000  (Ethernet)
        RX packets 958323  bytes 364771701 (347.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 671749  bytes 448020661 (427.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Local Loopback)
        RX packets 3  bytes 336 (336.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 336 (336.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@xxx ~]# ping 10.0.99.6
PING 10.0.99.6 (10.0.99.6) 56(84) bytes of data.
64 bytes from 10.0.99.6: icmp_seq=1 ttl=127 time=9.76 ms
64 bytes from 10.0.99.6: icmp_seq=2 ttl=127 time=5.22 ms
64 bytes from 10.0.99.6: icmp_seq=3 ttl=127 time=5.27 ms
64 bytes from 10.0.99.6: icmp_seq=4 ttl=127 time=5.28 ms
^Z
[1]+  Stopped                 ping 10.0.99.6
[root@iZbp13op13erqvwakinw7rZ ~]#

FAQ

IPsec and SSL client communication

Yes.

To allow communication between an on-premises data center connected via IPsec-VPN and SSL-VPN clients, you must add a route to the Client CIDR Block in the on-premises data center and add the data center's CIDR block to the Local CIDR Block field of the SSL server.