similar to: Fwd: How to avoid friends of friends joining the vpn ?

Thanks I will look into StrictSubnets, while digging through the mailling list I came across this: https://github.com/siblynx/tinc-1.0.16_hostupd/blob/master/README.hostupd which is pretty close to what I need That looks to be a fork on its own, with no PR raises for addding that functionality to the main tinc, unless I missed it out. Are there any plans to bring that functionality in ? -azul

Hello dear Tincers! I recently developed an extension to tinc 1.0.x protocol which introduces automatic and decentralized hosts update subsystem. The idea is to provide stable protocol extension to tinc which will do all the dirty work of spreading information about new hosts in network across all nodes by powers of tinc itself. If you're interested, you can take a look at the diff made for

On Sun, Mar 13, 2016 at 04:57:12PM +0000, Azul wrote: > Tinc 1.0 > 3 control masters > Many service hosts > Laptop (road warrior) > > The control masters have the public keys for the service hosts and the > laptop so that they can join the network. > > How can I prevent the laptop user to connect additional boxes to the > network? There are several ways. One can

*You should repeat this for all nodes you ConnectTo, or which ConnectTo you. However, remember that you do not need to ConnectTo all nodes in the VPN; it is only necessary to create one or a few meta-connections, after the connections are made tinc will learn about all the other nodes in the VPN, and will automatically make other connections as necessary. * The above is from the docs. Assuming

Hi all, I'm currently happily using tinc in my networks. I also use OpenVPN based on the customer requirements. I though have some questions which I could not find a clear answer. What I'd like to know is: 1. How to revoke a "node", simply removing the host file on the servers is enough? And one created by invitation? 2. Is there a way to let tinc ask for a username/password

Hi We have several stale nodes in our tinc network and I'd like to remove these. These nodes show up in graph dumps as red nodes, indicating they are unreachable. We run: tinc -n <vpn-name> purge Nothing happens. If we tail the logs at /var/log/syslog, we dont see an ack or message concerning the purge either. The dead nodes still show up in the graphs and their certs are still

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

Dear All, We are trying the Tinc invites to let nodes join the network. This is working as described but we want to push some configuration for some nodes but this seemed not to be working. What is working is the following invite: Name = test_invite NetName = test_VPN ConnectTo = test_hub01 Ifconfig = 172.16.1.4/24 Subnet = 172.16.1.4

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

Hello, are there reasons why all the examples for debian and ubuntu explain how to setup tinc to start from the init job /etc/init.d/tinc and /etc/tinc/nets.boot and why there are no examples or tutorials on howto start tinc from /etc/network/interfaces ? Using /etc/network/interfaces I have a perfectly running tinc vpn with an unprivileged user, locked memory and a chroot jail plus converted

Hi! here a little patch for darknet functionality, i hope it does what its intended for sufficiently ... but it seems to work :). what should it do? imagine your friend-network. A trusts B and C. B trusts D and E, D trust F, C trusts G. All trust relationships are mutal A <---> C <---> G ^ \ \-----> B <---> D <---> F ^ \ \---> E

Hi, We have a tinc network of about ~200 hosts and in the full mesh configuration we've had a lot of problems with the edge propagation storms taking the entire network down. Recently we had a setup with a small number of "hubs" to which all the other nodes connected to, which limited the number of meta connections, but that didn't help much with the edge propagation issues.

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

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

That sounds pretty amazing. Excellent work and thanks for contributing, I hope this gets implemented. On 16 Oct 2015 11:02, "????" <lynx at lynxlynx.tk> wrote: > Hello dear Tincers! > > I recently developed an extension to tinc 1.0.x protocol which > introduces automatic and decentralized hosts update subsystem. > > The idea is to provide stable protocol

The following is maybe a bug report, and a proposed patch. Using latest stable tinc 1.0.12. I have a central server and a few clients connecting to this server. I don't want clients to speak directly, but I want all the communications to pass by the server. My configuration is: Mode = switch TunnelServer = Yes I need layer2 because of some ethernet stuff on the clients. When you have

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

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

Hi, we use a tinc network of about 400 nodes, all of them linux servers, partly in different datacenters (but generally low latency). Usually this is working very well (for weeks without a problem). >From time to time the whole network goes down though. This happened when we restarted a larger number of servers or when there was a connectivity issue between datacenters or some (short)

thanks, but i was able to make it work based on some suggestion on tomato shibby forums. Regards Ramesh On Sun, Jan 15, 2017 at 9:02 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Fri, Jan 13, 2017 at 06:53:07PM +0000, Guillermo Bisheimer wrote: > > > I've setup a Tinc VPN for a bunch of nodes divided in two groups: > > > > Group 1: > > IP Range