similar to: Clarification of man page on StrictSubnets

TL;DR: a proposal for a new tinc feature that allows nodes to filter ADD_SUBNET messages based on the metaconnection on which they are received, so that nodes can't impersonate each other's VPN Subnets. Similar to StrictSubnets in spirit, but way more flexible. BACKGROUND: THE ISSUE OF TRUST IN A TINC NETWORK In terms of metaconnections (I'm not discussing data tunnels here), one of

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

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 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

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

Guus The mdoc warnings (on FreeBSD 8) are getting a little bit annoying at times: anywi at lcrproxy:/usr/ports/security/tinc/work/tinc-1.0.19/doc % man tinc.conf 2>&1 | head -5 mdoc warning: Empty input line #6 mdoc warning: Empty input line #10 mdoc warning: Empty input line #15 mdoc warning: Empty input line #22 mdoc warning: Empty input line #30 There are hundreds. Ctrl-L refreshes

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

Guus, Would it be possible to have the HTML documentation in one file on the website? With configuration directives separated over multiple files and me never remembering where they belong, it would be easier to search for them. Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message

Guus, I would like to ask you to reconsider using SIGINT for logging change. It?s a pain to kill tincd when started from the command line. Ctrl-C does not work as expected. Great for debugging perhaps, but in normal use cases, when trying to make a connection work and test changes it?s a pain. On BSD there is SIGINFO (29), which can be sent by pressing Ctrl-T, but I am not sure whether that

Folks, Does any of you have a sensible way of monitoring tinc? I haven?t tried anything yet, sorry for that. I?d like to avoid log spamming like the check_ssh plugin does (?10+ preauth' warnings a day). check_tcp is an option, but I was wondering whether anyone cooked up something more sensible. Met vriendelijke groet, Nick Hibma -- AnyWi Technologies BV E: nick at anywi.com T: +31 (0)71

Guus, [tinc version 1.0.24] Consider the case where you have the following setup client - fw - server The client and server successfully setup a tunnel and UDP communication starts to happen. Then the client shuts up and the server only needs to send data to the client if the remote tool accesses the client?s UI. If the firewall times out the NAT UDP hole, the server has a problem: The UDP

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, We set up tinc tunnels over 3G when the connection becomes available. It is a mobile environment so connections come and go frequently. We send tinc an ALRM signal to retry a connection, but somehow this fails once in a while. Is there a way to influence the retry interval for connections that are down and the interval increment? We would like to be able to set this to 1 minute after ALRM.

Hi, We want to deploy a tinc VPN, with more than 50 sites connected all arround the world. But we cannot trust all our sites with the same level, so the tinc solution (automatic full mesh) is "too automatic" for us : *any* node can add a new node which will be connected directly to others. A solution could be TLS (signing public keys), but create a PKI is another issue for us.

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 tincers, I run a small tinc mesh using version 1.1pre10 on mostly linux (debian) hosts. In the past, I was able to successfully join my windows machine to the tinc network, when I was running an earlier version of tinc (throughout the mesh). However, with 1.1pre10, I have had no success. Is this a known error, a misconfiguration on my part, or some other issue? I currently have no tinc-up

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

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