Broken Layer 3 IP routing

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
solo
Posts: 35
Joined: Sun Feb 14, 2021 10:31 am

Broken Layer 3 IP routing

Post by solo » Sun Feb 14, 2021 11:13 am

My SE server and bridge/clients work fine in L2 mode but not in L3. I will describe the situation using the "10.6.4 Network Layout" example. After setting up routes on Osaka 192.168.2.0 subnet, I can ping:

SE server Osaka L3 switch 192.168.2.254 - OK
SE server Tokyo L3 switch 192.168.1.254 - OK
SE server Tokyo hardware NIC 192.168.1.10 - OK
Tokyo bridged LAN 192.168.1.x - NO ping is possible!
  • I rebooted Tokyo server numerous times
  • I installed the server on various versions of Windows
  • I have tried the server with 2 NICs
Is there a L3 bug in the "v4.34-9745-rtm-2020.04.05-windows" version?

nobody12
Posts: 23
Joined: Sat Feb 13, 2021 10:22 pm

Re: Broken Layer 3 IP routing

Post by nobody12 » Sun Feb 14, 2021 5:56 pm

From which IP do you want to ping to a host in the Tokyo lan?
What is the routing table of the host you want to ping to/What is the routing table of the default gateway in the Tokyo lan? Are there entries present which refer to the osaka and tsukuba networks and point to the Tokyo IP of the L3 switch in the Tokyo network?

solo
Posts: 35
Joined: Sun Feb 14, 2021 10:31 am

Re: Broken Layer 3 IP routing

Post by solo » Sun Feb 14, 2021 9:50 pm

nobody12 wrote:
Sun Feb 14, 2021 5:56 pm
From which IP do you want to ping to a host in the Tokyo lan?
What is the routing table of the host you want to ping to/What is the routing table of the default gateway in the Tokyo lan? Are there entries present which refer to the osaka and tsukuba networks and point to the Tokyo IP of the L3 switch in the Tokyo network?
I ping from Osaka VPN bridge PC to Tokyo server PC and Tokyo bridged LAN.
On Osaka: route add 192.168.1.0 mask 255.255.255.0 192.168.2.254 metric 2

There is no router or extra routing table in Tokyo as the server and LAN are directly L2 bridged.

Again, Osaka to Tokyo in L2 mode ping LAN OK.

TSUKUBA does not exist.

nobody12
Posts: 23
Joined: Sat Feb 13, 2021 10:22 pm

Re: Broken Layer 3 IP routing

Post by nobody12 » Mon Feb 15, 2021 7:48 am

But Tokyo also needs to know how to send packets to to Osaka.
You need a route for this. Either in the default router of the tokyo network or on any PC in the tokyo network. This route has to point to the Tokyo IP of the L3 switch in the Tokyo network.
If the IP of the L3 switch in Tokyo is 192.168.1.254, then you need a route: 192.168.2.0/24 via 192.168.1.254
Otherwise the ping packets will be sent to Tokyo, but are unable to return since nobody in Tokyo known where to send them.

solo
Posts: 35
Joined: Sun Feb 14, 2021 10:31 am

Re: Broken Layer 3 IP routing

Post by solo » Mon Feb 15, 2021 9:44 am

nobody12 wrote:
Mon Feb 15, 2021 7:48 am
But Tokyo also needs to know how to send packets to to Osaka. You need a route for this. Either in the default router of the tokyo network or on any PC in the tokyo network. This route has to point to the Tokyo IP of the L3 switch in the Tokyo network. If the IP of the L3 switch in Tokyo is 192.168.1.254, then you need a route: 192.168.2.0/24 via 192.168.1.254 Otherwise the ping packets will be sent to Tokyo, but are unable to return since nobody in Tokyo known where to send them.
There are numerous, unresolved posts on this subject and only you have explained it clearly and precisely.

Layer 3 IP routing works fine now. Thank you nobody12 !

