vpncloud sends some packets to all peers at the same times

[baydakovss]

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

[baydakovss]

global_l2.net.txt

[dswd]

VpnCloud does not forward packets via other peers. There are only two ways packets could be duplicated within VpnCloud:

1. If you select "hub" mode then all packets are sent to all peers. This not the default mode and according to your config you are not using it.
2. In "switch" mode if you are sending to unknown addresses. This is the normal behavior of a switch but it should only affect a few packets until the receiver responds and the address is known. You seem to be seeing lots of packets getting copied to other peers.

Other than that, I don't see a way packets could be sent to the wrong peer within VpnCloud. However this could be an effect of your network setup surrounding the VPN. I see that you are configuring a network bridge which could cause such behavior depending on the configuration.

[biolim]

#cat global_l2.net|grep keepalive
keepalive: 10

When receiving keepalive packets from peers

720: https://github.com/dswd/vpncloud/blob/master/src/cloud.rs

the cache zeroing function is called

740: https://github.com/dswd/vpncloud/blob/master/src/cloud.rs

61: https://github.com/dswd/vpncloud/blob/master/src/table.rs

thus, the "switchout" value is not reached, and broadcast packets pass every "keepalive" second

[xeim]

I have same problem with recurring packet duplicates over vpncloud net.

[dswd]

Hi there,

after looking into it a couple of times without understanding the problem, I finally understood the source of the problem.

Thanks @biolim for pointing it out. I first dismissed your explanation as the "cache" is only there to speed up lookups (in the router mode) and cleaning it cannot change anything. However in switch mode, the cache IS the forwarding table and a cache miss means a broadcast.

Fix is on the way

[dswd]

Fixed in last commit. Please check if the problem is fixed.