LocalDiscovery flip flopping and network design tips

[Etienne Dechamps]

Hang on a second. I've just re-read your original message and I
believe you are confused about what the "Subnet" option does. Again,
it deals with addresses *inside* the VPN. In the configuration you
posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal
addresses, but then your other statements (and especially your dump
edges output) seem to indicate that 10.240.0.4 and 10.240.0.5 are
*also* the physical addresses of the machines on their physical
network interfaces.

That's not going to work: as soon as tinc manages to establish the
VPN, 10.240.0.4 and 10.240.0.5 become routable on *both* the virtual
and physical interfaces, resulting in conflicts, and it all goes
downhill from there. That would completely explain the weird phenomena
you're reporting. If you make sure to use different IP subnets for VPN
addresses and physical addresses, your problems should go away.

On 14 February 2017 at 20:36, Etienne Dechamps <etienne at edechamps.fr> wrote:
> On 14 February 2017 at 18:59, James Hartig <james at levenlabs.com> wrote:
>> When you say "and to the local network" what IP does it try to send to
>> on the local network? The subnet address?
>
> No. The Subnet option deals with routing *inside* the VPN, not the
> underlying "real" network.
>
> In tinc 1.1, the address that local discovery probes are sent to is
> the local address of the recipient node, as determined by the socket
> local address of its metaconnection. That's the address shown next to
> "local" in the dump edges output. In your case the local address is
> advertised correctly - there is no problem there.