sky59
Posts: 434
Joined: Tue Sep 11, 2018 5:58 pm

Re: Broken Layer 3 IP routing

Post by sky59 » Mon Feb 15, 2021 12:19 pm

nobody12 wrote:
Mon Feb 15, 2021 7:48 am
But Tokyo also needs to know how to send packets to to Osaka.
You need a route for this. Either in the default router of the tokyo network or on any PC in the tokyo network. This route has to point to the Tokyo IP of the L3 switch in the Tokyo network.
If the IP of the L3 switch in Tokyo is 192.168.1.254, then you need a route: 192.168.2.0/24 via 192.168.1.254
Otherwise the ping packets will be sent to Tokyo, but are unable to return since nobody in Tokyo known where to send them.
I do not understand. If you ping something somewere around the world you do not need to set up any route back to your computer you are pingging from.
Also for the stupid reason that you can not make ALL routes on all computers around the world to find you.

Instead of this, every router, every switch that is on the way to your destination device you are pinging keeps track of the message to be able to find the way back to your copmuter. I do not know how much time it is kept but there is a time defined for this.

So for me it seems that implementation of L3 virtual switch is not "regular" as it does not keep tha way back? And it should?
As you write the way going there to destination is OK, but way back is lost.

I have in neighbouring thread similar situation when I wanted and replicated this problem. I understand the need to provide correct gateway to my PC to reach destination but for the return path I should not care at all?? Should be automatic?

nobody12
Posts: 23
Joined: Sat Feb 13, 2021 10:22 pm

Re: Broken Layer 3 IP routing

Post by nobody12 » Mon Feb 15, 2021 5:43 pm

