Page 1 of 1

LAN-to-LAN again // L3 SWITCH PROBLEM SOLVED FOREVER !

Posted: Sat Feb 13, 2021 2:39 pm
by sky59
recently a lot question were raised about LAN-2-LAN connection L3 layer
I tested it and found there seems to be some problem?

I have running server sitting on public IP with two hubs: VPN and VPC

Everything is working excellent when I and many other people in company
use both hubs for L2 layer connections, always within the same subnet
never mixing two separate subnets together

VPN has got cascade connection to Ubuntu PC that provides BRIDGE to
company local net 10.52.254.0/24 with many devices on it

so, Ubuntu has got 2 NICs: one for internet connection to connect to VPN hub
on server, the second is local bridge to 10.52.254.0

When I need to connect to work from home I use SoftEther Windows Client, so I connect
to the VPN hub on server and everything works excellent! I even get IP from DHCP from
10.52.254.0 subnet at work, client uses virtual NIC inside PC for this connection

For next test steps I do not connect to VPN any more.

So far VPC hub is not used it is only for special circumstancies, so I did following:

As there is no DHCP at work on VPC hub subnet and no devices at all I made
IP address for my SoftEther Windows Client and its virtual NIC as follows:
IP: 10.100.100.5
mask: 255.255.255.0
gw: 10.100.100.102 - this will be address for Virtual L3 switch at server


Now I enable Virtual L3 switch on server:

Let us call it SW. It has got two Virtual Interfaces:
10.100.100.102 255.255.255.0 VPC
10. 52.254.102 255.255.255.0 VPN

The adresses 102 are not used in any way in both subnets. They serve now for SW.
Virtual L3 Switch started, no errors reported.

Documentation reads: "When multiple virtual interfaces that respectively belong to
a different IP network of a different Virtual Hub are defined,IP routing will be
automatically performed between these interfaces."

(so I did not write any Routing Table lines, though, I also played with all possible
and impossible lines..... no change)

Now I connected from my PC using aboveconfigured Windows Client to the VPC hub.

So after connection I could ping my own virtual interface: 10.100.100.5 in less than 1ms
I could also ping Virtual Interface 10.100.100.102 in tens of ms as it is on remote server.

What is good and I also expected it I could also ping another Virtual Interface belonging to VPN:

to be 100% sure I used this command (as still another NIC on PC is running for internet connection):

ping 10.52.254.102 -S 10.100.100.5 response also in a few of tens of ms

BUT BUT BUT:
I can not ping any other device in network 10.52.254.0 !?
Just for case ping is not supported I also tried to connect SSH to some devices - no success.

Is there something special that all people including me overlooked? Or is there really a problem
with this L3 switch?
Why packages for VPN network do not leave SW but only go maximal to its interface 10.52.254.102?


EDIT: I spent another hours fighting with L3 switch and it seems there is a real problem, or documentation
is not sufficient.
I have found many many questions about this since 2015 - so I am not the only one with problem.
Though I found also one solution: one guy claimed that after rebooting server it started suddenly to work
but did not helped me.

I think I described very well my configuration that is also simplest possible. Would be nice if someone
from Softhether team explained where is the problem.

Thank you in advance

Re: LAN-to-LAN again // I give up // L3 virtual switch problem

Posted: Fri Feb 19, 2021 9:21 am
by sky59
I wasted more time to try it without success.
There is a possibility to set up gateway also in Siemens PLC, so I set it up.

My configuration is so basic and so clear but it still does not work, see attached picture.

I can only ping virtual interface 10.52.254.4 but nothing more.

Is anybody able to find where I make error or should I continue to live with the feeling that it is not really working
and if it works for someone it is mostly a good luck only??

If I connect with PC client directly to VPN then I can ping Siemens PLC without problem.

IMG-20210219-WA0000.jpg

Re: LAN-to-LAN again // I give up // L3 virtual switch problem

Posted: Sat Feb 20, 2021 12:19 am
by solo
Try this on the Pi:

1) ensure/set: net.ipv4.ip_forward = 1

2) set default iptables policies:
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P FORWARD ACCEPT
(and remove restrictions, if any)

Reboot and start to ping PLC from your Win PC. If still nothing, on the Pi run:
tcpdump -nn net 10.52.254 while still pinging.
Do you see ICMP echo requests only, request/reply sequences, or nothing at all?

Finally, change PLC GW from 10.52.254.4 to 10.52.254.102 and re-test it.

Re: LAN-to-LAN again // I give up // L3 virtual switch problem

Posted: Sat Feb 20, 2021 8:05 am
by sky59
Thanx,
Iptable policies everything is enabled already.
Regarding ip forward I am bit surprised, is not it purely softether issue
in this case?
Problem is, i can not reboot because system is in locked sd card, no change possible, only temporary changes possible without reboot. After rebbot everything is gone :)
But i will ser what i can do regarding ip forward... but would se even work without it?
I run it on openwrt system and i believe it should be ok as it is exactly for networking

Re: LAN-to-LAN again // I give up // L3 virtual switch problem

Posted: Sat Feb 20, 2021 8:13 am
by solo
sky59 wrote:
Sat Feb 20, 2021 8:05 am
Regarding ip forward I am bit surprised, is not it purely softether issue in this case?
Yes, but I included it for baseline consistency. Anyway...
solo wrote:
Sat Feb 20, 2021 12:19 am
change PLC GW from 10.52.254.4 to 10.52.254.102 and re-test it.
That's it.

