similar to: Authenticating VPN addresses: a proposal

There are many ways to set up and manage a VPN. Tinc's roots are a "friend network", where there is a group of nodes that all trust each other, and there is no central authority. It also works well in situations where all nodes are controlled by the same authority, for example when a sysadmin configures several nodes, like within a company that wants to link together several

On Mon, 23 Nov 2015, Guus Sliepen wrote: > It also works in a situation where a group of people trust a central > authority which provides them with the configuration for their tinc > nodes, if StrictSubnets is used. The drawback is that an external tool > needs to be used (ChaosVPN is one such example, but there are others) > and it is not very flexible, but I would disagree that

On 09/03/2016 10:56 AM, Etienne Dechamps wrote: > C will still need keys in order to establish metaconnections with A and B (as > well as a few other things). However there is no need for C to own any > "Subnets" at all. If somebody breaks into C, he could get access to the vpn network, right? Because the keys are there, it will be possible to use them to get access. Even if

Guus, I have a question on how to interprete the following fragment of the man page: StrictSubnets = yes | no (no) [experimental] When this option is enabled tinc will only use Subnet statements which are present in the host config files in the local /etc/tinc/NETNAME/hosts/ directory. Does this mean it will ignore any subnets learnt through ADD_SUBNET? Perhaps

If you're using StrictSubnets, you will still be fine. StrictSubnets means that A will only use B's key (which C does not know) to send packets to B's statically configured subnets. C cannot impersonate B (as in, take its node name) because it would have to know B's private key to do so, and it cannot impersonate B's subnets because A is using StrictSubnets. The worst that C

Hi all, 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. For instance, I create a node "node_2" and a host file

Hello, I am tying to create tinc vpn for the ~1000 nodes and was thinking why meta connections are needed at all if I only need static configuration where every node knows addresses of other hosts and due to the amount of traffic any indirect connections will not work, so DirectOnly=yes is a must and then passing around routing information is not needed, right? Currently I have 10 nodes

Something to add. When this happened, it looks like tinc shutdown gracefully(not seg fault ..), because I can tell tinc-down script got implemented. Heng On Wed, Nov 25, 2015 at 6:00 AM, <tinc-request at tinc-vpn.org> wrote: > Send tinc mailing list submissions to > tinc at tinc-vpn.org > > To subscribe or unsubscribe via the World Wide Web, visit >

Thanks for the reply. I am running tinc (1.0.24) in an embedded linux environment, with a pretty old kernel (2.6). I have let tinc run for almost 24 hours with internet and can't reproduce the issue. Heng On Wed, Nov 25, 2015 at 6:00 AM, <tinc-request at tinc-vpn.org> wrote: > Send tinc mailing list submissions to > tinc at tinc-vpn.org > > To subscribe or

Hi All, I've been playing around with TINC and like what I've seen so far. I wanted a TINC tunnel like this, where I have a server on the Internet with a public IPv4 address as my TINC server. Then I can have clients connect to it and see each other except that the client at a customer site would allow me to route behind it so I could see hosts on site beyond my device on premise. I do

On 4 May 2015 at 20:53, Anne-Gwenn Kettunen <anwen at asphodelium.eu> wrote: > We started to take a look about that, and apparently, it seems that the IP > in the public key is taken into account when a client connects to a gateway. > Spoofing at that level doesn't seem easy, because the IP address seems to be > part of the authentication process. I'm having trouble

Hello, Here is a patch for protocol_subnet.c with two modifications : - in tunnelserver mode, tinc must check subnets in the ".../hosts/owner" config file, not in "c->config_tree" (which is the configuration of the meta-connection from which we receive the ADD_SUBNET message). - this checking can be made before the check of the owner, especially before any

Hello, How does tincd determine the subnet(s) of other remote nodes? Does tincd read its copies of the hosts file and parse and follow the subnet information contained in the local files? Or does tincd solely trust the subnet information dynamically advertised by each remote node? In my experimentation, it seems that: a) tincd reads its own subnet(s) from its copy of its own host file, but

On 09/02/2016 08:51 PM, Etienne Dechamps wrote: > What version of tinc are you using? tinc 1.1 already does what you want out of > the box: packets sent from node A to node B through node C will use a key that > A and B will negotiate between themselves. C doesn't have the key, and will > act as a blind relay. C will not be able to decipher the packets flowing > between A and B.

For some weeks I've been trying to devise a way to connect multiple users in various parts of the city and state, and I found out that most likely Tinc is the only daemon that does the kind of meshing I want. I was successful in connecting some servers of mine around in switch mode, but now comes the hard part: How can I authenticate clients on my network? I would also need to direct static

I'm still confused, but in any case, there's nothing stopping "miou" from impersonating "apeliote"'s subnets in your case, unless you use StrictSubnets. Here's the easiest way to do the spoofing: In miou's own node file (on the miou machine itself), add apeliote's subnets with a Weight smaller than 10 (which is the default), so that it overrides them.

Whatever you do, keep in mind that tinc will always trust all nodes as long as they are part of the graph. It is not currently designed to deal with insider threats. Most importantly, that means anyone can impersonate any Subnet on a tinc network, just by changing the Subnet declaration in their node file. The only way around that is to use StrictSubnets, but that requires every node to be

With pleasure we announce the release of version 1.0.17. Here is a summary of the changes: * The DeviceType option can now be used to select dummy, raw socket, UML and VDE devices without needing to recompile tinc. * Allow multiple BindToAddress statements. * Decrement TTL value of IPv4 and IPv6 packets. * Add LocalDiscovery option allowing tinc to detect peers that are behind the

With pleasure we announce the release of version 1.0.17. Here is a summary of the changes: * The DeviceType option can now be used to select dummy, raw socket, UML and VDE devices without needing to recompile tinc. * Allow multiple BindToAddress statements. * Decrement TTL value of IPv4 and IPv6 packets. * Add LocalDiscovery option allowing tinc to detect peers that are behind the

Hi, Thanks for the link :) I guess we'll just end up having 2 separate VPNs, eventually. Have a good evening! > There is no centralized way to remove a subnet or block a user. A user > is authorized to be on the network by other nodes that have his/her > public key. If you delete the offending host config files and let tinc > reload its configuration, you can remove a bad node