similar to: tinc Digest, Vol 185, Issue 3

Yes, exactly. There are lots of packages exchanged between tinc processes on port 655, accounting to 99 % of the Ethernet traffic, while the virtual interface stays almost idle. Best, Maximilian Am 20. März 2020 21:09:18 MEZ schrieb Lars Kruse <lists at sumpfralle.de>: >Hello Maximilian, > >Am Fri, 20 Mar 2020 19:43:35 +0100 >schrieb Maximilian Stein <m at steiny.biz>:

Hi Lars, Am 20.03.20 um 15:43 schrieb Lars Kruse: > Did you really try the nice visualizations in the "Statistics" menu? > These should allow you to see, which protocols and which peers cause the > traffic. > > I am slightly confused, that you already took a look at the traffic, but you did > not mention, which type of traffic makes up the bulk of the excessive packets

Hallo Maximilian, Am Thu, 19 Mar 2020 16:31:57 +0100 schrieb Maximilian Stein <m at steiny.biz>: > There I learned the basic patterns of these situations (communication with > many peers on ethernet but nearly nothing on the virtual tinc link). Did you really try the nice visualizations in the "Statistics" menu? These should allow you to see, which protocols and which

Hi, thanks for your suggestion. Am 19.03.20 um 20:15 schrieb Lars Kruse: > you could write the packets via tcpdump into a file and open this pcap later in > wireshark. Wireshark should give you a good visualization of the traffic > distribution. > Or maybe you already did this without further conclusions? Yeah, this is actually what I did: record with tcpdump, than open the files in

Hello Maximilian, Am Fri, 20 Mar 2020 19:43:35 +0100 schrieb Maximilian Stein <m at steiny.biz>: > My current mitigation is to stop some tinc peers for ten seconds and to > start them again afterwards, that usually causes the excessive traffic > to stop without interrupting service too much. I am guessing now: the rise of traffic on the ethernet link is caused by packets being

Hi everybody, I am operating a tinc network with nearly 200 peers connected over the internet. Some peers are permanently connected and offer a public, fixed IP ("servers") while others are behind NAT firewalls ("clients") and connect to the former primarily. Unfortunately, sometimes (~ once a day) the traffic on the ethernet links seems to explode way beyond whats normal

Thank you Lars for the reply. Your instructions were dead on. Yes I have considered the security risks; however, I think scaleability and rapid deployment out weigh the security risks for me. On Aug 18, 2015, at 6:31 AM, Lars Kruse <lists at sumpfralle.de> wrote: > Hi, > >> Is it possible to generate one key pair? > > Maybe this is all you want to know? > openssl

Hallo, Am Thu, 19 Mar 2020 16:31:57 +0100 schrieb Maximilian Stein <m at steiny.biz>: > Do you have any idea about how to analyze the situation further? Or > about the actual reasons behind the issue? you could write the packets via tcpdump into a file and open this pcap later in wireshark. Wireshark should give you a good visualization of the traffic distribution. Or maybe you

El 1 de abril de 2018 3:34:46 CEST, Lars Kruse <lists at sumpfralle.de> escribió: >Hello Ramses, > > >Am Sun, 01 Apr 2018 01:44:01 +0200 >schrieb Ramses <ramses.sevilla at gmail.com>: > >> [..] >> >> Correct? > >in general, this is exactly the right procedure. > > >> I have installed Raspbian 7 (Wheezy). I will have problems doing

El 31 de marzo de 2018 21:13:48 CEST, Lars Kruse <lists at sumpfralle.de> escribió: >Hello Ramses, > > >Am Sat, 31 Mar 2018 17:21:52 +0200 >schrieb Ramses <ramses.sevilla at gmail.com>: > >> Can tell me someone if there is any repository to Raspbian that has >Tinc v1.1 >> to update a installed Tinc v1.0 from command apt-get? > >thankfully the

El 31 de marzo de 2018 22:17:10 CEST, Lars Kruse <lists at sumpfralle.de> escribió: >Hello Ramses, > > >Am Sat, 31 Mar 2018 22:03:25 +0200 >schrieb Ramses <ramses.sevilla at gmail.com>: > >> But what repository I need to add to the sources.list file? > >the internet out there would have told you :) > >https://wiki.debian.org/DebianExperimental >

Hi Lars, Thanks for the help ** Test 1 ** On VPN_office I use 'tcpdump -npi any icmp and host 192.168.1.3' When pinging 192.168.1.1 from client 1, with no success, I see no packet passing. When pinging 192.168.1.3 from client 1, with success, I see packet passing: IP 172.16.0.3 > 192.168.1.3: ICMP echo request, id 2648, seq 23, length 64 IP 192.168.1.3 > 172.16.0.3: ICMP echo

In most howtos it is instructed to enable port forwarding with 'echo 1 > /proc/sys/net/ipv4/ip_forward', but they don't say it's not permanent... So it was gone when I rebooted the machine. I then disabled the firewall on the VPN_office machine... And it works! If obviously VPN_out must be highly secured, I guess there is no problem to disable the firewall on VPN_office?

I suspect your /64.. try giving a single address to two seperate machine so one single addresses for each. /32 . Then check your traffic. Tinc is a mesh network. If you give it millions of addresses. Then its probably checking each one. On Thu, May 2, 2019, 2:06 PM Christopher Klinge <Christ.Klinge at web.de> wrote: > Good evening, > > all of my servers where set up fresh with no

Lars, interesting - do you have an example of what that might look like in the config file? Thanks! On Sun, May 5, 2019 at 6:00 PM Lars Kruse <lists at sumpfralle.de> wrote: > Hello Christoph, > > I am glad, that you discovered the source of the problem! > > > Am Sat, 4 May 2019 08:30:28 +0200 > schrieb "Christopher Klinge" <Christ.Klinge at web.de>:

Hi Lars, I am using Ubuntu 18.04.2 at Digital Ocean hosting. The server is running MariaDB 10.3 and Postfix 3.3 and little else. With your help I finally have my existing configuration working so it was not eventually an error with the config files but with the start process. These are the sequence of commands which eventually got everything working for me Note that I now have in addition to

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