I have re-created your setup with two minor differences:
  • for the Pi I used Linux Mint SE server
  • for Ubuntu SE bridge I used Win SE bridge
  • my VPC client is also Win SE
With the 10.52.254.102 GW, bridged LAN devices reply to VPC client's pings.

Case closed :-)

Re: LAN-to-LAN again // I give up // L3 virtual switch problem

Posted: Sat Feb 20, 2021 1:45 pm
by sky59
Solo, thank you VERY much for testing it because I already started to think i am crazy.

Sorry asking again, is it a difference in address 4 or 102?
Yes, original text i wrote 102 but then i used for test 4 and adapted everything around, you might try also 4?

At least by your test i know there is somewhere hidden dog in my configuration. I will then continue to work on it.

First step i connect directly on ubuntu local bridge just one pc because i am not sure about siemens and whole local network

Do you like my picture? :) I like it very much and all people should always provide similar sketches, should not they?

Re: LAN-to-LAN again // I give up // L3 virtual switch problem

Posted: Sun Feb 21, 2021 12:26 am
by solo
sky59 wrote:
Sat Feb 20, 2021 1:45 pm
...is it a difference in address 4 or 102? Yes, original text i wrote 102 but then i used for test 4 and adapted everything around, you might try also 4?
Indeed no difference as long as L3=GW. Your text has differed from the picture and I thought that you misconfigured it. So the case is not closed after all ;-)

Please do these tests:
1. from the Ubuntu PC: ping 10.100.100.4 (or 102, works for me)
2. from a PC on the PLC LAN: ping 10.100.100.4 (or 102, works for me)
Do you like my picture? :) I like it very much and all people should always provide similar sketches, should not they?
Sure!

Re: LAN-to-LAN again // progress // L3 virtual switch

Posted: Sun Feb 21, 2021 4:40 pm
by sky59
solo,
it is Sunday today, so I took my bike and went to company to make changes to perform the test.

So, referring to the picture, I disconnected whole network from NIC Eth0 on Ubuntu (10.52.254.0)
and connected to Ubuntu only my company PC with this static setting:
IP: 10.52.254.127
M: 255.255.255.0
GW: 10.52.254.4

I performed following tests (what is not here I got also idea later sitting already at home :)

***** Tests at company (Ubuntu, company PC, server Orangi Pi Zero few meters away) ******

- from my company PC connected on Ubuntu local bridge I could ping 10.52.254.4 in 3ms
- ................................................................ 10.100.100.4 in 3ms
this behaviour is symetrical like below, see >>>>> (reaching virtual interfaces is always possible)


Now at home I realized Ubuntu has got also static IP 10.52.254.80 on local bridge NIC though
it is not needed (I need to check if there is also some gateway set up)

- so from terminal window on Ubuntu I could NOT ping 10.52.254.4 as it replayed Host Unreachable
from 10.52.254.80, but it seems to me correct, as tunnel is completely separated and Ubuntu
does not know about GW 10.52.254.4 ? And as it is the same subnet it went correctly to use
local interface 10.52.254.80 ? or here is the hidden dog??

****** Now tests at home from PC with SoftEther Client: ****************

- if I connected to VPN hub I could of course ping 10.52.254.127 company PC as it is same subnet
and L2 layer is sufficient to work

>>>>>>>>>>
- when I connect to VPC (as on picture) I can ping 10.100.100.4 in 50ms (over internet outside back to company)
- ................................................ 10.52.254.4 in 50ms (also both virtual interfaces reachable)

- when I try to ping 10.52.254.127 company PC "request timed out"

Unless you have already idea where the problem is, I will try next week to leave my company PC during weekend
as another Windows SE Client connected to VPN and try to ping it from home Windows SE Client VPC. Then I can eliminate problem
with Orange PI Zero server, or confirm problem :)

Re: LAN-to-LAN again // progress // L3 virtual switch

Posted: Sun Feb 21, 2021 11:02 pm
by solo
sky59 wrote:
Sun Feb 21, 2021 4:40 pm
- so from terminal window on Ubuntu I could NOT ping 10.52.254.4 as it replayed Host Unreachable
from 10.52.254.80, but it seems to me correct, as tunnel is completely separated and Ubuntu
does not know about GW 10.52.254.4 ?
You are absolutely right. Initially I connected to Pi-VPN as a client for ping tests which worked. In bridge mode it does not. Sorry about the confusion.
Unless you have already idea where the problem is, I will try next week to leave my company PC during weekend
as another Windows SE Client connected to VPN and try to ping it from home Windows SE Client VPC.
I think I do. My assumptions about PLC LAN PC tests:
- you connected a laptop with a wifi interface
- you entered GW 10.52.254.4 in the LAN interface

Now run: netstat -r on the laptop and look at default 0.0.0.0 gateways (post it here). I bet that the wifi one has lower metric and pings from the 10.100.100.x subnet will try to reply via this dead end route.

Solutions:
1. lower the LAN's metric below the wifi interface
or
2. on the Pi-VPN:
a. enable SecureNAT
b. disable Virtual NAT
c. preset all to the 10.52.254.x subnet
d. set Default Gateway to 10.52.254.4
e. on the laptop use DHCP for the LAN card
f. now when you connect, GW 10.52.254.4 will be automatically delivered as the only default route with a strong "2" metric

