similar to: Any analysis on Control channel security in Tinc?

> > > What is planned for Tinc 2.0? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20180314/120783a3/attachment.html>

> > > What is planned for Tinc 2.0? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20180314/120783a3/attachment.html>

Is there performance issue with Tinc compared to alternatives? Is it still single threaded? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180314/985dfc11/attachment.html>

I meant Tinc site-site VPN deployments in US business segments. Just references if any. On Tue, Mar 20, 2018 at 1:44 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Tue, Mar 20, 2018 at 12:53:55PM -0700, al so wrote: > > > Are there any Tinc deployments in the USA in Medium sized businesses and > > small Enterprises? > > Yes. However, VPNs are Virtual *Private*

On Wed, Mar 14, 2018 at 12:36 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Wed, Mar 14, 2018 at 08:42:20AM -0700, al so wrote: > > > Is there performance issue with Tinc compared to alternatives? > > Performance depends on many variables, it is impossible to say "A is > nn% faster/slower than alternative B". The best way to check which > alternative

Earlier, my tinc topology is this: https://ibb.co/bP1EJa <https://ibb.co/bP1EJa>, let me explain a little bit: client configuration: Name = client AddressFamily = ipv4 ProcessPriority = high PingTimeout = 10 TunnelServer = yes 1. All tinc nodes configured with “IndirectData = yes”, and the lines shown on the picture with arrow means the directional “ConnectTo”, so all the tinc traffic will

Please feel free to share your own benchmarks if any in the mean time. On Wed, Mar 14, 2018 at 12:36 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Wed, Mar 14, 2018 at 08:42:20AM -0700, al so wrote: > > > Is there performance issue with Tinc compared to alternatives? > > Performance depends on many variables, it is impossible to say "A is > nn% faster/slower

We have a tinc fan here! Although didn't address any questions. On Thu, Mar 29, 2018 at 3:10 PM, Lars Kruse <lists at sumpfralle.de> wrote: > Hello al, > > just a personal note (not via the mailinglist): > > > Is this the reason Tinc is slow on multicore platform? Almost every blog > > claims performance sucks. > > I am not sure, what your intention with

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

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

This bad use of RSA was reported back in Sept 2003. Is it fixed the latest version? tinc's real problem though is the handshake protocol, in which the client and server exchange random RSA-encrypted strings. That's raw bit strings, there's no PKCS #1 or OAEP padding, and the server is happy to act as an oracle for you too. This is a terrible way to use RSA, and usually compromises

On Fri, Sep 08, 2017 at 06:35:41AM +0800, Bright Zhao wrote: > And, I ran a constant ping from the tinc client’s IP to the tinc server’s IP, it shows, the pings are all successfully back and forth, no any packet loss during the connection drop happens, so will this help to exclude any NAT/firewall cause the connection drop? > > And as you saw from the earlier screen shot, when it

And, I ran a constant ping from the tinc client’s IP to the tinc server’s IP, it shows, the pings are all successfully back and forth, no any packet loss during the connection drop happens, so will this help to exclude any NAT/firewall cause the connection drop? And as you saw from the earlier screen shot, when it happens, it drop all tinc connections, and those connections are for different

On Wed, Mar 14, 2018 at 08:42:20AM -0700, al so wrote: > Is there performance issue with Tinc compared to alternatives? Performance depends on many variables, it is impossible to say "A is nn% faster/slower than alternative B". The best way to check which alternative has the best performance is to try them out yourself. > Is it still single threaded? Yes. -- Met vriendelijke

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

On Tue, Sep 05, 2017 at 12:27:59PM +0800, Bright Zhao wrote: > Recently, one of my tinc client always suffer connection drop, I was suspect the connection was not stable to cause this issue, and BTW, I’ve set the PingTimeout to 10 seconds already, but this situation still happens a lot sometimes, but when the connection drop happens, the connection recovery pretty fast, normally in a minutes.

On Wed, Sep 13, 2017 at 08:02:11PM +0100, Etienne Dechamps wrote: > 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

dear tinc member 1. I am having some trouble running tinc on an older Xp node. When I run the "tincd -n VPN -K" command, it tells me that it cant find the file ( see attached screenshot )' Seems like it messes up the / and \ directory symbols. 2. How would you compare the remobo and tinc services ? Remobo surely is less secure and requires direct access to a server, but a lot more

Hi, I have a question around whether there is any way to control tinc routing if you have multiple routes to the same destination. I have a three node configuration, let's call them: home -> connects to both other nodes vps1 -> a VPS, providing connection to the internet vps2 -> another VPS, also providing a connection to the internet Both vps nodes provide their own 192.168.x.0