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 <[email protected]> wrote: > On 14 February 2017 at 18:59, James Hartig <[email protected]> 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. _______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