Mystery solved? :-)

-Edit-

I forgot to mention solution #3, on the laptop: route -p add 10.100.100.0 mask 255.255.255.0 10.52.254.4 metric 1

Re: LAN-to-LAN again // progress // L3 virtual switch

Posted: Mon Feb 22, 2021 5:43 pm
by sky59
solo,

I performed test just now with two PCs as Windows SE Clients.

Configuration as on picture above just removed Ubuntu and local LAN with PLC Siemens.

Instead of this I connected another PC with SE Client as on the left side of the picture. All with correct IPs and GWs....

one connected to VPN another to VPC with L3 switch configured on server

Not working, so it seems it is OpenWrt "issue", I have seen somebody else has also server on OpenWrt and the same problems.

I already checked and IP4 forwarding is active on server (Orange Pi Zero + OpenWrt).

I can not do it from home but tomorrow I will make screen shots how firewall is set up on OpenWrt (no restrictions at all....)

No idea what to check on OpenWrt SE server......

I did not add any route to Windows but for test I use :
ping 10.52.254.127 -S 10.100.100.10 and similar from other side, so no WIFI interraction
or
ping 10.100.100.10 -S 10.52.254.127

/of course, I can ping both virtual interfaces from both sides/

Re: LAN-to-LAN again // progress // L3 virtual switch

Posted: Mon Feb 22, 2021 10:26 pm
by solo
So it looks like an OpenWrt issue. Are you using it to get around internet connectivity limitations at the PLC site? Like no port forwarding or dynamic IP?

You can use the SE VPN Azure option instead, it seems reliable but a bit slow in my tests. You could get rid of the OpenWrt unit and reconfigure the Ubuntu PC for SE server function with the same VPC/VPN-bridge hubs + VPN Azure.

--edit--

or keep OpenWrt without L3 switch and reconfigure the Ubuntu PC for SE server function with corresponding VPC-L3-VPN-bridge hubs + L2 cascades to OpenWrt...
plc2.png

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Tue Feb 23, 2021 7:41 am
by sky59
solo,

thank you for helping on this issue. In reality I do not need it but I was so curious that I reproduced it after many people here have problems with it. And for the moment it seems it is always the same reason, we miss something on server?

I use OrangePi Server on public IP because VPN is network at work so people can now work remotely from home with PLCs even with shared IPs.

The VPC is not used, just in cases when we need to connect to the PLCs around the world to our customers. Much cheaper than to travel :)
And SE is the only (?) vpn which supports Layer2 because Siemens software is using this layer as well, specially to identify PLC when not configured yet.
After configured then it uses L3 communication. We ahve in each device Ubuntu and after starting manually vpnbridge remotely over Anydesk/teamviewer I can then reach PLC even on other side of the world. It is reliable!

So both hubs VPN and VPC are by default separated because I do not want to mix two networks and L2 is absolutely necessary.

Just for curiosity I attach OpenWrt setting to have a look if something is missing.

I will try to raise the question also on OpwenWrt forum. If you search "openwrt" here you can find another people with openwrt having the same problem.

At this moment I postpone working on it but when I have a time and Ideas I will reply to this thread.
FW.png
FW.png

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Tue Feb 23, 2021 7:55 am
by sky59
While my first today's post is waiting for approval I found one user with the same problem. Look into this thread and user destinia:
(so this should be second post after the fisrt)

https://www.vpnusers.com/viewtopic.php? ... wrt#p89342

If I understand corret what he writes, he confirms there is a problem with L3 switch (?)

But then he made a test with L2 switch claiming it works then, but I do not understand what exactly he did?

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Tue Feb 23, 2021 9:48 am
by solo
sky59 wrote:
Tue Feb 23, 2021 7:55 am
But then he made a test with L2 switch claiming it works then, but I do not understand what exactly he did?
He removed L3 and made local L2 this way:
you can create a link between virtual Hubs on the same computer if necessary. It is called "Cascade Connection" or simply "Cascade" . Cascade is a popular technical term of Ethernet. If a cascade connection is established, then every Ethernet segment on each Virtual Hub is now united as a single segment.

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Tue Feb 23, 2021 12:21 pm
by sky59
Thanx! At the moment I have no oportunity to try it but I will do later.
I will place result here.

But then I have to add somewhere routes? Because for L3 it is automatic as they say as it knows all virtual interfaces.

For L2 there will not be any virtual interface so I need to add somewhere those routes (?)

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Tue Feb 23, 2021 4:37 pm
by sky59
I tried to cascade VPN to VPC over local interface IP 10.81.100.120 - this is the IP address of OrangePi Zero behind router which forwards ports from public IP 62.xx.xx.xx to the Orange Pi zero server

Of course it works with no doubt, but only in the same subnet, I can not merge two different subnets, for this is here L3. Correct?

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Wed Feb 24, 2021 3:02 am
by solo
The OpenWrt L3 issue may be unfixable. Please try L3 switch on a test PC with a popular Linux distro, then consider the options I mentioned before.
You can use the SE VPN Azure option instead, it seems reliable but a bit slow in my tests. You could get rid of the OpenWrt unit and reconfigure the Ubuntu PC for SE server function with the same VPC/[L3-switch]/VPN-bridge hubs + VPN Azure.

