similar to: ConnectTo Wildcard

Hi Guus Following your suggestion we reconfigured our tinc network as follows. Here is a new graph and below is our updated configuration: http://imgur.com/a/n6ksh - 2 Tinc nodes (yellow labels) have a public external IP and port 655 open. They both have ConnectTo's to each other and AutoConnect = yes - The remainder tinc nodes (blue labels) have their tinc.conf set up as follows:

Hi Today our Tinc network saw a network partition when we took one tinc node down. We knew there was a network partition since the graph showed a split. This graph is not very helpful but its what I have at the moment: http://i.imgur.com/XP2PSWc.png - (ignore node labeled ignore, since its a dead node anyways) - node R was shutdown for maintenance - We saw a network split - we brought node R

I have a use case where my tinc.conf ConnectTo can go upto 20 + hosts. I am planning to automate a periodic cleanup of ConnectTo in the tinc.conf file, the issue is I am not able to figure out which ConnectTo is been used and which are stale, say NOT used in last 2 to 3 days. I want to remove those ConnectTo which are no longer actively used. Is it possible to find which ConnectTo are not used.

Thanks Guss, some comments and questions: If you make the yellow nodes ConnectTo all other nodes, and not have > AutoConnect = yes, and the other nodes just have AutoConnect = yes but > no ConnectTo's, then you will get the desired graph. The reason this approach is not desirable is because it fails at automation. It requires us to add a new line of AutoConnect = <new node that

Hi Guus Thanks for clarifying. Some follow up questions: - How do we patch 1.1pre14 with this fix? Or will there be a 1.1pre15 to upgrade to? - What is the workaround until we patch with this fix? Using a combination of AutoConnect and ConnectTo? - When we use ConnectTo, is it mandatory to have a cert file in the hosts/* dir with an IP to ConnectTo ? -nirmal On Tue, Aug 22, 2017 at 12:10

thanks Guus for the quick response. I am using tinc 1.1 if I use AutoConnect = yes then will it automatically remove connections that are no longer in use? What are the security issues with 'AutoConnect = yes' I should be worried? for my use case I might go upto 20 to 30 + tinc hosts connected to single tinc box. as per the doc AutoConnect = yes is experimental, I am using it in our

Hello, We're suffering from sporadic network blockage(read: unable to ping other nodes) with 1.1-pre17. Before upgrading to the 1.1-pre release, the same network blockage also manifested itself in a pure 1.0.33 network. The log shows that there are a lot of "Got ADD_EDGE from nodeX (192.168.0.1 port 655) which does not match existing entry" and it turns out that the mismatches

I have a use case where I have to add new "ConnectTo=host" in tinc.conf and reload tinc. This is to make sure existing connections do not get disconnected. I use ... /usr/local/sbin/tinc --pidfile /var/run/tinc.vpn.pid -n vpn reload this works for most part, however, I am now seeing instance where I have to do a restart instead of reload. New connection works after a restart. Is there a

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)

Hi I'd like to build a Point-to-Point connection in Tinc 1.1pre14. My question specifically is how does one configure the conf file to achieve this Here's a simplified example: 1. There are 10 clients and 2 server nodes 2. All 10 clients have a Point-to-Point connection with the 2 server nodes 3. The 2 server nodes have Point-to-Point connection with all 10 clients. 4. In some ways this

Hi, Tinc Expert in my tinc.conf, the ConnectTo to host X is commented, like below: #ConnectTo = X and there is a script: /etc/tinc/netname/hosts/X-up, I thought commented the ConnectTo X wouldn’t trigger the X-up, but it did. Why? What’s the logic behind to trigger host-up? How can I avoid this except remove the host-up file? Bright Zhao

Thanks Guus I have one more question. - We see several log messages that we dont currently understand - Can you comment on what they mean and if they are concerning? I've obfuscated IP's and node names so please ignore those. Our tinc daemon command is: tincd -n <vpn name> -- Received short packet -- Got REQ_KEY from node003 while we already started a SPTPS session! -- Invalid

H, Narcissus Quick one for the below case, if node A have a direct connection to node B, and node B have a connection to node X, then I found node A will be able to talk to node X, but the communication path is go through node B, instead of build direct connection between A and X, is that right? I tested this in my environment. A >> B >> X > On 1 May 2017, at 3:07 PM, Narcissus

Hello. I am using the current 1.0 stable. I have tinc daemons on different dynamic ip connections. They have ports forwarded. They are using switch mode. I have 1 box which has dynamic dns set up. I would like everyone to use that for bootstrapping using ConnectTo. However I do NOT want that host to tunnel all traffic due to downtimes and bandwidth limitations. Can i get tinc to share the ips

Hi, I was quite surprised to see commmit 332b55d4 ("Change AutoConnect from int to bool"). Is there experimental evidence supporting 3 as the hardcoded maximum number of meta-connections? If there is a good reason for this limit on the number of meta-connections, maybe it should apply whatever the value of AutoConnect (currently, it is only enforced when AutoConnect is on). We may

On Thu, Aug 31, 2017 at 01:37:28PM -0700, Nirmal Thacker wrote: > If you make the yellow nodes ConnectTo all other nodes, and not have > > AutoConnect = yes, and the other nodes just have AutoConnect = yes but > > no ConnectTo's, then you will get the desired graph. > > The reason this approach is not desirable is because it fails at > automation. It requires us to

We have a handful of nodes set up. Some are NAT'd but a few have direct access to the Internet. Sample confs: HostA: Name = HostA AddressFamily = any Interface = tap0 Mode = switch Connectto = HostB GraphDumpFile = /tmp/mesh HostB: Name = HostB AddressFamily = any Interface = tap0 Mode = switch Connectto = HostA GraphDumpFile = /tmp/mesh And so on. If I use HostA as the main meta sever.

On Mon, Aug 21, 2017 at 05:37:06PM -0700, Nirmal Thacker wrote: > Today our Tinc network saw a network partition when we took one tinc node > down. > > We knew there was a network partition since the graph showed a split. This > graph is not very helpful but its what I have at the moment: > > http://i.imgur.com/XP2PSWc.png The graph is very clear. > Some questions:

Hi, I have successfully setup a tinc network between five hosts (in switch mode). Two of the hosts have static and known IP addresses (S1 and S2). Other hosts (H3-H5) connect one (or both) of them. The traffic flows nicely between all hosts. The initial edges (ConnectTo configuration directives) in my test network are: S1<->S2 H3 -> S1 and S2 H4 -> S1 H5 -> S2 As far as I have

On Thu, Aug 31, 2017 at 10:40:39AM -0700, Nirmal Thacker wrote: > Following your suggestion we reconfigured our tinc network as follows. > Here is a new graph and below is our updated configuration: > http://imgur.com/a/n6ksh [...] > We are concerned that: > - We still dont see edges in the graph that show connections between every > blue labeled node to both the yellow labeled