can't ping between server using "bridge on eth0"
Posted: Tue Aug 18, 2015 4:27 am
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
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