The behaviour you experience is normal.
Why:
Each device in a network segment has an IP address in the local Network, The Network Segment has a network adress which is made of a network address and a subnet mask. Example 192.168.10.0/24 (range is 192.168.10.1 to 192.168.10.255. All devices inside this Segment assume that any address within this network are directly accessible. When the device with the ip 192.168.10.1 wants to talk to 192.168.10.10 it makes an arp request: who has 192.168.10.10? and it gets the answer that a specific MAC adresse has this address. Then it can talk to 192.168.10.10 because it learned the MAC.
Now when it wants to talk to a device outside of the local network example to 192.168.20.1/24, it has two choices:
It first looks up its local routing table if there is a match for a route to 192.168.20.0/24. If there is a match it sends the packet to this router, hoping the router will then be able to deliver the packet to the destination. Second, If there is no match in the local routing table it sends the packet to the default gateway example 192.168.10.254, and again hopes this route will be able to deliver it to the destination. If the router is directly connected to the destination network it will be able to deliver the packet, if not the router will again try to lookup in its own routing table, check for a mach, if not it will deliver the packet to its own default gateway.
If you send a packet somewhere out of your local netowrk there is no information inside the packet how it can be sent back to the originator. It is left to destination device to discover a route back (this also makes sense because not always the path the packet did go is the best/right path to send an answer, there might be a shorter/better way back).
Therefore, both sender and receiver have either to know about a route where to send, or they rely on the default route.
If the Softether Router would be the same device as the default gateway, you would not need to create a seperate route, instead you just send the packet to the default router, Iti will know how to deliver the packet. But here you have a default router (gateway to the internet) and you have a second router, the L3 switch which is somewhere in your local network. Unless you create a static route in your default gateways routing table the router will send the packet in the internet - the wrong path.
So, either add the route to the default gateways routing table or to the routing table of any device in the local network (dhcp is able to distribute classless routes), but adding the route to the default gateway is a much better choice. Also, the default gateway can send a icmp redirect packet to the sender, so following packets (if the sender accepts icmp redirects) go to the correct address which will improve performance.

That is from my point of view why the behaviour ist normal: if you put more then one router inside of the network at least the default gateway needs to know all other local routing entries, otherwise you will have a problem.
This is not the fault of softether but the result of a network design with more then one router.

nobody12
Posts: 23
Joined: Sat Feb 13, 2021 10:22 pm

Re: Broken Layer 3 IP routing

Post by nobody12 » Mon Feb 15, 2021 6:31 pm

Another smaller followup to the large text:
If one of the routers is running NAT, then you do not need a routing entry for this hop, because packets originating from device behind a NAT router will appear to the destination like if the NAT router itself sent the packet. A packet sent from a NAT will be sent back to the NAT routers IP. The NAT router itself has an internal mapping table which enables it to return the packet to the correct destination.
Hoewver, NAT introduces problems: one way communication only. You dont want this. Also, NAT is not routing.

sky59
Posts: 434
Joined: Tue Sep 11, 2018 5:58 pm

Re: Broken Layer 3 IP routing

Post by sky59 » Mon Feb 15, 2021 6:33 pm

Thank you very much!
I hope you looked at my test. So my way to destination is ok as I provided gateway in my pc client.

But where on the way back should I add the route?

nobody12
Posts: 23
Joined: Sat Feb 13, 2021 10:22 pm

Re: Broken Layer 3 IP routing

Post by nobody12 » Mon Feb 15, 2021 6:56 pm

you mean this topic?
https://www.vpnusers.com/viewtopic.php?f=7&t=66579
If you want to send a ping from 10.100.100.200 to 10.52.254.200
Add an entry to the routing table to the host 10.100.100.200:
10.52.254.0/24 -> 10.100.100.102

On the other side, the host in the 10.52.254.0/24 network should have an entry in his routing table:
10.100.100.0/24 -> 10.52.254.102

Or, add these entries in the default gateways routing table.
Then any host in both networks will be able to communicate with any host in the other network.

sky59
Posts: 434
Joined: Tue Sep 11, 2018 5:58 pm

Re: Broken Layer 3 IP routing

Post by sky59 » Mon Feb 15, 2021 8:10 pm

Yes this topic..

Just for better understanding, if I want to ping only from local device 10.100.100.200 remote device 10.52.254.200, do I have to define routes on both sides?

I can imagine to define route on 10.100.100.200 device as it is a PC.
But on the other side 10.52.254.200 I have siemens PLC and I can not (?) define any route on it. What to do then? I have only Ubuntu as a BRIDGE layer 2.
If I understand this then I am happy :)

nobody12
Posts: 23
Joined: Sat Feb 13, 2021 10:22 pm

Re: Broken Layer 3 IP routing

Post by nobody12 » Mon Feb 15, 2021 8:29 pm

If the siemens PLC does not have a routing table which you can alter and also does not have a default gateway set (where you could put a route to the other side if you have permissions to do so), then there will be no way to communicate using layer 3.
You could put a NAT router in the network of the siemens PLC, which might be connected using a VPN to somewhere else. Then from the somewhere else location you cann talk to the siemens PLC.

sky59
Posts: 434
Joined: Tue Sep 11, 2018 5:58 pm

Re: Broken Layer 3 IP routing

Post by sky59 » Tue Feb 16, 2021 5:14 am

Thank you.
Also one local "expert" explained it in the same way. The problem for me was that there was no possibility to do it as PLC used so I could not understand it.
I will check one more time the plc possibilities....

solo
Posts: 35
Joined: Sun Feb 14, 2021 10:31 am

Re: Broken Layer 3 IP routing

Post by solo » Tue Feb 16, 2021 10:46 am

nobody12 wrote:
Mon Feb 15, 2021 8:29 pm
If the siemens PLC does not have a routing table which you can alter and also does not have a default gateway set (where you could put a route to the other side if you have permissions to do so), then there will be no way to communicate using layer 3.
What about a Proxy ARP layer 3 workaround? On a Linux SoftEther server simply edit /etc/sysctl.conf and add: net.ipv4.conf.all.proxy_arp = 1

Post Reply