NEEDED Updates

[tunermason]

I am a fan of VPNCloud however the beacon system seems to be a bit rough. With a mesh topology using a centralized beacon storage defeats some of the purpose. I guess one could have a file share on the seed node but that also is a point of failure. I was thinking about multicast but that would be hard to implement. Instead, I think we should have advertisement packets. They will be forwarded by each node that receives them for 2 hops then it expires. Yes, it may clog up the network with larger clusters, but it is a start. The second issue I have is with the IP system. In an effort to package VPN Cloud in a custom OS distribution, manually configuring each node is out of the question. As a short-term patch, I thought about using TAP interfaces with DHCP. However, the interface will not be created unless an IP address is defined in the .net/config file. Ideally a universal config file is my end goal.

Any and all input is welcome

[dswd]

Hi @tunermason.

The beacon feature is not limited to using files. Please see the docs (https://vpncloud.ddswd.de/features/beacons/) for more info. The github gist example shows how to use arbitrary commands to store and retrieve the beacon codes.

You can definitely use TAP interfaces with DHCP for dynamic IP addresses. The TAP interface will be created but it will not be activated without a configured IP address. You will have to manually bring up the interface with "ip link up" and "dhclient" (of course you can add those commands to the ifup script.

[tunermason]

I read the documentation for the beacons and the point that I was trying to get across is that you need a central dependency to have it operate properly. As for the interface with DHCP, I will definitely give that a try. Thank you for the information. After resolving the IP issue, the beacons would be the next main hurdle.

[tunermason]

Thank you for the information on DHCP, I tested and confirmed this is working

[tunermason]

I think another way would be to increase the beacon packet size to include peer information. Then there will be no need for a central distribution 'hub'. Over time a new peer's information will be propagated through the network.

[dswd]

The network will propagate the peer info internally anyway. The beacons are just a way to find an initial peer. However, I could add some code to include at least 5 addresses in every beacon.

[tunermason]

That sounds like a good idea. As far as the propagation in the network I haven't seen that in practice. I tried a 3 node test with node 1 and 3 connected to node 2 but not connected to each other. In theory shouldn't nodes 1 and 3 get each other's connection information from node 2? If the beacon was more so meant to find an initial peer, then I understand your use and implementation now. What would be a good way to test/configure propagation?

[tunermason]

So I think I found the problem with propagation. In the .stats file I found the following information (see below). It appears the code is trying to share the node configuration as seen by the node it's self (eg. lan ip). In this test there were three nodes each with it's own private subnet and public IP address and they are behind a NAT with port forwarding. So I think we should add a way to define the public address and/or use some sort of public Ip detection?

peers:

• "PUBLICIP:PORT": { ttl_secs: 246, crypto: AES256 }

forwarding_table:
claims:
cache:
- "XX:XX:XX:XX:XX:XX": { peer: "PUBLICIP:PORT", timeout: 255 }

peer_traffic:

• peer: "LANIP:PORT"
  in: { display: "0 B/s", bytes: 0, packets: 0 }
  out: { display: "74 B/s", bytes: 4495, packets: 31 }
• peer: "LANIP:PORT"
  in: { display: "0 B/s", bytes: 0, packets: 0 }
  out: { display: "74 B/s", bytes: 4495, packets: 31 }
• peer: "PUBLICIP:PORT"
  in: { display: "9 B/s", bytes: 563, packets: 5 }
  out: { display: "18 B/s", bytes: 1096, packets: 14 }

[tunermason]

@dswd