similar to: Git repository available

Guus Sliepen, I am working in a zeroconf setup for tinc called tzk, that could allow you to make this easily https://github.com/NebTex/tzk/ it will make better readme this weekend but you need a public machine with a public domain - subdomain pointed to it, the script will install tinc, consul (that is used for coordinate the vpn), and caddy a small reverse proxy for expose consul to the public

Thanks Guus for the quick answer, I will give a try now. Рысь, In my case we don't want to restart tinc "server" at all, therefore what might happen is that the client is still connected to server while its public key was already removed from server. I will try the signal approach. Heng On Mon, Jul 25, 2016 at 12:42 PM, <tinc-request at tinc-vpn.org> wrote: > Send tinc

With pleasure we announce the release of version 1.0.9. Here is a summary of the changes: * Fixed tinc as a service under Windows 2003. * Fixed reading configuration files that do not end with a newline. * Fixed crashes in situations where hostnames could not be resolved or hosts would disconnect at the same time as session keys were exchanged. * Improved default settings of tun and tap

With pleasure we announce the release of version 1.0.9. Here is a summary of the changes: * Fixed tinc as a service under Windows 2003. * Fixed reading configuration files that do not end with a newline. * Fixed crashes in situations where hostnames could not be resolved or hosts would disconnect at the same time as session keys were exchanged. * Improved default settings of tun and tap

On Wed, May 13, 2015 at 02:59:11AM +0200, Sven-Haegar Koch wrote: > configure.ac:7: option `info-in-builddir' not recognized > autoreconf: automake failed with exit status: 1 > > Do I now need a specific newer version of automake? Yes. > Seems to be the result of commit > 13f9bc1ff199bea46 "Add support for out-of-tree ("VPATH") builds."

On Tue, May 19, 2015 at 09:39:13AM +0200, Florent B wrote: > Any news about that option ? Can't compile on Wheezy... I removed the info-in-builddir option for now. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature

With pleasure we announce the release of version 1.0.3. Here is a summary of the changes: * Show error message when failing to write a PID file. * Ignore spaces at end of lines in config files. * Fix handling of late packets. * Unify BSD tun/tap device handling. This allows IPv6 on tun devices and anything on tap devices as long as the underlying OS supports it. * Handle IPv6 on Solaris tun

With pleasure we announce the release of version 1.0.3. Here is a summary of the changes: * Show error message when failing to write a PID file. * Ignore spaces at end of lines in config files. * Fix handling of late packets. * Unify BSD tun/tap device handling. This allows IPv6 on tun devices and anything on tap devices as long as the underlying OS supports it. * Handle IPv6 on Solaris tun

On Mon, Feb 26, 2018 at 03:18:15PM -0700, Todd C. Miller wrote: > > The problem is not the order of the events, the problem is that in the > > Windows version of the event loop, we only handle one event in each loop > > iteration. The select() loop handles all events that have accumulated so > > far, so regardless of the order it handles them, it never starves fd. At >

Would it not make more sense to have this on packagers responsiblity instead like you were saying adding it into the upstream repo. Maybe have a secondary repo that people can contribute to for distribution specific files and install scripts. On 24 September 2015 at 21:30, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Thu, Sep 24, 2015 at 05:45:36PM +0200, Guus Sliepen wrote: >

On Fri, Feb 23, 2018 at 03:04:24PM -0700, Todd C. Miller wrote: > I've noticed that on Windows during large transfers (such as an > iperf run), the receiving end sometimes fails to respond to a PING. > When this happens, the sender closes the connection and both ends > have to renegotiate. > > My theory is that, due to the properties of the splay tree, the TAP > device

You have a typo in your routes: fd80:2015:2105:adcd::/6 abcd vs. adcd On 21 May 2015, at 19:35, Martin <martinmoen at gmail.com<mailto:martinmoen at gmail.com>> wrote: I have 2 nodes nodeA and nodeB I'm using tinc 1.1pre11 -- nodeA(fd80:2015:2105:abcd::1) : $ ip -6 route fd80:2015:2105:abcd::1 dev tun0 proto kernel metric 256 fd80:2015:2105:adcd::/64 dev tun0 metric 1024

Thanks Guus. Appreciate the help. What's the purpose of SUBNET msg? Is it even useful in switch mode? I tweaked the code to disable SUBNET msg, because I thought they weren't useful when it comes to switch mode. Which caused the UDP connection got blocked apparently. If I re-enable SUBNET msg, the udp connection starts to work fine. I don't see any forwarding traffic any more. On

Something to add. When this happened, it looks like tinc shutdown gracefully(not seg fault ..), because I can tell tinc-down script got implemented. Heng On Wed, Nov 25, 2015 at 6:00 AM, <tinc-request at tinc-vpn.org> wrote: > Send tinc mailing list submissions to > tinc at tinc-vpn.org > > To subscribe or unsubscribe via the World Wide Web, visit >

Thanks for the reply. I am running tinc (1.0.24) in an embedded linux environment, with a pretty old kernel (2.6). I have let tinc run for almost 24 hours with internet and can't reproduce the issue. Heng On Wed, Nov 25, 2015 at 6:00 AM, <tinc-request at tinc-vpn.org> wrote: > Send tinc mailing list submissions to > tinc at tinc-vpn.org > > To subscribe or

Thanks Guus! Looking forward to trying out tinc 1.1pre15. Can 1.1pre15 nodes coexist with 1.1pre14 nodes? Nirmal On Sat, Sep 2, 2017 at 1:47 PM Guus Sliepen <guus at tinc-vpn.org> wrote: > With pleasure we announce the release of tinc versions 1.0.32 and > 1.1pre15. > > Here is a summary of the changes in tinc 1.0.32: > > * Fix segmentation fault when using Cipher =

Thanks Guus! Looking forward to trying out tinc 1.1pre15. Can 1.1pre15 nodes coexist with 1.1pre14 nodes? Nirmal On Sat, Sep 2, 2017 at 1:47 PM Guus Sliepen <guus at tinc-vpn.org> wrote: > With pleasure we announce the release of tinc versions 1.0.32 and > 1.1pre15. > > Here is a summary of the changes in tinc 1.0.32: > > * Fix segmentation fault when using Cipher =

Thanks for the answer Guus, One more thing. I can run two tinc daemons one for each group, but I sill need to communicate clients from one group to the other. Clients from group 2 (admin group) need to reach clients from group 1 (remote server group), but clients from group 1 must not be able to reach each other nor the server. If I'm not using TunnelServer and Forwarding, How can I setup

yes, ip_forward was turned on. iptables is defaulted to ACCEPT policy on all the 3 chains. On Sat, May 14, 2016 at 1:24 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sat, May 14, 2016 at 12:06:51AM +0800, Terry T wrote: > > > I have a Debian 8 64-bit machine set up as a server and apt-got the tinc > > package. I configured tinc as a bridge and everything seems

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