<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Good evening,</div> <div> </div> <div>all of my servers where set up fresh with no other applications running besides tinc and my ssh sessions. I just double checked and those are the two only processes on my machines that have active sockets. Additionally, the SSH sessions do not go through the VPN, but are set up directly to the machines. Does tinc provide a way for differentiating between between meta and payload traffic?</div> <div> <div> </div> <div>Kind regards and thanks for your time,</div> <div>Christopher</div> <div> </div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 01. Mai 2019 um 23:29 Uhr<br/> <b>Von:</b> "Lars Kruse" <lists@sumpfralle.de><br/> <b>An:</b> tinc@tinc-vpn.org<br/> <b>Betreff:</b> Re: very high traffic without any load</div> <div name="quoted-content">Hello Christopher,<br/> <br/> <br/> Am Wed, 1 May 2019 12:37:33 +0200<br/> schrieb "Christopher Klinge" <Christ.Klinge@web.de>:<br/> <br/>> There is however a large amount of management traffic which I assume should<br/> > not be the case.<br/><br/> indeed - I never noticed an unreasonable amount of tinc management traffic<br/> with any of my setups.<br/> <br/> How exactly did you verify, that tinc meta traffic is really the culprit?<br/> Did you compare the traffic over your uplink interface with the traffic<br/> over the tinc interface?<br/> Maybe there is just a huge amount of payload traffic exchanged between the<br/> nodes over the tinc VPN?<br/> Since you are using "switch" mode, this could even be broadcast traffic.<br/> <br/> Cheers,<br/> Lars<br/> _______________________________________________<br/> tinc mailing list<br/> tinc@tinc-vpn.org<br/> <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a></div> </div> </div> </div></div></body></html>
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 other applications running > besides tinc and my ssh sessions. I just double checked and those are the > two only processes on my machines that have active sockets. Additionally, > the SSH sessions do not go through the VPN, but are set up directly to the > machines. Does tinc provide a way for differentiating between between meta > and payload traffic? > > Kind regards and thanks for your time, > Christopher > > *Gesendet:* Mittwoch, 01. Mai 2019 um 23:29 Uhr > *Von:* "Lars Kruse" <lists at sumpfralle.de> > *An:* tinc at tinc-vpn.org > *Betreff:* Re: very high traffic without any load > Hello Christopher, > > > Am Wed, 1 May 2019 12:37:33 +0200 > schrieb "Christopher Klinge" <Christ.Klinge at web.de>: > > > There is however a large amount of management traffic which I assume > should > > not be the case. > > indeed - I never noticed an unreasonable amount of tinc management traffic > with any of my setups. > > How exactly did you verify, that tinc meta traffic is really the culprit? > Did you compare the traffic over your uplink interface with the traffic > over the tinc interface? > Maybe there is just a huge amount of payload traffic exchanged between the > nodes over the tinc VPN? > Since you are using "switch" mode, this could even be broadcast traffic. > > Cheers, > Lars > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20190502/ba631195/attachment.html>
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>I will test this ASAP, but can you elaborate as to why this would happen? If there is no payload traffic in the VPN, there should be no reason to query for IP addresses. And if tinc switches do query for addresses without cause, why would they query for each possible address individually? When an entire subnet is assigned to one node, shouldn't that suffice? Even if two nodes had the same subnet assigned to them, a switch should simply multicast to both peers to find the target of a connection. Am I missing something important? <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Donnerstag, 02. Mai 2019 um 20:38 Uhr<br/> <b>Von:</b> "Absolute Truth" <requiredtruth@gmail.com><br/> <b>An:</b> tinc@tinc-vpn.org<br/> <b>Betreff:</b> Re: Re: very high traffic without any load</div> <div name="quoted-content"> <div>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.</div> <div class="gmail_quote"> <div class="gmail_attr">On Thu, May 2, 2019, 2:06 PM Christopher Klinge <<a href="mailto:Christ.Klinge@web.de" onclick="parent.window.location.href='mailto:Christ.Klinge@web.de'; return false;" target="_blank">Christ.Klinge@web.de</a>> wrote:</div> <blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex;border-left: 1.0px rgb(204,204,204) solid;padding-left: 1.0ex;"> <div> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>Good evening,</div> <div> </div> <div>all of my servers where set up fresh with no other applications running besides tinc and my ssh sessions. I just double checked and those are the two only processes on my machines that have active sockets. Additionally, the SSH sessions do not go through the VPN, but are set up directly to the machines. Does tinc provide a way for differentiating between between meta and payload traffic?</div> <div> <div> </div> <div>Kind regards and thanks for your time,</div> <div>Christopher</div> <div> </div> <div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);"> <div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Mittwoch, 01. Mai 2019 um 23:29 Uhr<br/> <b>Von:</b> "Lars Kruse" <<a href="mailto:lists@sumpfralle.de" onclick="parent.window.location.href='mailto:lists@sumpfralle.de'; return false;" target="_blank">lists@sumpfralle.de</a>><br/> <b>An:</b> <a href="mailto:tinc@tinc-vpn.org" onclick="parent.window.location.href='mailto:tinc@tinc-vpn.org'; return false;" target="_blank">tinc@tinc-vpn.org</a><br/> <b>Betreff:</b> Re: very high traffic without any load</div> <div>Hello Christopher,<br/> <br/> <br/> Am Wed, 1 May 2019 12:37:33 +0200<br/> schrieb "Christopher Klinge" <<a href="mailto:Christ.Klinge@web.de" onclick="parent.window.location.href='mailto:Christ.Klinge@web.de'; return false;" target="_blank">Christ.Klinge@web.de</a>>:<br/> <br/>> There is however a large amount of management traffic which I assume should<br/> > not be the case.<br/><br/> indeed - I never noticed an unreasonable amount of tinc management traffic<br/> with any of my setups.<br/> <br/> How exactly did you verify, that tinc meta traffic is really the culprit?<br/> Did you compare the traffic over your uplink interface with the traffic<br/> over the tinc interface?<br/> Maybe there is just a huge amount of payload traffic exchanged between the<br/> nodes over the tinc VPN?<br/> Since you are using "switch" mode, this could even be broadcast traffic.<br/> <br/> Cheers,<br/> Lars<br/> _______________________________________________<br/> tinc mailing list<br/> <a href="mailto:tinc@tinc-vpn.org" onclick="parent.window.location.href='mailto:tinc@tinc-vpn.org'; return false;" target="_blank">tinc@tinc-vpn.org</a><br/> <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a></div> </div> </div> </div> </div> </div> _______________________________________________<br/> tinc mailing list<br/> <a href="mailto:tinc@tinc-vpn.org" onclick="parent.window.location.href='mailto:tinc@tinc-vpn.org'; return false;" target="_blank">tinc@tinc-vpn.org</a><br/> <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a></blockquote> </div> _______________________________________________ tinc mailing list tinc@tinc-vpn.org <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a></div> </div> </div> </div></div></body></html>
Hello Christoph, Am Thu, 2 May 2019 19:42:25 +0200 schrieb "Christopher Klinge" <Christ.Klinge at web.de>:> all of my servers where set up fresh with no other applications running > besides tinc and my ssh sessions.Did you try something as simple as "tcpdump -npi TINC_INTERFACE"? This should give you a good impression of the traffic flowing through the VPN. Cheers, Lars
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi again,</div> <div> </div> <div>I did some digging, and thus far I could not find any other culprit other than tinc itself. The packages that are being sent are addressed directly to the other tinc hosts on their vpn addresses. During my latest tests, within about 12 seconds 100MB of data were transmitted this way. I captured this test in wireshark. Sadly, I lack the expertise of understanding what is happening.</div> <div> </div> <div>At the very beginning, normal connections are being set up and a few ICMP neighbor advertisements/solicitations are being exchanged. Next a short TCP session was created between the public IP addresses of two of my hosts, through the VPN. This is something that I would like to support and theoretically it should be possible. However, to me it looks like the connection could not be established. Right afterwards, one of the nodes involved in the TCP connection and the third node I used for testing started exchaning the weird packages that I am complaining about.</div> <div> </div> <div>They are UDP packets varying in size and as far as I can tell unrelated to any outside application. All of them belong to one connection. If anyone would like to take a look at the dump itself, I'll provide it directly, since I don't want to make all of my servers' addresses public.</div> <div> </div> <div>Warning, wall of text incoming:</div> <div> <div> <div>Source Destination Protocol Length Info<br/> node01-public node04-public TCP 929 tinc(655) → 40690 [PSH, ACK] Seq=1 Ack=1 Win=240 Len=843 TSval=66121145 TSecr=65947641<br/> node01-public node04-public TCP 1294 tinc(655) → 40690 [ACK] Seq=844 Ack=1 Win=240 Len=1208 TSval=66121145 TSecr=65947641<br/> node01-public node04-public TCP 110 tinc(655) → 40690 [PSH, ACK] Seq=2052 Ack=1 Win=240 Len=24 TSval=66121145 TSecr=65947641<br/> node01-public node04-public TCP 1294 tinc(655) → 40690 [ACK] Seq=2076 Ack=1 Win=240 Len=1208 TSval=66121145 TSecr=65947641<br/> node01-public node04-public TCP 373 tinc(655) → 40690 [PSH, ACK] Seq=3284 Ack=1 Win=240 Len=287 TSval=66121145 TSecr=65947641<br/> node01-public node04-public TCP 1294 tinc(655) → 40690 [ACK] Seq=3571 Ack=1 Win=240 Len=1208 TSval=66121145 TSecr=65947641<br/> node01-public node04-public TCP 636 tinc(655) → 40690 [PSH, ACK] Seq=4779 Ack=1 Win=240 Len=550 TSval=66121145 TSecr=65947641<br/> node01-public node04-public TCP 1294 tinc(655) → 40690 [ACK] Seq=5329 Ack=1 Win=240 Len=1208 TSval=66121149 TSecr=65947641<br/> node01-public node04-public TCP 899 tinc(655) → 40690 [PSH, ACK] Seq=6537 Ack=1 Win=240 Len=813 TSval=66121149 TSecr=65947641<br/> node01-public node04-public TCP 1294 tinc(655) → 40690 [ACK] Seq=7350 Ack=1 Win=240 Len=1196 TSval=66121196 TSecr=65947693 SLE=4294967052 SRE=1<br/> node01-public node04-public TCP 1294 tinc(655) → 40690 [ACK] Seq=8546 Ack=1 Win=240 Len=1208 TSval=66121200 TSecr=65947693<br/> node01-public node04-public TCP 98 [TCP Dup ACK 63#1] tinc(655) → 40690 [ACK] Seq=9754 Ack=1 Win=240 Len=0 TSval=66121248 TSecr=65947745 SLE=4294967052 SRE=1<br/> node01-public node04-public TCP 1294 tinc(655) → 40690 [ACK] Seq=9754 Ack=1 Win=240 Len=1208 TSval=66121252 TSecr=65947745<br/> node01-public node04-public TCP 929 [TCP Retransmission] tinc(655) → 40690 [PSH, ACK] Seq=1 Ack=1 Win=240 Len=843 TSval=66121304 TSecr=65947745<br/> node01-public node04-public TCP 98 [TCP Dup ACK 63#2] tinc(655) → 40690 [ACK] Seq=10962 Ack=1 Win=240 Len=0 TSval=66121351 TSecr=65947848 SLE=4294967052 SRE=1<br/> node01-public node04-public TCP 929 [TCP Retransmission] tinc(655) → 40690 [PSH, ACK] Seq=1 Ack=1 Win=240 Len=843 TSval=66121408 TSecr=65947848<br/> node01-public node04-public TCP 98 [TCP Dup ACK 63#3] tinc(655) → 40690 [ACK] Seq=10962 Ack=1 Win=240 Len=0 TSval=66121559 TSecr=65948056 SLE=4294967052 SRE=1<br/> node01-public node04-public TCP 929 [TCP Retransmission] tinc(655) → 40690 [PSH, ACK] Seq=1 Ack=1 Win=240 Len=843 TSval=66121616 TSecr=65948056<br/> node02-vpn ff02::1:ff00:4 ICMPv6 86 Neighbor Solicitation for 1111:1::4 from 96:6a:04:92:56:4e<br/> fe80::946a:4ff:fe92:564e ff02::1:ff00:4 ICMPv6 86 Neighbor Solicitation for 1111:1::4 from 96:6a:04:92:56:4e<br/> node01-public node04-public TCP 98 [TCP Dup ACK 63#4] tinc(655) → 40690 [ACK] Seq=10962 Ack=1 Win=240 Len=0 TSval=66121975 TSecr=65948472 SLE=4294967052 SRE=1<br/> node01-public node04-public TCP 929 [TCP Retransmission] tinc(655) → 40690 [PSH, ACK] Seq=1 Ack=1 Win=240 Len=843 TSval=66122032 TSecr=65948472<br/> node02-vpn ff02::1:ff00:4 ICMPv6 86 Neighbor Solicitation for 1111:1::4 from 96:6a:04:92:56:4e<br/> node02-vpn ff02::1:ff00:4 ICMPv6 86 Neighbor Solicitation for 1111:1::4 from 96:6a:04:92:56:4e<br/> fe80::1471:c8ff:fe7b:1003 1111:1::4 ICMPv6 86 Neighbor Solicitation for 1111:1::4 from 16:71:c8:7b:10:03<br/> fe80::1471:c8ff:fe7b:1003 1111:1::4 ICMPv6 86 Neighbor Solicitation for 1111:1::4 from 16:71:c8:7b:10:03<br/> node01-public node04-public TCP 98 [TCP Dup ACK 63#5] tinc(655) → 40690 [ACK] Seq=10962 Ack=1 Win=240 Len=0 TSval=66122815 TSecr=65949312 SLE=4294967052 SRE=1<br/> node01-public node04-public TCP 929 [TCP Retransmission] tinc(655) → 40690 [PSH, ACK] Seq=1 Ack=1 Win=240 Len=843 TSval=66122880 TSecr=65949312<br/> fe80::1471:c8ff:fe7b:1003 1111:1::4 ICMPv6 86 Neighbor Solicitation for 1111:1::4 from 16:71:c8:7b:10:03<br/> fe80::1471:c8ff:fe7b:1003 ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 1111:1::1 from 16:71:c8:7b:10:03<br/> node02-vpn fe80::1471:c8ff:fe7b:1003 ICMPv6 86 Neighbor Advertisement 1111:1::1 (sol, ovr) is at 96:6a:04:92:56:4e<br/> node01-vpn node01-public UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node01-public UDP 1294 tinc(655) → tinc(655) Len=1232<br/> node01-vpn node01-public UDP 113 tinc(655) → tinc(655) Len=51<br/> node02-vpn ff02::1:ff00:3 ICMPv6 86 Neighbor Solicitation for 1111:1::3 from 96:6a:04:92:56:4e<br/> node01-vpn node02-vpn ICMPv6 86 Neighbor Advertisement 1111:1::3 (sol, ovr) is at 16:71:c8:7b:10:03<br/> node01-vpn node01-public UDP 113 tinc(655) → tinc(655) Len=51<br/> node02-vpn node01-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node02-vpn node01-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node02-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node02-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node01-public UDP 113 tinc(655) → tinc(655) Len=51<br/> node02-vpn node01-vpn UDP 1294 tinc(655) → tinc(655) Len=1232<br/> node02-vpn node01-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node02-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node02-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node02-vpn UDP 1294 tinc(655) → tinc(655) Len=1232<br/> node02-vpn node01-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node02-vpn node01-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node02-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node01-vpn node02-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node02-vpn node01-vpn UDP 1253 tinc(655) → tinc(655) Len=1191<br/> node02-vpn node01-vpn UDP 1158 tinc(655) → tinc(655) Len=1096<br/> node02-vpn node01-vpn UDP 1063 tinc(655) → tinc(655) Len=1001<br/> node02-vpn node01-vpn UDP 968 tinc(655) → tinc(655) Len=906<br/> node02-vpn node01-vpn UDP 873 tinc(655) → tinc(655) Len=811<br/> node02-vpn node01-vpn UDP 778 tinc(655) → tinc(655) Len=716<br/> node02-vpn node01-vpn UDP 683 tinc(655) → tinc(655) Len=621<br/> node02-vpn node01-vpn UDP 1253 tinc(655) → tinc(655) Len=1191<br/> node02-vpn node01-vpn UDP 588 tinc(655) → tinc(655) Len=526<br/> node02-vpn node01-vpn UDP 1158 tinc(655) → tinc(655) Len=1096<br/> node02-vpn node01-vpn UDP 493 tinc(655) → tinc(655) Len=431<br/> node02-vpn node01-vpn UDP 1063 tinc(655) → tinc(655) Len=1001<br/> node02-vpn node01-vpn UDP 398 tinc(655) → tinc(655) Len=336<br/> node02-vpn node01-vpn UDP 968 tinc(655) → tinc(655) Len=906<br/> node02-vpn node01-vpn UDP 303 tinc(655) → tinc(655) Len=241<br/> node02-vpn node01-vpn UDP 873 tinc(655) → tinc(655) Len=811<br/> node02-vpn node01-vpn UDP 208 tinc(655) → tinc(655) Len=146<br/> node02-vpn node01-vpn UDP 778 tinc(655) → tinc(655) Len=716<br/> node02-vpn node01-vpn UDP 113 tinc(655) → tinc(655) Len=51<br/> node02-vpn node01-vpn UDP 683 tinc(655) → tinc(655) Len=621</div> <div>...</div> </div> </div> <div> </div> <div> </div> <div>Kind regards</div> <div>Christopher</div> <div> </div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Donnerstag, 02. Mai 2019 um 23:00 Uhr<br/> <b>Von:</b> "Lars Kruse" <lists@sumpfralle.de><br/> <b>An:</b> tinc@tinc-vpn.org<br/> <b>Betreff:</b> Re: very high traffic without any load</div> <div name="quoted-content">Hello Christoph,<br/> <br/> <br/> Am Thu, 2 May 2019 19:42:25 +0200<br/> schrieb "Christopher Klinge" <Christ.Klinge@web.de>:<br/> <br/>> all of my servers where set up fresh with no other applications running<br/> > besides tinc and my ssh sessions.<br/><br/> Did you try something as simple as "tcpdump -npi TINC_INTERFACE"?<br/> This should give you a good impression of the traffic flowing through the VPN.<br/> <br/> Cheers,<br/> Lars<br/> _______________________________________________<br/> tinc mailing list<br/> tinc@tinc-vpn.org<br/> <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a></div> </div> </div> </div></div></body></html>