vpncloud sends some packets to all peers at the same times

[baydakovss]

Discussed in #253

^{Originally posted by baydakovss November 6, 2021}
Hello
There is a problem we faced with vpncloud. Rather often the packet or groups of packets (not all packets) sending from transmitter go through all vpncloud simultaneously like broadcast.
Those peers trying to forward packets to receiver as relayer.

But I can not blame broadcast/multicast in common linux.
tcpdump -n "broadcast and multicast" show nothing.

It seems specifically vpncloud sends traffic to all peers at the same times occasionally.

Let me demonstrate to you how is it loos like for ICMP (but applied to tcp/udp as well)

Sender

[root@wz-gw10 ~]# ping 172.22.0.10
64 bytes from 172.22.0.10: icmp_seq=**654** ttl=64 time=0.317 ms
....
64 bytes from 172.22.0.10: icmp_seq=**684** ttl=64 time=0.364 ms

Receiver gets this all ICMPs. Seems all good

But the others gateways with vpncloud receive some packets as well

root@hz-gw17:~# tcpdump -i any -nn proto ICMP and host 172.22.0.10
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
09:26:14.106677 vpncloud0 P   IP 172.22.0.13 > 172.22.0.10: ICMP echo request, id 11734, seq **654**, length 64
09:26:44.106752 vpncloud0 P   IP 172.22.0.13 > 172.22.0.10: ICMP echo request, id 11734, seq **684**, length 64

[root@wz-gw1 log]# tcpdump -i any -nn proto ICMP and host 172.22.0.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
09:26:14.104039 IP 172.22.0.13 > 172.22.0.10: ICMP echo request, id 11734, seq **654**, length 64
09:26:44.104013 IP 172.22.0.13 > 172.22.0.10: ICMP echo request, id 11734, seq **684**, length 64

As you can see ICMP packets with tcp sequences 654 and 684 (and a dozens before) were transmitted not directly.
It has not only todo with ICMP but UDP and TCP as well

In stat file I see just right entry in cache

forwarding_table:
  claims:
  cache:
    - "fa:78:cf:e9:76:c3": { peer: "185.ZZZ.XXX.YYY:3210", timeout: 299 }

In peervpn there is an option enablerelay: yes/no. But I can't find something like that in vpncloud documentation.

We have /16 ethernet segment and set ip adress statically
The configuration is typical for all peers.

I wonder how we can avoid this behavior. We need traffic sending just directly not bypass

Thank you

[dswd]

Should be fixed in 2.3.0