Unauthorized ADD_SUBNET, but known subnet

[Guus Sliepen]

On Wed, May 22, 2013 at 04:23:39PM +0200, Ivan Vilata i Balaguer wrote:

> I'm using a tinc 1.0.19 (from Debian Squeeze) setup with some nodes
> connecting to a "server" node which has "StrictSubnets = yes".
> Whenever a new node is added to the mesh, a process generates and
> drops its host file in the server's host directory before the node is
> booted and tries to connect. […]
> 
> The node publishes that subnet and the server knows it beforehand from
> the existing node host file, but as you can see it still ignores it as
> unauthorized so the node is unreachable.  Killing the server daemon
> with HUP makes everything work, but I expected this not to be
> necessary.  Surprisingly, replacing the node's public key first in the
> server then in the node and restarting the daemon in the node (without
> touching that of the server) results in the node getting back online.
> 
> Any ideas on why the server needs the HUP?

The server needs the HUP so it will reread the host config files and update its
list of approved Subnets. However, the validity of a Subnet that a node
announces is only checked when that node announces its Subnet. So the best way
is to make sure the server gets the new host config file and a HUP signal
before the new node comes online.

> Moreover, although it doesn't accept the subnet itself, the server
> forwards the ADD_SUBNET to other nodes (in the tests they are on the
> same network link and only know the server to which they ConnectTo) so
> other nodes can ping the newly added node but the server cannot.  The
> problem is that I need to contact services running in the server from
> the node. :-/
> 
> There's also the question whether forwarding such an untrusted network
> makes sense (can it be disabled?), but that's another topic...

There are various options that control forwarding of information. You might
want to use the TunnelServer option in your case.

-- 
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/attachments/20130523/4ad1a407/attachment.pgp>