VPN Clients are Connected and Have TCP Connections but Cannot Ping (Cluster with Static Hub Problem)

[gregory112]

Hi everyone,

I have set up (multiple times) a simple two VMs VPN cluster in GCP (and AlibabaCloud, in fact). One node is set up as controller, and the other as member. Each VMs are connected via 10.x.x.x private network, and has public IP address.

I have configured the member to connect to the controller via private address and not public. I have also configured the public IP address of the member. I have also created a static hub.

After setting up dummy users, I have my laptop and another VM to connect to the cluster. The public IP address of the cluster controller is specified as the destination server address as usual. Accessing the ClusterConnectionStatusGet command in the member yield this result:

Code: Select all

ClusterConnectionStatusGet command - Get Connection Status to Cluster Controller
Item                             |Value
---------------------------------+-------------------------
Controller IP Address            |10.x.x.x
Controller TCP/IP Port           |992
Connection Status                |Online
Connection Started at            |2023-03-13 (Mon) 13:01:53
First Connection Established at  |2023-03-13 (Mon) 13:01:53
Current Connection Established at|2023-03-13 (Mon) 13:01:53
Number of Connection Attempts    |1
Number of Successful Connections |1
Number of Failed Connections     |0
The command completed successfully.

The output of ClusterMemberList in controller:

Code: Select all

ClusterMemberList command - Get List of Cluster Members
        ID|Type      |Connection Started at    |Host Name|Point|Number of Sessions|Number of TCP Connections|Number of Operating Hubs|Using Client Connection Licenses|Using Bridge Connection Licenses
----------+----------+-------------------------+---------+-----+------------------+-------------------------+------------------------+--------------------------------+--------------------------------
3764370032|Controller|2023-03-13 (Mon) 12:52:30|gaia     |99999|                 1|                       21|                       1|                               1|                               0
3173883201|Member    |2023-03-13 (Mon) 13:01:53|ares     |99999|                 1|                       21|                       1|                               1|                               0

Finally, getting in the hub and executing SessionList, we get:

Code: Select all

SessionList command - Get List of Connected Sessions
Item            |Value
----------------+---------------
Session Name    |SID-USER1-24
VLAN ID         |-
Location        |On 'gaia'
User Name       |user1
Source Host Name|redacted
TCP Connections |2 / 2
Transfer Bytes  |43,134
Transfer Packets|1,027
----------------+---------------
Session Name    |SID-USER2-1
VLAN ID         |-
Location        |On 'ares'
User Name       |user2
Source Host Name|redacted
TCP Connections |2 / 2
Transfer Bytes  |354,018
Transfer Packets|5,353
The command completed successfully.

It shows that all the clients have successfully created TCP connections. No NAT/DHCP is enabled, so both clients are given static IP. This is even detected in IpTable command:

Code: Select all

IpTable command - Get the IP Address Table Database
Item        |Value
------------+-------------------------
ID          |1241270314
Session Name|SID-USER1-24
IP Address  |192.168.100.10
Created at  |2023-03-13 13:31:45
Updated at  |2023-03-13 13:49:33
Location    |On 'gaia'
------------+-------------------------
ID          |351225459
Session Name|SID-USER2-1
IP Address  |192.168.100.11
Created at  |2023-03-13 13:15:06
Updated at  |2023-03-13 14:10:03
Location    |On 'ares'
The command completed successfully.

But pinging each other results in Destination Host Unreachable. Doing `tcpdump` on the virtual VPN client interface results in nothing (no packet detected).

How do I debug this? How do I know that the cluster connection is working and TCP connections are healthy? Thank you in advance.

[solo]

Enable "Promiscuous Mode" or "MAC Address Spoofing" or "Port Mirroring" or "Forged Transmits" or whatever it is called on the VMs' NICs.

[gregory112]

Hi, I have turned on IP Forwarding in GCP. In fact due to this I have some other network infrastructure that works (Calico CNI).

Looking at tcpdump, I realized that my laptop is sending ARP requests through the virtual VPN interface and got no reply. However, I received an ARP request, probably from the server to fill IpTable, but not from the other devices in the VPN network.

Any other ideas?

[gregory112]

Reading from https://www.softether.org/4-docs/1-manu ... _Functions section 3.4.8 it is explained that the VPN server sends unicast ARP request to clients to detect their IP addresses. Because my devices do receive ARP requests and IP addresses are registered in IpTable output successfully, I can see that the connections between the client and the server are healthy.

[solo]

Hi, I have turned on IP Forwarding in GCP. In fact due to this I have some other network infrastructure that works (Calico CNI).

But we don't care about IP forwarding here. Enable promiscuous mode.

[gregory112]

Both are the same thing aren't they? Enabling IP Forwarding enables all kinds of IP addresses packets to pass through the interface. I have also enabled promisc mode in Linux with `ip` command but it does not work. There is no "promisc mode" for GCP other than IP Forwarding.

[solo]

No, check https://stackoverflow.com/questions/596 ... cuous-mode

[gregory112]

I have seen that stackoverflow post matter of fact. In it it is described to create two vNICs to access different VPCs, and enable IP Forwarding for the second answer. I don't see why creating additional vNIC to connect to other VPC is relevant here.

[gregory112]

Would you also explain why promiscious mode is required here? I have set up a single server SoftEther VPN server and it does work. Now with clustering, it does not.

[solo]

SE docs

Note 1. Local Bridge Requires Promiscuous Mode
Some VMs prohibit the "Promiscuous Mode" (MAC Address Spoofing) on the network adapters by default. If the Promiscuous Mode (MAC Address Spoofing) is administratively disabled, the Local Bridge function between a Virtual Hub on the VPN Server and a physical network adapter on the physical computer does not work well. You should allow the Promiscuous Mode (MAC Address Spoofing) by using the configuration tool of the VM. For details please refer the documents of your VM. If it is a shared-VM and administrated by other person, please request the administrator to permit the use of the Promiscuous (MAC Address Spoofing) Mode to your VM.

[gregory112]

Yes, but I don't have local bridge. I have no need of VPN clients being able to communicate with the server physical network. I just need all VPN clients to be able to communicate to each other, with a softether VPN cluster and static hub.

[solo]

Yes, but I don't have local bridge. I have no need of VPN clients being able to communicate with the server physical network. I just need all VPN clients to be able to communicate to each other, with a softether VPN cluster and static hub.

Let's see:

- VPN cluster
- static hubs
- no local bridge

Then good luck.

When a static Virtual Hub is created on the cluster controller an instance of that static Virtual Hub will automatically be made on all VPN Servers in the cluster. (See section 3.9 Clustering.) Next, make a direct administrative connection to each VPN Server and set up a local bridge connection between that Virtual Hub and the physical LAN you wish to connect to remotely. (For more information on creating local bridge connections, see section 3.6 Local Bridges.) As explained previously, if the network you wish to connect to remotely has multiple segments, you must make local bridge connections between each static Virtual Hub and their respective physical LAN. (You will need multiple network adapters for this.)

[gregory112]

Okay I get it you need local bridge and connection to physical LAN to provide clustering. It is not explained in detail that packets are required to travel via physical LAN (I thought the cluster connection already does that).

Eventually because the cloud physical LAN does not support broadcast/multicast that I need for DHCP to work (and other things), I had to set up an overlay network with BGP EVPN and VXLAN and created a tap local bridge. I get some success even though Ticket Authentications fail most of the time. For this I will just open a new issue.