Bridging and local access to manage server

[strikese]

Hi all, any help on this appreciated.

How do you configure bridging so that you can use the SoftEther management tool to configure the server WHILE you are connected remotely to the VPN as a client with local IP?

My setup:

I've installed SE on a local server behind my home router. The server has two connected interfaces, one ethernet, one wifi, both with different ip addresses. So:

Ethernet 192.168.0.100
Wifi 192.168.0.101
SoftEther listening port: 10000

I have port forwarding on my router, 10000 is forwarded to 192.168.1.100 (ethernet)
Softether bridging is set up using the ethernet interface.

So as of now, on another local windows machine on the network, I can use the server manager tool to configure the server using either 192.168.0.100 or 192.168.0.101. Both work.

Now I connect a windows laptop to the VPN through a network outside my home. I get served a local IP address 192.168.1.51. So now my remotely connected laptop is part of the local network and I should be able to manage the server using the Windows management tool.

Now I understand that due to Linux kernel restrictions I can't connect with the server management tool using 192.168.0.100 (ethernet) because it is being used for the bridge. So I try to connect 192.168.0.101 (wifi) which works fine when I'm on a computer physically connected locally. But when connected remotely through VPN it doesn't work. Similarly I can SSH to my server through 192.168.0.100 or 192.168.0.101 when on a physical local machine, but neither IPs work when connected through the VPN.

My expectation is that this should work. I don't like having the management interface open to the world with just password protection, it's not secure, so I want to use adminip.txt to restrict access only to local machines but I can't seem to access the server at all when connected through the VPN.

I have tried deleting the ethernet bridge and replacing it with the wifi bridge. I have tried having the ethernet and wifi bridges active at the same time. Neither works, SoftEther won't serve a local IP to me when connecting as a client unless the only operational bridge is the ethernet bridge. I have tried forwarding the port 10000 to the wifi IP, then I can't connect the client at all.

I don't want to use SecureNat due to the performance hit.

Anyone have any genius suggestions as to what I'm doing wrong here?

Thanks!

PS all of this could be avoided if we could have certificate authentication for the manager instead of plain password....

[maltyx]

you wrote that when connected to VPN session you have an IP like 192.168.1.51
and your network Scope is 192.168.0.100
so there should be NAT or routing in between your vpn client IP and your internal network to get the VPN server management interface? or its just misspelling?

[strikese]

Sorry yes it was a typo

Local served as VPN client is like 192.168.0.51 not 192.168.1.51

Thanks

[Mada]

This is an issue for me to!

There are a number of threads on the subject. No clear conclusion.

Creating a TAP device if running softether on linux has been suggested. That could then be bridged to a virtual hub. I have not tried this yet.

In the mean time, I am assigning a static ip address to the local bridge NIC (under windows). I think the manual says "do not do that". I am also facing a lot of routing issues trying to access the private network from the server running SE.

[strikese]

I've tried the TAP approach and it didn't work for me.

It's very puzzling why this doesn't work. I have two physical adapters on the server so while one acts as the bridge you should be able to access the server manager through the IP of the second adapter. But it just doesn't work.

Actually the best solution would be that management access login be controlled by certificate instead of password and be able to disable password access. Then you could manage the virtual hub remotely directly without having to leave insecure password access open to the net. Like in SSH where you can configure it to force certificate login, control the amount of time allowed for login, set the number of incorrect login attempts before closing access, etc.

This is really an essential feature that needs to be implemented in SoftEther in my opinion. What's the point of having secure, controllable certificate-based client access when the management access can only be password-based with no way to control the number and method of login attempts?

The only solution right now I can find is to use the adminip.txt approach to block access to all IPs, then modify the file to allow the IP address you happen to be on when you need to access management functions, do what you have to do, then remove the allowed IP address when you're finished. During that period the whole system is exposed to a determined password cracker.

Not an ideal solution by any means and certificate access to manage the server is a major missing piece of an otherwise amazing package.

[Mada]

Good point about certificate authentication for management!

If you are not using SecureNAT, how do you translate addresses? Is it done bye other software on the server running SE or a different machine?

The problem I have to contact the server running SE or talking to local addresses from that same server must be related to routing right? Sometimes it works, sometimes not. Attaching a schematic of my setup.

[Mada]

Is the route I paint in red impossible?

The virtual hub:s are cascaded.

[maltyx]

Hi, Mada. I don't understand what kind of connection you are trying to establish between your 2 sites?
Layer 2 bridge or Routed connection (L3)?

1. If I reference to you last sketch, I can assume that looks like L2 scenario .. but if so - you do not need any routing in this case to be connected between 2 sites.
2. In case you DO want to do routing between sites - first of all define different IP ranges for each site, and create at your primary site 2 virtual hubs: one for primary site local site and the second for remote site connections. And then add routes for each IP subnet on your VPN server at the primary site ..

[Mada]

Hi, it is a L2 bridge. Same subnet on both sites. But I have also tried to solve the problem using L3.

I think that it is a fundamental problem of talking to an interface through the interface itself and not a routing problem.

I.e. can a interface listen and receive at the same time it is transmitting? Is it really duplex in that sense?

I can only find references to situations where two (and only two) interfaces can exchange packages simultaneously (duplex). However, is is unclear to me if this would work with one interface only.

If we set up a virtual interface and do a local bridge to that interface, how would SoftEther handel it? Would we circumvent the local physical interface?

[maltyx]

Both NIC2s on your 2 locations are part of the same ethernet broadcast domain (in case of L2 bridge scenario), so on those NICs SE manual does not advise to configure any TCP/IP settings (Local bridged to Virtual hubs) and this really matter in case you are going to make a "real bridge" connection (include VLANs tagged packets)

But, in general it should work and with IP configured on the , but less robust ...
Just make sure on both sides IPs are unique and have the same mask .. and check the cascaded connection status at your main site

[Mada]

Yes, maltyx, but will Softether realize that the packet is destined to the computer itself? And then somehow insert it directly into the network stack? Without transmission?

If not, it will tell the NIC to transmit it with the same NIC:s mac address as destination? Will the NIC realize that the packet is for itself? If not will it be able to "hear" its own transmission while transmitting? I doubt that.

[Mada]

I think this might re related to a problem with switching?

If we send the packet to the switch, it seems we will never get it back:

"A frame is never forwarded out the same port it was received from, so the only way a frame would be sent to all connected ports is if it originated from somewhere other than a port, and that means the switch itself. "

[thisjun]

I think outgoing packets are sent via ethernet NIC.
Please try to unassign IP address of ethernet NIC.