similar to: Some questions about SPTPS

Hi, I'm currently trying to troubleshoot what appears to be a very subtle bug (most likely a race condition) in SPTPS that causes state to become corrupted during SPTPS key regeneration. The tinc version currently deployed to my production nodes is git 7ac5263, which is somewhat old (2014-09-06), but I think this is still relevant because the affected code paths haven't really changed

I sent you a pull request that addresses the general issue, at least for the short term: https://github.com/gsliepen/tinc/pull/83 On 16 May 2015 at 19:36, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > >> I believe there is a design flaw in the way SPTPS key regeneration >> works, because upon reception of

Hi all! I still have never managed to fully wrap my head around how UDP data tunnels can be established between nodes. Everytime I think I understand it, I see something that confuses me again Just now I am seeing the following: I have nodes A, B + C A has everybody's keys and host configuration files. B and C only have A's key, and host config with A's public IP address. B and

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,

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

Hi, Etienne I took a look for the below host configuration parameter (IndirectData), the default is no. For the below example: A ConnectTo B, B ConnectTo C: If IndirectData = no (default), then A wouldn’t establish direct connection with C, but will be forwarded by B. If IndirectData = yes, then A will try to establish direct connection with C, even though A don’t have the statement of

On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > I believe there is a design flaw in the way SPTPS key regeneration > works, because upon reception of the KEX message the other nodes will > send both KEX and SIG messages at the same time. However, the node > expects SIG to arrive after KEX. Therefore, there is an implicit > assumption that messages won't

On 09/02/2016 08:51 PM, Etienne Dechamps wrote: > What version of tinc are you using? tinc 1.1 already does what you want out of > the box: packets sent from node A to node B through node C will use a key that > A and B will negotiate between themselves. C doesn't have the key, and will > act as a blind relay. C will not be able to decipher the packets flowing > between A and B.

Is SPTPS protocol enabled in 1.1 by default? Or we need to manually enable it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180316/2360e357/attachment.html>

Hi there, we're using tinc to mesh together hosts in a public datacenter (instead of using a private VLAN, sort of). So all hosts are reasonably modern; connections are low latency with an available bandwith of around 500Mbit/s or 1Gbit/s (depending on how close they are to each other). Iperf between two nodes directly reports around 940Mbit/s. The CPUs are Intel(R) Core(TM) i7-4770 CPU @

Hi, Etienne In addition, is there any option or switch can turn of the automatic direct connection? For the example below, even A has the route to C and can establish UDP connection directly, but I need the traffic to go through B, how can I achieve that easily? (instead of remove something from A’s routing table, or manually block the connection between A and C) > On 1 May 2017, at 6:28 PM,

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

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

On 13 April 2018 at 19:34, Alex Corcoles <alex at corcoles.net> wrote: > > Note that it would be easier to set up tinc nodes on your Windows > > desktop and Linux laptops, to avoid the additional complication of > > having to relay broadcast packets between your local networks and the > > tinc network. This is what I do in my setup. > > But both systems will

It seems like that kind of problem could be solved by making sure that tinc continues PINGing over TCP metaconnections even when an UDP tunnel is established, to keep the metaconnection alive. In fact I was under the impression that the 1.1 branch already did that or that I had submitted some code to do that at some point in the past, but it looks like I maybe be misremembering things. On 13

On Sun, May 17, 2015 at 07:46:45PM +0100, Etienne Dechamps wrote: > I sent you a pull request that addresses the general issue, at least > for the short term: https://github.com/gsliepen/tinc/pull/83 Merged. > > You are right. The main issue with the SPTPS datagram protocol is that > > it actually doesn't handle any packet loss or reordering during > > authentication

With pleasure we announce the release of tinc version 1.1pre12. Here is a summary of the changes: * Added a "--syslog" option to force logging to syslog even if running in the foreground. * Fixes and improvements to the DecrementTTL function. * Improved PMTU discovery and UDP keepalive probes. * More efficient relaying of UDP packets through intermediate nodes. * Improved

With pleasure we announce the release of tinc version 1.1pre12. Here is a summary of the changes: * Added a "--syslog" option to force logging to syslog even if running in the foreground. * Fixes and improvements to the DecrementTTL function. * Improved PMTU discovery and UDP keepalive probes. * More efficient relaying of UDP packets through intermediate nodes. * Improved

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

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.