...or keep OpenWrt without L3 switch and reconfigure the Ubuntu PC for SE server function with corresponding VPC-L3-VPN-bridge hubs + L2 cascades to OpenWrt
As for
And SE is the only (?) vpn which supports Layer2
Before SE I was using OpenVPN L2 (tap-interface) for several LAN+remote SIP phones.
For L3 deployments I love WireGuard VPN but SoftEther beats them all :-)

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Thu Feb 25, 2021 11:37 am
by solo
sky59 wrote:
Tue Feb 23, 2021 7:41 am
So both hubs VPN and VPC are by default separated because I do not want to mix two networks and L2 is absolutely necessary. Just for curiosity I attach OpenWrt setting to have a look if something is missing. I will try to raise the question also on OpwenWrt forum. If you search "openwrt" here you can find another people with openwrt having the same problem.
Sky59, I have a useless, little GL-MT300N-V2 router with rather crippled OEM firmware, so I decided to flash OpenWrt on it and verify the problem. Details:
  • openwrt-19.07.7-ramips-mt76x8-gl-mt300n-v2-squashfs-sysupgrade.bin
  • setup with WiFi in AP mode + WiFi client
  • all defaults, no changes to firewall/forwarding/etc.
SoftEther packages:
- softethervpn-base Version: 4.29-9680-3
- softethervpn-server Version: 4.29-9680-3

PuTTY shows all up and running:

Code: Select all

BusyBox v1.30.1 () built-in shell (ash)
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 19.07.7, r11306-c4a6851c72
 -----------------------------------------------------
 
root@OpenWrt:~# netstat -tapn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      947/uhttpd
tcp        0      0 0.0.0.0:5555            0.0.0.0:*               LISTEN      4384/vpnserver
tcp        0      0 192.168.86.93:53        0.0.0.0:*               LISTEN      1408/dnsmasq
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1408/dnsmasq
tcp        0      0 192.168.11.1:53         0.0.0.0:*               LISTEN      1408/dnsmasq
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      798/dropbear
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      4384/vpnserver
tcp        0      0 0.0.0.0:992             0.0.0.0:*               LISTEN      4384/vpnserver
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      4384/vpnserver
tcp        0    288 192.168.11.1:22         192.168.11.172:53532    ESTABLISHED 7885/dropbear
tcp        0      0 :::80                   :::*                    LISTEN      947/uhttpd
tcp        0      0 :::5555                 :::*                    LISTEN      4384/vpnserver
tcp        0      0 fe80::e495:6eff:fe47:c130:53 :::*                    LISTEN      1408/dnsmasq
tcp        0      0 fe80::e695:6eff:fe47:c130:53 :::*                    LISTEN      1408/dnsmasq
tcp        0      0 ::1:53                  :::*                    LISTEN      1408/dnsmasq
tcp        0      0 fe80::e695:6eff:fe47:c130:53 :::*                    LISTEN      1408/dnsmasq
tcp        0      0 fd8c:376a:a18d::1:53    :::*                    LISTEN      1408/dnsmasq
tcp        0      0 fe80::e695:6eff:fe47:c130:53 :::*                    LISTEN      1408/dnsmasq
tcp        0      0 fe80::e695:6eff:fe47:c130:53 :::*                    LISTEN      1408/dnsmasq
tcp        0      0 :::22                   :::*                    LISTEN      798/dropbear
tcp        0      0 :::443                  :::*                    LISTEN      4384/vpnserver
tcp        0      0 :::992                  :::*                    LISTEN      4384/vpnserver
tcp        0      0 :::1194                 :::*                    LISTEN      4384/vpnserver

root@OpenWrt:~# cat /proc/cpuinfo
system type             : MediaTek MT7628AN ver:1 eco:2
machine                 : GL-MT300N-V2
cpu model               : MIPS 24KEc V5.5
I used the VPN Azure option and created two hubs with SecureNAT but without VirtualNAT, plus Layer 3 switch:

vpn.png
vpc.png
vpnc.png
Next connected two PCs via VPN Azure over WiFi and did the following tests:

Code: Select all

PC connected to VPN
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   192.168.30.254    192.168.30.10      2
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306

Pinging 192.168.130.254 with 32 bytes of data:
Reply from 192.168.130.254: bytes=32 time=820ms TTL=255
Reply from 192.168.130.254: bytes=32 time=936ms TTL=255
Reply from 192.168.130.254: bytes=32 time=1037ms TTL=255
Reply from 192.168.130.254: bytes=32 time=593ms TTL=255

Pinging 192.168.130.10 with 32 bytes of data:
Reply from 192.168.130.10: bytes=32 time=2216ms TTL=127
Reply from 192.168.130.10: bytes=32 time=1460ms TTL=127
Reply from 192.168.130.10: bytes=32 time=1693ms TTL=127
Reply from 192.168.130.10: bytes=32 time=2034ms TTL=127


PC connected to VPC
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0  192.168.130.254  192.168.130.10       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

Pinging 192.168.30.254 with 32 bytes of data:
Reply from 192.168.30.254: bytes=32 time=779ms TTL=255
Reply from 192.168.30.254: bytes=32 time=755ms TTL=255
Reply from 192.168.30.254: bytes=32 time=1392ms TTL=255
Reply from 192.168.30.254: bytes=32 time=1313ms TTL=255

