x-post SoftEther VPN suddenly acting up in a Virtual Sandbox

[LaxSlash]

From Reddit: https://www.reddit.com/r/networking/com ... a_virtual/

I have a sandbox infrastructure setup using a bunch of virtual machines to prototype a possible infrastructure.
Things were working great until today, when I suddenly hit a weird issue with SoftEther.
The way I have it setup currently is I have three machines: One is for the VPN host, one is for a Sentora server, and one is the API Development server. The VPN host is running Ubuntu 16.04, the others are on CentOS 7.
All VMs are hooked into a VirtualBox Internal network - protonet. This network uses the subnet 10.1.0.255. The VPN server connects outside via a Bridged adapter, the others go off of a NAT connection.
The hub itself is setup to be using a bridge connection on the VPN host to the protonet internal network, so that connecting clients can access those machines. The SecureNAT DHCP server is setup on a 10.1.1.255 subnet, with 10.1.1.1 as the gateway, and the Sentora server at 10.1.0.4 setup as the DNS server.
Today, I am unable to connect to anything on protonet through the VPN connections. It either times out, or gets connection refused.
Trying to ping the VPN client (10.1.1.2) works from the Sentora and API Dev servers from within the protonet network. However, what's intersting is that the VPN host vm can not ping the VPN client, and the VPN client can not ping any of the vms within protonet.
I've deleted and recreated the HUB multiple times, tried a different DHCP subnet for SecureNAT, tried removing the bridge to see if I could get it to at least ping the client (it didn't), tried rebooting everything multiple times, verified that the firewall on the vpn host is off, among numerous other troubleshooting steps.
Does anyone have any ideas for what may be causing this? What other information is needed?
E: Got an update. When restarting the HUB, there appears to be a window in which the client can ping other machines behind the 'protonet' network, before starting to time out. I haven't timed it exactly, but it seems to be around 30 seconds. After this, the VPN Client refuses to talk to anything. What's odd is that the virtual servers will not ping the client back, nor will the VPN Host... even during that window. The VPN Client machince can now continuosly ping the VPN Host, though. Pushing the virtual hub offline and then back online brings back connectivity in the same fashion. Here are my settings for everything (I realized I forgot to mention them all earlier):
VPN Host: enp0s17: (Bridged Adapter) Gateway: 192.168.1.1 Subnet Mask: 255.255.255.0 IP Address: 192.168.1.2
enp0s3: (protonet) Gateway: 10.1.0.1 DNS Server: 10.1.0.4 Subnet Mask: 255.255.255.0 IP Address: 10.1.0.2
protonet Servers: Gateway: 10.1.0.1 DNS Server: 10.1.0.4 Subnet Mask: 255.255.255.0 IP Addresses: 10.1.0.x
VPN VHub SecureNAT Settings: VHost IP: 10.1.1.1 VHost Subnet Mask: 255.255.255.0 DHCP Range: 10.1.1.2 - 10.1.1.255 DHCP Subnet Mask: 255.255.255.0 Client Gateway: 10.1.1.1 Client DNS Server: 10.1.0.4
Local Bridge Settings: Virtual Hub Name: [The matching hub name] Network Adapter or Tap Device Name: enp0s8 Status: Operating
Promiscuous Mode is set to "Allow All" on all of the VMs.
Worth noting, I disabled/"unplugged" the NAT adapters from the server VMs for now.

[LaxSlash]

Bump.

https://superuser.com/questions/1204606 ... e-behavior

[thisjun]

I think tap device got the IP address from virtual DHCP.
If so, packets may loop because the default gateway of the host of the VPN server points itself.