similar to: Packet loss with LocalDiscovery

Hi, I was previously using tinc-1.1pre8 and it worked just fine, but after upgrading to tinc-1.1pre10 my Windows machine is unable to connect to my tinc network, as it fails to complete the handshake. Steps to reproduce: - Set up a Linux node with tinc-1.1pre10 using "tinc init" - Set up a Windows node with tinc-1.1pre10 using "tinc init", and try to make it connect to the

Hi Guus, Am Freitag, den 25.09.2015, 09:36 +0200 schrieb Guus Sliepen: > On Fri, Sep 25, 2015 at 08:41:06AM +0200, Marcus Schopen wrote: > > > I'm running some tinc clients behind a NAT (masquerading, Cisco Router) > > connecting to a host outside on a public IP in a different network. The > > tunnels get unstable every few minutes and I see packet loss when > >

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

We are testing tinc inside Google Compute within a single region and an external region. Two boxes are created as follows: /etc/tinc/test/tinc_test_1 Subnet = 10.240.0.0/16 Subnet = 10.240.0.4/32 Address = 104.154.59.151 /etc/tinc/test/tinc_test_2 Subnet = 10.240.0.0/16 Subnet = 10.240.0.5/32 Address = 104.197.132.141 /etc/tinc/test/tinc.conf Name = $HOST AddressFamily = ipv4 Interface = tun0

Hi, I am playing with LocalDiscovery again and have noticed that I do not see any LocalDiscovery broadcasts anymore. I am using tinc 1.1-pre9 in switch mode and have set LocalDiscovery = yes in tinc.conf. I do not see any broadcasts on any network and I also do not see anything in the debug output. What to do? -nik -- # apt-assassinate --help Usage: apt-assassinate [upstream|maintainer]

Hi, I´m using Tinc for several years, but I didn´t fix a performance problem. There a about 20 nodes in this network. Master: 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) tinc.conf: Name = TincKnoten12 AddressFamily = ipv4 Interface = tun ProcessPriority=high mode = router #DirectOnly = no Compression=0 PMTUDiscovery = yes #IndirectData = yes #ReplayWindow = 64 #ConnectTo

Hi, I have tried the LocalDiscovery feature of tinc. The problem is that it also sends broadcast probes out the CPN interface *and* detects nodes on the VPN. A connection is then established through the tunnel, which effectively breaks connectivity between the two nodes. I do not think that discovering hosts on the VPN makes sense in any way. How can it be disabled? I could easily netfilter

LocalDiscovery works by sending some of the MTU probe packets to the broadcast address (255.255.255.255). If the destination node receives one of these packets, it will update its UDP cache and reply, thus the two nodes will start using their local addresses to communicate. Now, I see two problems with this approach: - In case the two nodes are behind the same NAT and can reach other *but*

Hi everyone, you can find the current version of my enhanced tinc using subversion: svn://tardyon.mon-clan.de/tinc I allowed anonymous read access, so feel free to download the sources. Unfortunately, my enhancements are based on a rather old git-checkout from Guus. The version should run under windows and Debian/Ubuntu. Best, Daniel -----Original Message----- From: folkert [mailto:folkert

Hello tinc users! Has anyone been able to get LocalDiscovery to work properly? I'm not quite sure what I need to do other than enable it in tinc.conf, and it doesnt seem to be working. Has anyone else tried it? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160901/5698fc86/attachment.html>

With pleasure we announce the release of tinc version 1.0.20. Here is a summary of the changes: * Use /dev/tap0 by default on FreeBSD and NetBSD when using switch mode. * Minor improvements and clarifications in the documentation. * Allow tinc to be cross-compiled with Android's NDK. * The discovered PMTU is now also applied to VLAN tagged traffic. * The LocalDiscovery option now

With pleasure we announce the release of tinc version 1.0.20. Here is a summary of the changes: * Use /dev/tap0 by default on FreeBSD and NetBSD when using switch mode. * Minor improvements and clarifications in the documentation. * Allow tinc to be cross-compiled with Android's NDK. * The discovered PMTU is now also applied to VLAN tagged traffic. * The LocalDiscovery option now

Hi, I propose that the "ad-hoc connections" (localdiscovery) are also displayed in the graph (graphdumpfile) as it is useful for debugging. I find the command-line tooling a bit cumbersome to find out where the problem is - maybe a web-interface can be added to tincd? Implementing a http server is trivial I found out. Folkert van Heusden -- Curious about the inner workings of your

Hi All, Sorry for disturbing you if the issues has been discussed earlier but I cannot find clear explanation of my problem. Tracing the tinc logs (a debug level) I have found that the MTU value of the connection is determined and chosen at the beginning of the tunnel setup. My question is following: is the MTU value renegotiated / rechecked after the tunnel is established? The question

Hi, I'm using LocalDiscovery = yes to let tinc clients connect directly behind a NAT. Problem is that clients only start to talk directly after pinging each client from each client. Is there way to force direct connection after starting the tunnel. Ciao!

Am Freitag, den 25.09.2015, 22:45 +0200 schrieb Marcus Schopen: > Hi Guus, > > Am Freitag, den 25.09.2015, 17:46 +0200 schrieb Marcus Schopen: > > Hmmm ... I've tried "LocalDiscovery = yes" > > in /etc/tinc/mytunnel/tinc.conf already, but that didn't help. Config on > > client A is: > > > > --------------- > > Name = clienta >

Hi Guus and List, Since the CVE-2013-1428 was announced, I followed the recommendation to update my windows machines to tinc1.1pre7. I've had connectivity issues since upgrading. I've done some debugging but I can't figure out when or why its happening. All machines on the network are running Windows 7 or Windows 2008R2 Enterprise server and tinc 1.1pre7. I've got one master

On Tue, Feb 14, 2017 at 3:43 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > Hang on a second. I've just re-read your original message and I > believe you are confused about what the "Subnet" option does. Again, > it deals with addresses *inside* the VPN. In the configuration you > posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal >

On Tue, Feb 14, 2017 at 1:22 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > > Can you specify which version of tinc you're using? There are vast differences in the way LocalDiscovery works between 1.0 and 1.1. The former uses broadcast, the latter unicast to explicitly advertised local addresses. I'm using tinc 1.1pre14. I noticed there's an option,

I've noticed some inconsistent performance with some of my tunnels and thought I would take some of the spare free time I have over the holidays to try to figure out what the cause of that may be. My environment in this case is my home LAN. Please forgive my use of the terms "server" and "client" in this email, I only use these terms to simply explanation. I statically