Pinging 192.168.30.10 with 32 bytes of data:
Reply from 192.168.30.10: bytes=32 time=2386ms TTL=127
Reply from 192.168.30.10: bytes=32 time=1730ms TTL=127
Reply from 192.168.30.10: bytes=32 time=1959ms TTL=127
Reply from 192.168.30.10: bytes=32 time=2030ms TTL=127
As you can see SoftEther Layer 3 switch on OpenWrt works OK.
Perhaps you use old firmware or packages?
Again, it was a brand new OpenWrt installation with only default settings.
Let me know, if you need any OpenWrt or SoftEther logs or other tests.

Cheers

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Thu Feb 25, 2021 6:46 pm
by sky59
NO WAY ! :(

Today I prepared newest Raspbian with 4.29 softether (before I had 4.25)

Behaves EXACTLY the same as with OpenWrt - sh*t

I noticed these differences between us:
---------------------------------------

How do you set up IP of virtual NIC interfaces in PC? I set it up under windows in network interfaces
with static IPs - you use DHCP from SecureNAT?

Why you set up SecuteNAT? I have not seen it anywhere in documentation.

Can you try static adresses as me, in attachment?

can you ping this: because what you uploaded here for me it is unclear:
I do not know what are PIs of your virtual NIC interfaces in PCs

ping IP_remote_PC_virtual_interface -S IP_virtual_interface_local_PC

both directions?

MY DETAILES:
pc1:
virtual NIC 10.100.100.10/24 setup static using windows network interfaces
GW 10.100.100.1

pc2:
virtual NIC 10.52.254.10/24 setup static using windows network interfaces
GW 10.52.254.1


L3 SW: 10.52.254.1/24 in server
10.100.100.1/24

I tried also to add SecureNat: 10.100.100.100/24
10.52.254.100/24

I have no idea what is this for?
is it supposed to make virtual wire between 10.100.100.100 ------- 10.100.100.1
and 10.52.254.100----------10.52.254.1 ???????????????????????????????????

would be nice if you could try ecxactly my settings as I have another PC and server at work and now I am at home




Untitled.png
Untitled1.png

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Thu Feb 25, 2021 11:21 pm
by solo
sky59 wrote:
Thu Feb 25, 2021 6:46 pm
Why you set up SecuteNAT? I have not seen it anywhere in documentation.
...
would be nice if you could try ecxactly my settings as I have another PC and server at work and now I am at home
SecureNAT-DHCP is very convenient, that's all. Anyway I preset my net exactly as you asked, and with SecureNAT completely disabled.

Code: Select all

	declare VirtualLayer3SwitchList
	{
		declare VPNC
		{
			bool Active true

			declare InterfaceList
			{
				declare Interface0
				{
					string HubName VPC
					string IpAddress 10.100.100.1
					string SubnetMask 255.255.255.0
				}
				declare Interface1
				{
					string HubName VPN
					string IpAddress 10.52.254.1
					string SubnetMask 255.255.255.0
				}
			}
			declare RoutingTable
			{
			}
		}
	}


VPN PC
------

Unknown adapter VPN - VPN Client:
   IPv4 Address. . . . . . . . . . . : 10.52.254.10
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.52.254.1


Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.52.254.1     10.52.254.10      2
      10.52.254.0    255.255.255.0         On-link      10.52.254.10    257
     10.52.254.10  255.255.255.255         On-link      10.52.254.10    257
    10.52.254.255  255.255.255.255         On-link      10.52.254.10    257


Pinging 10.100.100.1 with 32 bytes of data:
Reply from 10.100.100.1: bytes=32 time=458ms TTL=255
Reply from 10.100.100.1: bytes=32 time=478ms TTL=255
Reply from 10.100.100.1: bytes=32 time=1101ms TTL=255
Reply from 10.100.100.1: bytes=32 time=490ms TTL=255


Pinging 10.100.100.10 with 32 bytes of data:
Reply from 10.100.100.10: bytes=32 time=1258ms TTL=127
Reply from 10.100.100.10: bytes=32 time=1110ms TTL=127
Reply from 10.100.100.10: bytes=32 time=1869ms TTL=127
Reply from 10.100.100.10: bytes=32 time=2046ms TTL=127



VPC PC
------

Ethernet adapter VPN - VPN Client:
        IP Address. . . . . . . . . . . . : 10.100.100.10
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 10.100.100.1


Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     10.100.100.1   10.100.100.10       1
     10.100.100.0    255.255.255.0    10.100.100.10   10.100.100.10       1
    10.100.100.10  255.255.255.255        127.0.0.1       127.0.0.1       1
   10.255.255.255  255.255.255.255    10.100.100.10   10.100.100.10       1


Pinging 10.52.254.1 with 32 bytes of data:
Reply from 10.52.254.1: bytes=32 time=1143ms TTL=255
Reply from 10.52.254.1: bytes=32 time=1802ms TTL=255
Reply from 10.52.254.1: bytes=32 time=536ms TTL=255
Reply from 10.52.254.1: bytes=32 time=1972ms TTL=255


Pinging 10.52.254.10 with 32 bytes of data:
Reply from 10.52.254.10: bytes=32 time=2265ms TTL=127
Reply from 10.52.254.10: bytes=32 time=2048ms TTL=127
Reply from 10.52.254.10: bytes=32 time=2045ms TTL=127
Reply from 10.52.254.10: bytes=32 time=1945ms TTL=127

It just works. At the beginning of this thread I did ask for your routing and net metrics, and still think this is the root of your connectivity problem.

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Fri Feb 26, 2021 6:53 am
by sky59
OK, it was not my reluctance, I only thought it is too much complicated but it must/should work .....
So here is required information:

- fresh new server Raspbian is sitting at work's network on 10.81.100.150

- VPN PC is also at work and connects to 10.81.100.150 as it is connected to the same network

- VPC PC at home uses wifi to go to internet, then I use company vpn ZyXel to go to network 10.81.100.0
so my home PC connects also directly to 10.81.100.150

here is my configuration file for server:
vpn_server.c

here is the information you required:
New Text Document.txt
I could perform tests only from one side from home, but I am sure it would be the same also from work as in the past

I did configured also Azure for server, but at works network I can not use it as I get ports forwarded from public IP xx.xx.xx.108
but if I ask "whatis my ip" in browser it reports xx.xx.xx.107, we have more public addresses and I have no idea what they did

next, last test will be, I take server home, I connect over WiFi over Azure and if it does not work also then then the result is for me
Layer3 switch does not work, or works only in very very specific conditions which are not described anyhow in documentation

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Sat Feb 27, 2021 7:40 am
by solo
sky59 wrote:
Fri Feb 26, 2021 6:53 am
here is the information you required:
...
Layer3 switch does not work, or works only in very very specific conditions which are not described anyhow in documentation
Thank you for the data, it looks OK. So the working theory is that OpenWrt's Pi build is flawed. Time for plan B :-)

For net diagnostics we pinged to/from both sides of the L3 switch but in reality only VPC needs to ping/access the PLC LAN from a different subnet, correct? If so, here is a very simple, quick, net topology change to accomplish it without L3 switch ...
.
no-L3.png
.
SoftEther is a truly remarkable VPN. While I am not converting my existing VPNs to SE, all future projects will be based on it.

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Sat Feb 27, 2021 5:19 pm
by sky59
solo, thanx for the effort...

I do not need it I only try to find where the problem is as other people experience

So I brought Raspberry fresh installation home, connected to the mobile phone tethering wifi and Azure DOES NOT WORK !
In server manager it says server is connected to Azure, though.

The PC Windows 10 SE Client can not connect over address vpn761015089.vpnazure.net !?!?!?!

As I connect both server and PC to the same wifi I can connect to the server over local address 192.168.43.128 (Android tether) but not
over vpn761015089.vpnazure.net

I created HUBtest1 (also user, password) on the server. I leave it running, can you try to connect to it? DHCP enabled

to be sure that it is alive you can ping:

Pinging vpn761015089.vpnazure.net [130.158.6.124] with 32 bytes of data:
Reply from 130.158.6.124: bytes=32 time=286ms TTL=47
Reply from 130.158.6.124: bytes=32 time=338ms TTL=47
Reply from 130.158.6.124: bytes=32 time=292ms TTL=47
Reply from 130.158.6.124: bytes=32 time=322ms TTL=47

I start to have suspicions about windows 10 !!! both machines I use are W10 (VPN, VPC)

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Sun Feb 28, 2021 1:54 am
by solo
I have tried but can not connect to your hub. SoftEther offers this great virtual test hub - I love it. Please try it instead of VPN Azure for now.

As for Windows 10 SE PCs, you could boot from USB a live Linux on them, no need for any installation.
Also none of the ping tests require the "-S" source argument as this is a very simple net environment.

Re: LAN-to-LAN again // OpenWrt problem ??

Posted: Sun Feb 28, 2021 9:30 am
by sky59
I am sure there is a problem with softether. I compiled it directly on Raspbian version 4.29. But also OpenWrt with compiled version from source 4.25
behaves exactly the way as Raspbian.

Though, SoftEther remains the best VPN I know. What we need is only to know its limits.

Recapitulation:
1- OpenWrt server 4.25 sitting behind router with public static IP 62.xx.xx.xx with portforwarding works perfect using Layer2 only (whole company is using it now as home office)
Connecting two different subnets over Layer3 using Virtual Switch does NOT work

2- OpenWrt server 4.25 with USB dongle wit SIM card with PUBLIC IP 92.248.37.55 (yes I have such a card - see attached photos, mobile phone IP is the same as result from Whatismyip.net) works perfect Layer2, no more energy to try Layer3

3- Raspbian with 4.29 enabled Azure, Internet connection over wifi tethering Huawei mobile with common SIM card (no public IP) , not even possible to connect to it over Azure.net

4- Raspbian with 4.29 enabled Azure, Internet connection over wifi tethering old mobile with SIM card public IP , not even possible to connect to it over Azure.net

5- points 3 and 4: possible to connect to the server over locat tethering Android address 192.168.43.182, so I could even see that server reports that Azure is connected - see attached screenshot

So for me, as contemporary internet providers are trying to get as much as possible clients on internet they devise new ways how to do it, so it seems they play a lot with special setting and routes, this affects not only Azure not working but I am sure it affects also Layer3 connecting subnets together as it needs correct routes

RESULT: if you have problems like described above try to find first internet provider with legacy services
ip1.png
ip2.png
azure.png

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Sun Feb 28, 2021 11:33 am
by sky59
solo,

Could you give me your vpnxxxxxx.azure.net at least to try if I can connect to it with W10 client?

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Sun Feb 28, 2021 1:26 pm
by solo
sky59 wrote:
Sun Feb 28, 2021 11:33 am
solo,
Could you give me your vpnxxxxxx.azure.net at least to try if I can connect to it with W10 client?
I have something much better for your tests. I created L3 switch on my server with cascades to vpn.packetix.net and it goes through any firewalls or NATs. You can do a complete L3 ping test with your PCs. Needles to say, it works for me :-)
.
solo-net.png
.
Logs:

