Resolving "Several VPN Servers on the same IP address" Error with Multiple Virtual Hubs

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
valant98
Posts: 19
Joined: Tue Feb 21, 2023 8:07 am

Resolving "Several VPN Servers on the same IP address" Error with Multiple Virtual Hubs

Post by valant98 » Wed Oct 23, 2024 9:03 am

Hello SoftEther Community,

I'm experiencing an issue with my SoftEther VPN Server setup and would appreciate your guidance.

Server Environment:
Ubuntu Linux on a Google Cloud Platform VM.

Features Enabled:
  • OpenVPN Clone Server Function.
  • SecureNAT with virtual NAT and Virtual DHCP Server enabled on all virtual hubs.
  • There are no local bridges assigned to any virtual hubs.
Initial Virtual Hub Configuration:

I have four virtual hubs, and initially, they were all configured with the same subnet:
  • SecureNAT Enabled: Virtual NAT and Virtual DHCP Server active on each hub.
  • Subnet: 192.168.10.0/24 for all hubs.
  • DHCP Settings: Each hub's DHCP server assigned IPs within the 192.168.10.0/24 range.
  • Default Gateway: Set to the SecureNAT virtual gateway IP (192.168.10.1) within each subnet.
Use Case Details:

Router Connections:
  • A router acts as an OpenVPN client in TAP mode and connects to Virtual Hub 1.
  • On the router:
    ethernet1 is connected to the WAN.
    ethernet2 is bridged with the TAP interface.
    Devices connected to ethernet2 are forwarded to the VPN server.
  • Client Access:
    Another user connects to Virtual Hub 1 using the SoftEther VPN Client.
    This setup allows access to devices connected behind the router on ethernet2.
The Problem:
  • Error Message: "Several VPN Servers on the same IP address" error window pops up when i am trying to access the "Softether VPN Server Manager."
  • Behavior: The VPN server stops responding for several hours, despite appearing active.
  • Frequency: This issue started recently after months of stable operation.
Actions Taken:
After some reboots of the Virtual Machine I had the opportunity to Access the Softether VPN Server Manager and put all of my Virtual Hubs 'Offline'
and then,

Changed Subnets for Virtual Hubs:
  • I updated each virtual hub to have a unique subnet:
Virtual Hub 1: 192.168.10.0/24
Virtual Hub 2: 192.168.20.0/24
Virtual Hub 3: 192.168.30.0/24
Virtual Hub 4: 192.168.40.0/24
  • DHCP Settings: Adjusted to assign IPs within the new subnet ranges.
  • Default Gateways: Updated to match the new subnets (e.g., 192.168.20.1 for Virtual Hub 2).
Current Status:
The "Several VPN Servers on the same IP address" error is no longer appearing, but I'm not entirely sure if this change fixed the issue or if the problem might recur.

My Concerns and Questions:

Was Subnet Separation the Correct Fix?
  • Effectiveness: Did changing the virtual hubs to unique subnets resolve the issue, or might there be underlying problems that could cause the error to return?
  • Validation: Is this configuration considered best practice in SoftEther VPN deployments?
Potential Issues with Current Configuration:
  • Points of Concern: Are there any aspects of my current setup that I should be cautious about to prevent future conflicts?
  • Preventative Measures: What steps can I take to ensure long-term stability with multiple virtual hubs (more than 50)?
Clients with the Same Static IP Address:
  • Situation: Some clients are manually assigned the same static IP address (e.g., 192.168.10.10), but they connect to different virtual hubs with different subnets.
  • Isolation: There is no routing or bridging between virtual hubs, and each hub operates independently.
  • Question: Could assigning the same static IP address to clients on different virtual hubs cause conflicts or contribute to the original error, even though the hubs are on separate subnets?
Best Practices for IP Addressing in Multi-Hub Environments:
  • IP Assignment Strategy: Should all clients across all virtual hubs have unique IP addresses, even if the hubs are isolated?
  • Static vs. Dynamic IPs: Is it better to use DHCP for client IP assignment to avoid accidental duplication?
  • Network Design Recommendations: What are the recommended practices for configuring multiple virtual hubs to prevent IP conflicts and ensure optimal performance?
I am really sorry for the long post,
I much appreciate any help.

solo
Posts: 1613
Joined: Sun Feb 14, 2021 10:31 am

Re: Resolving "Several VPN Servers on the same IP address" Error with Multiple Virtual Hubs

Post by solo » Wed Oct 23, 2024 10:29 am

valant98 wrote:
Wed Oct 23, 2024 9:03 am
  • Frequency: This issue started recently after months of stable operation.
It's a rare issue unrelated to your setup of SoftEther, check these...
viewtopic.php?t=64747#p95978
https://community.ipfire.org/t/vpn-soft ... ation/1832

valant98
Posts: 19
Joined: Tue Feb 21, 2023 8:07 am

Re: Resolving "Several VPN Servers on the same IP address" Error with Multiple Virtual Hubs

Post by valant98 » Thu Oct 24, 2024 7:22 am

Thank you for the reply.

One important detail I forgot to mention earlier is that we have assigned a DNS name to the public IP address of our virtual machine on Google Cloud. Clients are now using this DNS name to connect to the VPN server instead of the direct IP address.

Could this change be contributing to the "Several VPN Servers on the same IP address" error?

Could this affect how the server interprets incoming connections and lead to the error we're experiencing?

Lastly, I wanted to ask: Is it really a problem to assign the same subnet to all virtual hubs' SecureNAT configurations?

Could using the same IP subnet (e.g., 192.168.10.0/24) for SecureNAT across all virtual hubs cause conflicts or contribute to the "Several VPN Servers on the same IP address" error?

crooks22
Posts: 3
Joined: Mon Feb 24, 2025 10:27 am

Re: Resolving "Several VPN Servers on the same IP address" Error with Multiple Virtual Hubs

Post by crooks22 » Mon Feb 24, 2025 10:29 am

I encountered a similar issue before! Ensuring that each virtual hub has a unique subnet is essential to prevent overlapping IP addresses. It's good to see you’ve taken steps to isolate the hubs. Hopefully, this change will restore stability to your VPN setup!

Post Reply