similar to: lose connection with traffic from connector to connectee

Hi, I've been running tinc for a couple of months and it's great, but I have a periodic problem which maybe you guys can figure out. I operate a 3-node tinc VPN, lets say A, B and C. A / \ B --- C The problem is that after a while, node C can't exchange data with node B. It works fine (ping and other traffic) for about 10 minutes, then fails. Here is some debug

Hello, I'm trying to test a tinc vpn between two Linux hosts on the same ethernet. If I start tinc on both sides as 'tinc -n test --bypass-security --debug=5' I can ping both machines from each other and tcpdump shows that the packets pass through the tun-device created by tinc. Connection from 192.168.192.17 port 32852 Sending ID to (null) (192.168.192.17 port 32852): 0 helix 17

Hello, I have been reading through the documentation and trying to set up a very small VPN as a test for a larger rollout that I would like to complete in the future but cannot get this working. The configuration seems like it should be relatively simple, so I'm most likely missing something basic but I just cannot see what I'm doing wrong. At the moment I am trying to get this working

> - Indirectdata finally REALLY REALLY works now! > - More precise debug messages Hmmm ... I can't prove that using the CVS code I checked out this morning. Everything works like yesterday: I can ping the peer but I canot go beyond: *** SERVER *** Jun 27 09:04:56 lemon tinc.9[10186]: tincd 1.0pre3 (Jun 27 2000 08:53:56) startin g, debug level 4 Jun 27 09:04:56 lemon tinc.9[10186]:

Here are a few facts that should make things clearer. Regarding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of

Hello. Finally I discovered the mailinglists and subscribed. Before, I were in #tinc, pinging guus all the time with various stuff/problems/patches/etc. So... the problems, in no particular order. 1) Quite often, after re-starting a client (I run in tunnelserver mode), no packets are flowing. Tcpdump shows packets being sent from client but nothing gets received, and on the server both send

I would like to discuss the following commit: https://github.com/gsliepen/tinc/commit/4a0b9981513059755b9fd15b38fc198f46a0d6f2 ("Determine peer's reflexive address and port when exchanging keys") This is a great feature as it basically allows peers to do UDP Hole Punching (via MTU probes) even when both are having their source ports rewritten by a NAT, which is extremely useful.

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.

Hello! I have encountered a bug using tincd with Microsoft Windows: Below you'll find my Setup and my Logs. In short, i do the following: 1. office running tincd 1.0.7 and waiting for connections (no ConnectTo, but this does not resolve the issue) 2. the supporter starts up tincd 1.0.7 on windows (native) 3. ping from windows ("support") to the office: Here the error occours:

Hello, this morning I apparently had tinc crash on me. In 2 independent tinc clusters of 3 nodes each (but located in the same datacenter), one tinc process crashed in each of the clusters. One process apparently with `status=6/ABRT`, the other with `status=11/SEGV`. Interestingly, they crashed with only 5 minutes difference. The only thing I can come up with that might explain this correlation

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

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

I'm running tinc 1.1pre11 with AutoConnect set to 'yes' and I recently started seeing lots of these messages on my VPN and cannot connect to various hosts from other hosts: (I have obscured the hostnames and vpn name, but otherwise this is a direct paste from syslog) Aug 19 14:51:51 AAA tinc.nnn[2217]: Got REQ_KEY from XXX while we already started a SPTPS session! Aug 19 14:51:54 AAA

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, I am testing tinc for a very large scale deployment. I am using tinc-1.1 for testing. test results below are for tinc in switch mode. all other settings are default. test is performed in LAN env. 2 different hosts. I am getting only 24.6 Mbits/sec when tinc is used. without tinc on the same hosts/link I get 95 to 100 Mbits/sec using iperf. Over Tinc: iperf -c 192.168.9.9 -b 100m -l 32k -w

Hi I have some problems with my vpn. Im running version 1.1pre15 on all nodes. I have four nodes in my network. Node1 -> connects to Node2 Node2 -> connects to Node1 Node3 -> connects to Node1 and Node2 Node4 -> connects to Node1 and Node2 The problem is the connection between Node3 and Node4. The traffic is going via Node1 and Node2. Its unstable. package drops almost all the time

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,

I've been using SPTPS (a.k.a ExperimentalProtocol) for a while now, but I've only recently started looking into the details of the protocol itself. I have some questions about the design: - I am not sure what the thread model for SPTPS is when compared with the legacy protocol. SPTPS is vastly more complex than the legacy protocol (it adds a whole new handshake mechanism), and

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