Code: Select all

vpn.packetix.net:443
hub: SOLO2
test/test


VPN NIC from DHCP

   IPv4 Address. . . . . . . . . . . : 192.168.30.10
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.30.254


Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   192.168.30.254    192.168.30.10      2
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306


ping 192.168.130.254

Pinging 192.168.130.254 with 32 bytes of data:
Reply from 192.168.130.254: bytes=32 time=422ms TTL=255
Reply from 192.168.130.254: bytes=32 time=409ms TTL=255
Reply from 192.168.130.254: bytes=32 time=410ms TTL=255
Reply from 192.168.130.254: bytes=32 time=409ms TTL=255


ping 192.168.130.10

Pinging 192.168.130.10 with 32 bytes of data:
Reply from 192.168.130.10: bytes=32 time=1311ms TTL=127
Reply from 192.168.130.10: bytes=32 time=1592ms TTL=127
Reply from 192.168.130.10: bytes=32 time=994ms TTL=127
Reply from 192.168.130.10: bytes=32 time=817ms TTL=127


---------------------------------------------------------------------------


vpn.packetix.net:443
hub: SOLO3
test/test


VPN NIC from DHCP

        IP Address. . . . . . . . . . . . : 192.168.130.10
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.130.254


Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0  192.168.130.254  192.168.130.10       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1


