Can't ping SoftEther server when connected through VPN

[genesys]

When connected through VPN (both with SoftEther VPN client as well as SSTP client) I can ping all machines in the local network of the vpn server, EXCEPT for the VPN server itself.

I also can't connect VPN Server Manager from my laptop (connected via VPN) to my SoftEther server - I can only connect it if I am with my laptop physically onsite.

Any ideas why that is and how to solve it?

[OliverTejada]

Does target VPN server have a local bridge to the physical network, or are you using SoftEther's VirtualNAT

[genesys]

It has a local bridge to the 'physical' network adapter (server runs on a hyper-v VM, so the servers physical eth0 adapter is created through a hyper-v virtual switch)

[centeredki69]

If you haven't already, in HyperV manager you need to edit the network adapter advanced feature in the SE- host VM settings area. MAC static, enable MAC spoofing.

[genesys]

Jep I did that, otherwise I think the VPN connection couldn't work at all

[OliverTejada]

This is a common issue with promiscuous mode within VMs... Hypervisor's fault.

[genesys]

So, any way to solve it?

[OliverTejada]

So, any way to solve it?

Well, if the localbridge has this unexpected behavior, your solution is VirtualNAT, kinda slower and sometimes buggy but gets the connectivity done.

[genesys]

If I understand correclty, the following is happening:

Hypervisor implements a virtual switch, which is a layer 2 virtual device (no layer 3 routing).
On the Virtual machine, there is a "physical" eth0 adapter (which is created in software by the hypervisor virtual switch).
this eth0 adapter is bridged by the SoftEther server's local bridge, which in itself is a virtual layer 2 device (again, no layer 3 routing).

If the SoftEther server is now receiving an ethernet packet from a connected VPN client that is addressed to the SoftEther server itself, the SoftEther local bridge should actually directly relay this packet to the SoftEther server eth0 interface itself. However, what it does it is dropping the packet onto the hypervisor virtual switch. Since this is a layer 2 and not a layer 3 device, it does (correctly) not reflect back that packet to where it came from (the SoftEther server's eth0 adapter).

So this seems to be a bug with the SoftEther server's local bridge. It should directly relay that packet to the SoftEther server's MAC address rather than dropping it onto the Hypervisor's virtual switch.

I'm no expert - is this analysis incorrect?

[OliverTejada]

Refer to this diagram to have a better understanding about how the localbridging works when done from within a virtual machine

I've seen cases where SoftEther's localbridge won't work properly even when configured on the Host Operating System (bridging directly to the physical NIC and onto the network segment). I really don't know where the problem is, but to me this looks like a link layer or ARP issue in some network switches, which kinda go crazy when they see two devices at the link layer using the same MAC address, and ethernet frames arrive unconditionally to either of them.

OR, it could be the physical NIC of the server, not capable of bridging properly, which is very unlikely but could be the reason why your localbridge is failing. Try mounting a different PCI/USB network card and try bridging with it.

[genesys]

Is the reason why promiscuous mode is required exactly to address this problem, because network packets must be reflected back on the same port so that connected vpn users can ping the vpn server or each other (because packets arriving at either the software or hardware NIC have the same port as source as well as target and usually switches do not reflect back packets on the same port?)

[genesys]

Looking at https://cloudbase.it/hyper-v-promiscuous-mode/ it seems that Hyper-V's "promiscuous" mode only allows a particular port to be EITHER source OR destination of the packet doubling. But if I understand correctly why promiscuous mode would be required, then I guess I would need to be able to set the same port (the one the softether server is connected through) as both source AND destination. Could that be?