No connection between nodes on same LAN

[Guus Sliepen]

On Fri, May 07, 2010 at 09:03:09AM +0200, Daniel Schall wrote:

> > However, if you add a "ConnectTo = Node2" to Node1's tinc.conf, and add
> > "Address = 192.168.0.102" to Node1's hosts/Node2 file, then it will make a
> > direct connection.
> 
> Unfortunately, the nodes get their IP by DHCP, so a fixed address would not
> help.

Aha.

> Setting up a local node behind each router with a static IP is also not
> possible, since my nodes are often on-the-go in foreign networks, where I am
> unable to set up static addresses by myself.

You could still do that, and have the mobile nodes connect both to the local
node with a static IP (which will fail of course when you are on another
network), and to the external node with public IP. Then at least at your home
network the nodes will connect to each other directly.

> > Tin does no autoconnect to each other, it does only connect if you set
> > "connectto" line in tinc.conf. But tinc does mesh after connect, so all
> > connections will be announced and packtes will find destination
> > automaticly.
> 
> As far as I understood the documentation, "connectto" is used to connect
> nodes to each other in order to exchange meta-information, where each node
> is located at (IP:PORT).

Correct.

> The actual "meshing" always occurs directly between all nodes, unless this
> is impossible due to firewalls etc.

Correct.

> So shouldn't it be enough to connect all nodes to a centralized one (Node3),
> where they can exchange their address-details in order to connect diretly to
> those addresses afterwards?

That's what it does, however tinc nodes do not announce their own local IP
address, rather the node they connect to announces the IP address the
connection came from.

> In my opinion, tinc does not support multiple endpoints, hence Node3 saves
> only the publicly visible (NATed) endpoints for Node1 and Node2.
> 
> The privately visible endpoints in the LAN are not saved and announced back.
> Therefore, Node1 and Node2 never know, they are on the same network.

Exactly.

> Do you have any advice for me, how to achieve the desired behavior?
> 
> I'd suggest that each node announces its local endpoint to other nodes on
> connectto and the other node saves this endpoint together with the publicly
> visible one where it sees the packets coming from.
> 
> That would enable each node to select the "best" endpoint to connect to the
> other node.
> 
> This selection could either be algorithmic by calculating the shortest
> distance to the other endpoint or by trying out and selecting the one with
> the lowest round trip time.

That is one possibility, but that would require changes to the protocol. It
might be possible to do that in a backwards compatible way.

Another option would be to use Avahi to announce and discover local nodes. This
will not require any changes to the protocol.

A third option that might work is when doing PMTU discovery after exchanging
session keys between Node1 and Node2 (via their meta connections with Node3 of
course), that they also send some MTU probes to the broadcast address. The
receiving node will update the known address of the peer when it receives a
valid UDP packet, whereever it came from.

I think the third option is easiest to implement, I don't know if it will work
though. I'm a little busy this month so if you or someone else wants to try to
implement it, please go ahead :)

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100507/7f19fa3d/attachment.pgp>