LocalDiscovery works by sending some of the MTU probe packets to the broadcast address (255.255.255.255). If the destination node receives one of these packets, it will update its UDP cache and reply, thus the two nodes will start using their local addresses to communicate. Now, I see two problems with this approach: - In case the two nodes are behind the same NAT and can reach other *but* are not on the same broadcast domain, LocalDiscovery won't work. This is a typical situation in entreprise/university environments where there are often multiple routed private subnets behind the NAT. - Contrary to popular belief, sending packets to 255.255.255.255 doesn't send them on all network interfaces. This is true for Linux and Windows[1]. It is hard to predict which interface will be used unless one manually looks at the routing table. This can lead to ironic situations where tinc tries to send MTU probes on its own VPN. Fixing this requires iterating over all interfaces to manually send the probes on each one, which is complicated and AFAIK hard to do in a portable way. To fix these issues, I am suggesting adding functionality to the tinc protocol that allows nodes to advertise their own local socket addresses (IP and port) to the rest of the graph. Then, instead of sending probes to the broadcast address, they would be sent directly to the node's local socket address. IMHO this is an elegant solution that solves both issues above and as an added bonus is more friendly to the underlying local network since it doesn't use broadcasts. The only situation where it would break is if there is a local private NAT between the two local nodes, but this is probably an unsolvable problem anyway since we just don't have the necessary information to make them reach each other in this case, and broadcasts obviously won't get through a NAT. I guess the local socket information could be added to ADD_EDGE messages and stored in edge_t. Thoughts? [1] http://serverfault.com/questions/72112/how-to-alter-the-global-broadcast-address-255-255-255-255-behavior-on-windows (the long discussion in the comments of the second answer are particularly interesting) -- Etienne Dechamps
On 21/07/2013 17:41, Etienne Dechamps wrote:> To fix these issues, I am suggesting adding functionality to the tinc > protocol that allows nodes to advertise their own local socket addresses > (IP and port) to the rest of the graph.To clarify, I'm referring to the local address as returned by getsockname() on the metaconnection's underlying socket. Obviously calling getsockname() on the listen socket itself won't be very useful since that will return INADDR_ANY (0.0.0.0) with most configurations. -- Etienne Dechamps
On Sun, Jul 21, 2013 at 05:41:06PM +0100, Etienne Dechamps wrote:> - In case the two nodes are behind the same NAT and can reach other > *but* are not on the same broadcast domain, LocalDiscovery won't > work. This is a typical situation in entreprise/university > environments where there are often multiple routed private subnets > behind the NAT. > > - Contrary to popular belief, sending packets to 255.255.255.255 > doesn't send them on all network interfaces. This is true for Linux > and Windows[1]. It is hard to predict which interface will be used > unless one manually looks at the routing table. This can lead to > ironic situations where tinc tries to send MTU probes on its own > VPN. Fixing this requires iterating over all interfaces to manually > send the probes on each one, which is complicated and AFAIK hard to > do in a portable way.As suggested by Folkert van Heusden, I added the LocalDiscoveryAddress option to change the broadcast address. That is still not perfect of course.> To fix these issues, I am suggesting adding functionality to the > tinc protocol that allows nodes to advertise their own local socket > addresses (IP and port) to the rest of the graph. Then, instead of > sending probes to the broadcast address, they would be sent directly > to the node's local socket address. > > IMHO this is an elegant solution that solves both issues above and > as an added bonus is more friendly to the underlying local network > since it doesn't use broadcasts. The only situation where it would > break is if there is a local private NAT between the two local > nodes, but this is probably an unsolvable problem anyway since we > just don't have the necessary information to make them reach each > other in this case, and broadcasts obviously won't get through a > NAT. > > I guess the local socket information could be added to ADD_EDGE > messages and stored in edge_t.That is indeed a better way, and the ADD_EDGE messages can be extended while preserving backwards compatibility. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20130722/14a85888/attachment.sig>