similar to: Node to Node UDP Tunnels HOWTO?

Hi all, many thanks for the replies! On 14/05/18 19:05, Parke wrote: > On Mon, May 14, 2018 at 4:44 AM, Keith Whyte <keith at rhizomatica.org> wrote: >> but then I read that no, each host much have the key of >> the other to establish the direct connection. But I am looking at >> tcpdump right now in the terminal and seeing the UDP tunnel packets >> flowing from

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

Hi all I feel like I should know the answer to this question, like I read it someplace sometime, but it evades me right now. It's also an opportunity to say hello to the list and many thanks for writing and supporting tinc vpn! We make great use of it at rhizomatica. So, Let's take this example setup. I have two tinc nodes (A and B) behind a firewall NodeA and NodeB have 192.168.1.2

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.

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

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)

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

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 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

pc1(LANa) ----poor connection ----> VPS <--------- PC2(LANb) pc1 and pc2 used to connected directly with tinc, since pc1 used to have WAN IP(pppoe), but the pppoe IP is not WAN IP anymore (ISP changed to let all ADSL user in a LAN). if I let the two pc connect to a VPS with tinc, can later connections between pc1 and pc2 be directly ? for example, ssh from pc1 to pc2 but not proxyed by

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

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.

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 Ok I have a simple lab setup with three nodes , one acting as the "Central Node" and the other two as remote nodes which "*ConnectTo*" the central node in order to be able to communicate with each other. What I would like to know is , once the tinc remote nodes establish a connection to the "Central Node" , my understanding was that if the remote nodes want to

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

Hello, We are using tinc 1.0.24 with switch mode. Some questions regarding to the UDP connections on tinc. As far as I understand tinc is building meta connections with "ConnectTo", and "ADD_EDGE" packet. With the help of EDGE info two nodes who don't have direct meta connection are able to communicate through direct UDP connection. I understand we can dump the meta

Hi Guus, Am Freitag, den 25.09.2015, 17:04 +0200 schrieb Guus Sliepen: > Ok, that means by default the UDP NAT timeout on the Cisco is extremely > short. > > > I check the manual of the the Cisco NAT for any TCP/UDP > > timeout settings, but there is no way to modify anything like "keeps > > TCP/UDP connections alive". > > It wouldn't be called

Hi, is it possible to run two tinc hosts to make failover in case of crash of one tinc host? Or should I switch to tinc 1.1? ALBI...

Hello list, I use tinc with QOS, and since some weeks I got problem with tunnel disconnection because the default "Pingtimeout" of 5 sec is reach. I think it happens because of the QOS shappe the tinc traffic (data here) to let some BP for VOIP, but whate is very strange is that the ICMP protocol is not include in the shapping, so tinc would never 'see' latency on the link,

Hi! Me and two friends are trying to get a VPN working, but we cant get routing between two tunnels. This is how it looks, all servers (192.168.*.1) are running IP Masquerade to enable the other computers behind them to access the internet. Both elayne and glenn are connecting to melc, and the tunnel between melc and glenn are running TCPOnly because that glenn doesnt have a public IP (it's