similar to: "Mode Switch" and "Tunnelserver Yes" cause unnecessary traffic to clients (proposed patch)

Let me start with what I'm trying to accomplish. I use tinc mainly to get to subnets behind the daemons and I don't control those subnets and can't guarantee overlap. I was using routing mode and reconfiguring tinc every time i needed to get to a subnet behind a specific daemon. Then I came across switch mode that allowed me to simply add routes based on the IP address of the tinc

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

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.

> I'm mostly looking for guidance on whether it is possible for daemons to > only accept traffic from specific daemons in switch mode. If so, what am I > doing wrong with my subnet configurations that won't let me even ping from > one daemon to the server when TunnelMode is yes? check if this patch still applies:

*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, thank for getting back. I'll answer the questions, but I've already gave up on tinc and switch to zerotier-one. On 2020-07-27 5:10 p.m., borg at uu3.net wrote: > Hi. I have few questions out of curiosity.. Cant help for now with > your problem... > > What version is crashing? 1.1 or 1.0 ? 1.1 is crashing > > How your network is segmented..? > I use tinc myself

Hi all, I have a network with about ~800. The network is a mix of tinc 1.0 and 1.1 nodes. It is gradually expanding for several years now. The problem is that at some point it seams the daemon can not handle the processing of the new connection and the edges. There are 3 major nodes in the system and every other node initially makes connection to one of them. Now after a lot of debugging

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

I don't know why, but for my case, I reduced the tinc topology from a complex one(which provide layered redundancy) to a very simpled one(one connection), and that connection drop disappeared. Later, let me draw the topology and share the config to you to see if there's any findings of the cause. Guus Sliepen <guus at tinc-vpn.org>于2017年9月14日 周四上午3:20写道： > On Wed, Sep 13, 2017

Hi. I have few questions out of curiosity.. Cant help for now with your problem... What version is crashing? 1.1 or 1.0 ? How your network is segmented..? I use tinc myself here a lot too (1.0) but my network is very segmented. I use switch mode and handle routing myself, so mesh links arent large.. I would NOT go beyond 30 nodes for full auto-mesh.. its already like 435 edges... Regards,

Thanks for answers. I think its now flaw.. but design.. Tinc auto-mesh is very very handy. You just need to avoid flat networks. There is also IndirectMode w/ forces nodes to be switched by intermediate node... but I would be cautionus how its used. I use it myself for certain nodes behind NATs where they cannot be connected to, so always connect node handles switching for them. You noticed it

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, All Here is the case: A, B, C, D all configured with "IndirectData = yes”, so connection only happens when there’s a “ConnectTo” in tinc.conf. Arrow indicate the “ConnectTo” direction Everything works fine earlier as below: 1. A connect to C, D connect to C 2. C is the transit node where only forward traffic between A and C 3. D advertise 0.0.0.0/0#2 4. A can access internet from D

Well i currently try to set up tinc between two hosts, one with normal dsl connection one behind some kind of unknown firewall (Note since OpenVp is able to connect when the normal one is the Server I guess tinc should be able, too) start.bat-------------------------------tincd -n Empire-Network -D -d4 --bypass-security (Bypass is only currently because tis not working yet)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On Wed, 7 Oct 2020, Hamish Moffatt wrote: > On 22/9/20 4:44 pm, Hamish Moffatt wrote: >> Is it possible to a configure a tinc (1.0.35) node to only send outbound >> through specific nodes, rather than trying to establish direct connections? >> >> I have a node which can connect to all the others directly, but some

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

Hello, Anyone on this list had successfully used tinc on planet lab [0] ? I'm trying to do it but I get some problems using the tap device tincd just keeps printing this error: Error while reading from Linux ethertap device /dev/net/tun: File descriptor in bad state I guess the problem is I cannot manage tun/tap devices on the planet lab nodes even if I am root :( Look at this: bash-3.2#

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

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