ping 192.168.30.254

Pinging 192.168.30.254 with 32 bytes of data:
Reply from 192.168.30.254: bytes=32 time=413ms TTL=255
Reply from 192.168.30.254: bytes=32 time=478ms TTL=255
Reply from 192.168.30.254: bytes=32 time=602ms TTL=255
Reply from 192.168.30.254: bytes=32 time=455ms TTL=255


ping 192.168.30.10

Pinging 192.168.30.10 with 32 bytes of data:
Reply from 192.168.30.10: bytes=32 time=1536ms TTL=127
Reply from 192.168.30.10: bytes=32 time=1061ms TTL=127
Reply from 192.168.30.10: bytes=32 time=1077ms TTL=127
Reply from 192.168.30.10: bytes=32 time=836ms TTL=127

Make sure to enable DHCP on VPN NICs!
Good luck.

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Sun Feb 28, 2021 5:11 pm
by sky59
OK, you probably deleted those SOLO2 and SOLO3 hubs...

I am not going to create something new as it is not of my interest. I believe you it works. But I am interested
in something that does not work and I would love to find exact reason. So far it seems it is true what I have already written.

I think these days the routes from IPS are so complicated that probably softether evaluates them in the wrong way.
The result is that Azure is not working as false route is established between clients.
It probably affects also Layer3 switching as it strongly depends on correct routes. For layer2 everything happens inside
common subnet so not that big problems with route table, I hope I am right.

Unfortunately creators of SoftEther do not read this forum. I would keep my server with Azure working during European nights
when in Japan there is already the day so they might try to find out where is the problem.

Anyway, for what I need VPN softether it works very well. I can access any PLC Siemens or any USB device all around the world.
I hope, those really need to merge different subnets might find my information useful. I confirm there IS a problem.

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Sun Feb 28, 2021 9:27 pm
by solo
sky59 wrote:
Sun Feb 28, 2021 5:11 pm
OK, you probably deleted those SOLO2 and SOLO3 hubs...
No, they are up and running and I invite other SoftEther forum users for a L3 test.

Again...
host: vpn.packetix.net
port: 443
hub: SOLO2 (and SOLO3)
user: test
password: test

Maybe better in pictures.
.
s2.png
s2s.png

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Mon Mar 01, 2021 7:42 am
by sky59
Yes, it is possible connect to SOLO2,3 but another mystery is here :

Why it does not show the hub like all others? I thought your hubs are not there anymore.
It was neccessary to type their names into the box.

But as I said many times, your test is nice, but it has nothing to do with the problem I try to dig in.
Anyway, thanx for your help.

solo2.png

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Mon Mar 01, 2021 8:43 am
by solo
sky59 wrote:
Mon Mar 01, 2021 7:42 am
Yes, it is possible connect to SOLO2,3 but another mystery is here : Why it does not show the hub like all others? I thought your hubs are not there anymore. It was neccessary to type their names into the box. But as I said many times, your test is nice, but it has nothing to do with the problem I try to dig in. Anyway, thanx for your help.
Does it all mean that you had connected, tried the ping test, and failed yet again?

Yes?/No?

Look, the remedy could be as simple as disabling the PC's firewalls. Have you checked them?

No mystery, no enumerate...
no.png

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Mon Mar 01, 2021 4:50 pm
by sky59
yes, I did connect, but no more tests as it is not of my interest (I have written this already few times)

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Mon Mar 01, 2021 10:56 pm
by solo
Your concluding remarks to this very long topic are truly underwhelming. Here is my summary.
  • you have written many times how unreliable the SoftEther's Layer 3 switch is
  • the switch always works for me - tested on PC (Windows/Linux) and ARM (OpenWrt)
  • recently you wrote "I start to have suspicions about windows 10 !!! both machines" and followed by the altered topic title "// Problem seems to be solved" but without revealing any details!
