remote server (SRemote) which bridge on virtual tap, which works fine
softether SLocal is bridge on eth0 which is a real eth device.
SLocal cascade fine with SRemote and every other settings is good, because if SLocal bridge on virtual tap it works complete just fine

PC: (192.168.2.3/16)
SLocal eth0: 192.168.2.2/16
SRemote tap_vpn: 192.168.9.1/16

in my lan networks i have PC wich connects on switch to eth0
arp/pings is fine with between: PC<->SLocal
arp/pings is fine with between: PC<----via SLocal(eth0) softether ----->SRemote, so let's ignore any NAT/connection detail

however the SLocal itself can't get any packet from SRemote using eth0
tcpdump on eth0@SLocal looks fine because
# tcpdump -ni eth0 host 192.168.9.1
A:
11:38:33.036212 ARP, Request who-has 192.168.2.2 tell 192.168.2.2, length 28
(which means SLocal(192.168.2.2) did request ARP from for IP 192.168.2.2)

and B:
11:38:33.334186 ARP, Reply 192.168.9.1 is-at 00:ac:72:a9:7a:83, length 28
(which means SRemote(192.168.9.1) did respond ARP correctly and get received to eth0@SLocal)

but SLocal never read this ARP response:
ip neigh show | grep 192.168.9.1
192.168.9.1 dev eth0 FAILED


even if i do "ip neigh change 192.168.9.1 lladdr 00:ac:72:a9:7a:83 dev eth0" on SLocal, the tcpdump shows fine about ping:
11:41:01.563765 IP 192.168.2.2 > 192.168.9.1: ICMP echo request, id 13066, seq 1, length 64
(request sent)
11:41:02.103345 IP 192.168.9.1 > 192.168.2.2: ICMP echo reply, id 13066, seq 1, length 64
(respond received)

but ping didn't get anything
# ping 192.168.9.1
PING 192.168.9.1 (192.168.9.1) 56(84) bytes of data.
^C
--- 192.168.9.1 ping statistics ---
23 packets transmitted, 0 received, 100% packet loss, time 22017ms


==========
here's my suspicion:
softether bridge on vpn, when the respond packet is put to eth0, kernel@SLocal can't see/receive it because the packet is being sent out from eth0, not received from eth0
i can't say much because i have no idea how the bridge works and why tap works without this problem


==== other infos
server: gentoo, softether-server
client: openwrt, softether-server 4.17-9566-beta-1, 3.18.17 #23 SMP Sun Aug 9 02:26:50 CST 2015 x86_64

This is a technical limitation. The vpn clients cannot communicate with the server if the bridge is at the interface that the server is listening on.

Method 1:
You should use a tap device on the VPN Server. Bridge it to eth0 using linux bridge. Assign IP on the linux bridge.

Method 2:
You should have a dedicated NIC for the local bridge.

Can you please explain to me what the method 2 is. what is dedicated NIC

Add a dedicated network interface for the local bridge.

kh_tsang wrote:
> This is a technical limitation. The vpn clients cannot communicate with the
> server if the bridge is at the interface that the server is listening on.
>
> Method 1:
> You should use a tap device on the VPN Server. Bridge it to eth0 using
> linux bridge. Assign IP on the linux bridge.
>
> Method 2:
> You should have a dedicated NIC for the local bridge.
i'm not sure if i understand the limitation. because both vmware and virtualbox can "bridge" on real interface "directly", without creating any bridge interface like br0 (which is managed by brctl)

i really hope softether can be like vmware/vbox on this issue

can you please overcome this limitation like tinc/vmware/vbox do? please

I tried a little survey.
In VirtualBox, bridging is implemented as kernel filter driver.
https://github.com/mirror/vbox/tree/mas ... VBoxNetFlt

I do not have enough knowledge of the Linux kernel, but I guess that updating the kernel driver following the Linux kernel update requires a continuous and significant effort.
If there are contributors who can provide such abilities and labor, realization is not impossible (but difficult).