On Tue, Jul 08, 2014 at 10:46:38PM +0100, Graham Cobb wrote: > > I do agree that if a > > large fraction of the nodes in the VPN is behind a NAT, it can take > > quite a time for the current logic to find a node it can connect to. > > Isn't a fairly common scenario a hub and spoke but with a redundant hub?
Yes.
> Nodes A and B are internet servers, with a connection between them. C1,
> C2, ... Cn are clients, each behind NAT, and each configured to
> ConnectTo A and B.
>
> Today, the Ci all have two connections: one to each of A and B. But
> with a connection limit of 3 on A and B, both will be trying to drop the
> connection to Ci to get down to their connection limit.
Again, the AutoConnect feature does not impose a hard limit on the
number of connections. The central nodes will still accept all incoming
connections and will not drop them.
> Presumably the "don't disconnect if this is the last connection for this
> node" test will mean that each Ci will retain one of its connections,
> but only one (some to A, some to B).
First of all, when AutoConnect is enabled on a node, it will never drop
incoming connections, it will only drop outgoing connections. So in your
dual-hub-and-spoke scenario, each Ci will still have two working
outgoing connections to A and B.
> In that case, if a Ci connection goes down, it is isolated until it
> can reestablish a connection (as it is behind NAT, only outbound
> connections work). Will that be attempted immediately?
When the number of connections drops below 3, it will within seconds
attempt to make a new connection.
> Also, is there a way to make sure that the connection between A and B is
> never selected to be dropped (you don't want traffic from A to B routing
> through one of the Ci)?
At the moment only by disabling AutoConnect on A and B. But I will add a
feature to specify mandatory connections.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
signature.asc
Description: Digital signature
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
