SoftEther VPN User Forum

Hey everyone, I'm having some trouble getting LANs to communicate with a site-to-site configuration. Both servers are Softether OpenVPN servers on virtual machines. I have the servers communicating with each other from what I can tell. Any help would be appreciated. My configuration is below. Also, I used the guide here for reference: https://www.softether.org/4-docs/1-manu ... P_Routing)


Main Site:

Network: 192.168.5.0/24

Local Bridge connects to VM network adapter
Virtual Hub Name: BNT Tech
Network Adapter: ens18

Layer 3 Virtual Switch
IP Address: 192.168.5.254/24
Virtual Hub Name: BNT Tech


Virtual Hub Sessions indicate connected and traffic flow

Remote Site:

Network: 192.168.2.0/24

Local Bridge connects to VM network adapter
Virtual Hub Name: ALC-LG
Network Adapter: ens160

Layer 3 Virtual Switch
IP Address: 192.168.2.254/24
Virtual Hub Name: ALC-LG

Cascade Connection
Host Name: Public IP of Main Site
Port #: 1194
Virtual Hub Name: BNT Tech

Connection indicates established
After entering the static routes, I'm unable to communicate with the remote subnets.

Hi, did you enable Promiscuous Mode/MAC Address Spoofing on the hosts of the VMs?
Those static routes were added to SoftEther's "Routing Table Entry" or to PCs/routers on the LANs?

I do not study your question completely, may be what I write does not apply for you.

In the pas I also spent a lot lot time to make it. Then I realized it simply does not work with our company network. We have quite
complicated topology.

Then I tested it with simple and clear network and it works.

For you I would suggest to use a few computers to make small network and test it on it first. If it works then network you want to use is
"complicated" so it will not work.

solo wrote: ↑

Mon Feb 07, 2022 10:01 am

Hi, did you enable Promiscuous Mode/MAC Address Spoofing on the hosts of the VMs?
Those static routes were added to SoftEther's "Routing Table Entry" or to PCs/routers on the LANs?

Hey solo, I appreciate your reply. I do have promiscuous mode enabled on the VMs. For more clarification, both VMs are running on Proxmox hosts. The Main Site network is using VLANs while the Remote Site is not. However, the VLAN awareness setting is not enabled for the VMs. Not sure if that makes a difference or not. I did try enabling it and the VPN connection still didn't work.

You created a cascade from ALG-LG to BNT Tech but they are in different subnets. This is equivalent to connecting two networks with a cable. What do you expect?

Thanks eddiwu. Shouldn't the bridge and vSwitch IPs fix that though after the proper routes have been put in place?


That did somewhat trigger my thought process though so I decided to start over with the whole thing to make sure I didn't miss anything. I feel like this should work with the setup I have though. I can now ping the Main Site vSwitch IP address, not any other IPs though. I'm also not able to ping the Remote Site vSwitch IP from the Main Site.


Main Site:
- 2 virtual hubs
-- ALC-LG (Local)
-- BNT-Tech
- 1 Local bridge
-- ALC-LG (Local) to ens18
- 1 vSwitch
-- IP: 192.168.5.254/24 connected to Virtual Hub "ALC-LG (Local)"
-- IP: 192.168.2.254/24 connected to Virtual Hub "BNT-Tech"
- 1 Cascade connection to "DEFAULT" hub on remote site
- Gateway static route
-- Network 192.168.2.0/24 via 192.168.5.254

Remote Site:
- 1 virtual hub
-- DEFAULT
- 1 Local bridge
-- DEFAULT to ens160
- 1 User using certificate authentication
- Gateway static route
-- Network 192.168.5.0/24 via 192.168.2.254

your Network at the main site:
Did you implement a route for all devices in this network which makes the remote network available by the route 192.168.5.254?

Yes, static route is implemented at the gateway of the main site. Network 192.168.2.0/24 via 192.168.5.254.

You should go from simple to complicated....

As I suggested before, make your own small network of a few PCs and test it there. You will see it works....

But then you will understand it will never work with you real network as it is too complicated for SoftEther and S-2-S communication

Is it safe to assume that the documentation at the link below is wrong then?

https://www.softether.org/4-docs/1-manu ... P_Routing)

According to this, s-2-s communication does work.

Of course it works.

nethompson wrote: ↑

Tue Feb 08, 2022 6:55 pm

Is it safe to assume that the documentation at the link below is wrong then?

https://www.softether.org/4-docs/1-manu ... P_Routing)

According to this, s-2-s communication does work.

it does not work for some "complicated" networks - and we have such network at offices, I have not investigated why exactly it does not work

but it DOES work on simple network, I did test it to work using a few computers like on the picture you refer to, each in different subnet

if you want to have a good sleep test it Like I did to be sure you do not make a mistake, then accept it will not work on every network

if you are able to identify what is the problem why it does not work sometimes would be nice, but for me it was enough to know it is like I write

Update on this:

I have this working (to an extent). What I'm having trouble with now is the routing table(s). I've detailed the setup below with the changes highlighted.


Main Site:
- 2 virtual hubs
-- ALC-LG (Local)
-- BNTTech
COLOR=#FF0000 - 2 Local bridges
-- ALC-LG (Local) to ens18
-- BNTTech to ens18
- 1 vSwitch with 2 interfaces
-- IP: 192.168.5.254/24 connected to Virtual Hub "ALC-LG (Local)"
-- IP: 192.168.2.254/24 connected to Virtual Hub "BNTTech"
- User account created on "BNTTech" virtual hub
- Gateway static route
-- Network 192.168.2.0/24 via 192.168.5.254

Remote Site:
- 1 virtual hub
-- ALC-LG
- 1 Local bridge
-- ALC-LG to ens160
- Cascade connection to main site
COLOR=#FF0000 - Static route on single computer
-- Network 192.168.5.0/24 via 192.168.2.254


The static route is where I'm having trouble with now and it's on the remote site. I'm using an Ubuntu server as the gateway. Adding the static route to the gateway prevents communication. If I add the static route to a computer manually then everything works.

I have this working fully now!

I added a second NIC to the remote site gateway (Linux server), bridged that connection in place of the original, set the static route, and presto!