There is nothing suspicious about Windows 10 - its firewall simply blocked the test pings, while SoftEther's Layer 3 switch worked as advertised.

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Tue Mar 02, 2021 4:37 am
by sky59
No, you read my posts incorrectly.
Result is that se can not cope with non standsrd, non legacy internet routes.
Your test will not work with my company network or sim provided internet, it is for me the same provider.

Long known problem for me, i mentioned it already, even Layer2 is affected, is fact, that at company network "whatismyip.net" return xx.xx.xx.107. But router is on public xx.xx.xx.108
So when i connect to vpnXXXXXXXX. softether. net it does not work as DDNS uses 107. So i have to use for connecting numeric address 108
The similar problem with complicated routes also affects se.

And I DID offer to run my small server to the SE programmers to find out what is the problem.
This would not give direct answer on L3 problem, but if they found the reason why my server CONNECTED to Azure can not be accessed by any client. You also tried. For me it is non standard routes ISPs use now to get moe clients. I am in Austria so it seems it is more "advanced" country comparing where you are

Re: LAN-to-LAN again // Problem seems to be solved

Posted: Mon Mar 08, 2021 11:05 am
by sky59
I am so happy I was always right :)

Problem with L3 switch is solved once and forever. As I was claiming already many times the problem is internet connection.
I tried it many times at work with our huge and complicated IT network. Not even Azure was working. It connected but client
could not connect to the server. See above.

So I finally got villingness to open my mobile phone to get SIM card with PUBLIC IP (yes, you read correct, public), prepared
again server on OrangePi Zero based on OpenWrt (I was always using it above), put USB modem with SIM into the box and tried.

To underline, now I had pure, clean, direct connection to internet, no routers no complicated ways and static routes and other staff.
DIRECT connection from the OpenWrt kernel over USB modem.

Attached is a photo just for curiosity. Black cable is 5V supply.

I made tests from computer at home, connected to the VPN hub. At work I left another PC that connected to VPC hub inside white
box on the photo. Having good connection for server also PC at work managed to connect to the server even over work complicated
network.

On both PCs windows10, IP addresses for virtual NICs set up static over windows manager - see attached photo.

I used SoftEther instalation originally used only for L2 connection. The only thing I added was SW L3, see attache photo.

Then you see attached test using ping commands. The only response for local virtual NIC is below 1ms, rest is going outside of my
kitchen where I sit just now :)

ISSUE IS CLOSED, only would be nice if SE creators would be able to describe what properties must have server connection to function
properly L3 funcionality of the server.

The setting for remote PC was similar, 10.100.100.10/24 gw 10.100.100.1 also over windows network setting, like attached photo for
local PC I use now writing on it



*************Windows IP Configuration***************************

Ethernet adapter VPN111 - VPN Client: local virtual NIC, static IP

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::7481:cf7b:abd:9e1b%4
IPv4 Address. . . . . . . . . . . : 10.52.254.10
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.52.254.1

Wireless LAN adapter Wi-Fi: wifi connection to internet, DHCP Android

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::8ce9:3c3d:1568:4f3%16
IPv4 Address. . . . . . . . . . . : 192.168.43.74
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :



**************ping 10.52.254.10 local virtual NIC, response <1ms

Pinging 10.52.254.10 with 32 bytes of data:
Reply from 10.52.254.10: bytes=32 time<1ms TTL=128
Reply from 10.52.254.10: bytes=32 time<1ms TTL=128
Reply from 10.52.254.10: bytes=32 time<1ms TTL=128
Reply from 10.52.254.10: bytes=32 time<1ms TTL=128

Ping statistics for 10.52.254.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

**************ping 10.52.254.1 virtual interface VPN on L3 Switch

Pinging 10.52.254.1 with 32 bytes of data:
Reply from 10.52.254.1: bytes=32 time=198ms TTL=255
Reply from 10.52.254.1: bytes=32 time=101ms TTL=255
Reply from 10.52.254.1: bytes=32 time=84ms TTL=255
Reply from 10.52.254.1: bytes=32 time=88ms TTL=255

Ping statistics for 10.52.254.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 84ms, Maximum = 198ms, Average = 117ms

**************ping 10.100.100.1 virtual interface VPC on L3 Switch

Pinging 10.100.100.1 with 32 bytes of data:
Reply from 10.100.100.1: bytes=32 time=164ms TTL=255
Reply from 10.100.100.1: bytes=32 time=197ms TTL=255
Reply from 10.100.100.1: bytes=32 time=144ms TTL=255
Reply from 10.100.100.1: bytes=32 time=259ms TTL=255

Ping statistics for 10.100.100.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 144ms, Maximum = 259ms, Average = 191ms


"""""""""""""""""" BINGO """"""""""""""""""""""""""""""""""""""""""""
***************ping 10.100.100.10 remote PC virtual NIC, static IP

Pinging 10.100.100.10 with 32 bytes of data:
Reply from 10.100.100.10: bytes=32 time=146ms TTL=127
Reply from 10.100.100.10: bytes=32 time=177ms TTL=127
Reply from 10.100.100.10: bytes=32 time=212ms TTL=127
Reply from 10.100.100.10: bytes=32 time=163ms TTL=127

Ping statistics for 10.100.100.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 146ms, Maximum = 212ms, Average = 174ms





sw.png
virtualnic.png
IMG_20210308_110502.jpg