gmane.network.tinc.devel

[Announcement] Tinc version 1.0.21 and 1.1pre7 released

Guus Sliepen — 2013-04-22T20:00:34

Because of a security vulnerability in tinc that was recently discovered, we
hereby release tinc versions 1.0.21 and 1.1pre7. Here is a summary of the
changes in tinc 1.0.21:

 * Drop packets forwarded via TCP if they are too big (CVE-2013-1428).

Here is a summary of the changes in tinc 1.1pre7:

 * Fixed large latencies on Windows.
 * Renamed the tincctl tool to tinc.
 * Simplified changing the configuration using the tinc tool.
 * Added a full description of the ExperimentalProtocol to the manual.
 * Drop packets forwarded via TCP if they are too big (CVE-2013-1428).

Thanks to Martin Schobert for auditing tinc and reporting the vulnerability.
He discovered a potential stack overflow that can be triggered by an
authenticated peer. This can be used to cause a tinc daemon to crash, or in the
worst case, it might be possible to execute code on another node as the user
running tincd. This bug has been present in all versions of tinc. All users of
tinc should upgrade to 1.0.21 or 1.1pre7 as soon as possible.

Re: Automatic exchange of dynamic node-IPs between nodes

Guus Sliepen — 2013-03-28T19:39:17


Tinc 2.0 will use certificates but not X.509 ones. However, I do plan to
support the possibility to have a central entity assign Subnets to nodes.

Re: Automatic exchange of dynamic node-IPs between nodes

Rene Bartsch — 2013-03-28T11:13:40

2013/3/26 Guus Sliepen <guus< at >tinc-vpn.org>:

Luckily, no. In Germany we have a traditional 24 hours timeout on the
DSL connections which causes a new IP via PPPOE. By pulling the plug
on the routers at different times you can manipulate the time of day
they get disconnected. Because of VoIP some ISPs are going for a
180-day-timeout, now. But no fixed IPs or reverse DNS for Consumers.
The business model of our ISPs is simple. Consumers pay 25-40 €/month
for an internet socket with a flatrate but get only dynamic IPs and
can't set up their own server services (like NAS, P2P social Network,
...). So they have to pay extra for "Cloud"-services an entrust their
private data to cloud-service providers. Companies can get internet
sockets with a flatrate and fixed IP(s) for 100 - 500 €/month.

I personally like the idea of a static global IPv6 unicast prefix for
incoming connections and dynamic global IPv6 unicast prefix for
outgoing connections. That way you can be reached and still have a
little anonymity on t

Re: Automatic exchange of dynamic node-IPs between nodes

Guus Sliepen — 2013-03-26T22:31:42


I hope they are not all changing at the same instant...


Yes, that is indeed one of the things I will implement at some point (although
the host-up script you use is doing the job quite well). In tinc version
1.1pre4 and later complement this with the AutoConnect option and by
automatically distributing the public keys of nodes, if you use the
ExperimentalProtocol option.

Automatic exchange of dynamic node-IPs between nodes

Bartsch, Rene — 2013-03-26T11:45:48

Hi,

I'm new to Tinc, so a "Hello" to all! :-)

In my setup one master node has a static public IP. All other nodes have dynamic public IPs changing every 24 hours (and yes, in Germany even Global IPv6 Unicast Prefixes are dynamic on DSL/Cable sockets :-( ).

To distribute the dynamic node-IPs to all other nodes, the following "host-up" script is used:

------------------------------------------------------------- snip --------------------------------------------------------------

#!/bin/bash

FILE="/etc/tinc/$NETNAME/hosts/$NODE"
ADDRESS="Address = $REMOTEADDRESS $REMOTEPORT"

if grep -q Address $FILE; then
    /bin/sed s:'^Address.*=.*$':"$ADDRESS": -i $FILE
else
    echo $ADDRESS >> $FILE
fi

------------------------------------------------------------- snap 
--------------------------------------------------------------


Please implement such a function directly into the Tinc code! Maybe even with distributed tables without the need of a master with a static IP.

Best regards,

Renne

Re: Problem with local Discovery in tinc-pre

muh Kuh — 2013-03-14T23:08:23


I removed Compression = 9 completly from all corresponding hostfiles
(alphalabs, slowpoke and Lassulus). The error still occurs.

Re: Problem with local Discovery in tinc-pre

Guus Sliepen — 2013-03-14T13:17:48


[...]


Try removing Compression = 9, and let me know if you still see the same packet
loss or not.

Problem with local Discovery in tinc-pre

muh Kuh — 2013-03-12T19:52:29

I'm currently running tinc-pre6 on 2 nodes in a larger network.
My Laptop (Lassulus), lan ip: 192.168.2.100, tinc-ip: 10.243.0.2
My Server (alphalabs), lan ip: 192.168.2.103, tinc-ip: 10.243.1.10
internet vserver (slowpoke), no lan ip, tinc-ip: 10.243.232.121

Everything works fine until both nodes are in the same LAN. The first
2-3 minutes everything is fine. Pings between the machines go through
other servers so they are between 50-80ms, 0% packet loss.
But as soon as localDiscovery starts to kick in the pings drop to 20ms
(which is good) but packet loss goes up to 90% (tested with ping -f).
For every lost packet tincd (started with -D -d4) shows the Error:
"Received UDP packet from unknown source 192.168.2.103 port 655".
Every 2-3 seconds the packet loss stops and tincd reports: "UDP
address of alphalabs set to 192.168.2.103 port 655"
But after <1second the packet loss begins again with the unknown source error.

log snippet:
UDP address of alphalabs set to 192.168.2.103 port 655
UDP address of slowpoke s

Re: [Announcement] Tinc version 1.0.20 released

Guus Sliepen — 2013-03-04T11:56:19


No, local discovery makes use of the sames keys that have been exchanged for
direct UDP communication. So you don't need the public keys of all other
nodes, and it is not possible to spoof local discovery packets.

Re: [Announcement] Tinc version 1.0.20 released

folkert — 2013-03-04T10:59:07

Do the systems that see each other in the local lan, do they all need to
have each others public keys in hosts/ ? Or is it possible to let them
ask some trusted central authoritie(s) if the detected host is kosher?


Folkert van Heusden

Re: [monkeysphere] tinc-monkeysphere integration

Guus Sliepen — 2012-12-17T22:48:54


Ah, I see.


The protocol assumes there is only one key, so neither the public keys nor
their fingerprints are exchanged during the authentication phase. Tinc also
expects only one public key to be in a host config file, and if there are
multiple it will only use the first one.

A very dirty hack would be to write a program that continuously reads the log
output from tinc, and when it sees an unsuccesful connection has been made to a
node, it will replace the public key in its host config file with another one.
Since tinc rereads the host config file on every retry, it will use the new key
when trying to reconnect.

But perhaps it's better to ensure that only the key will be used which is
signed by the uid of the corresponding host itself. If there still are multiple
keys, use the one which has the newest signature from the host itself.

Re: [monkeysphere] tinc-monkeysphere integration

Clint Adams — 2012-12-17T16:45:34

It is possible for there to be more than one Monkeysphere-validated
key for a userid, and no way of knowing which of those is the
"correct" one.

The solution for ssh involves generating an authorized_keys
file with all valid, matching keys.

Presumably this cannot currently be done with tinc.

Re: [monkeysphere] tinc-monkeysphere integration

Guus Sliepen — 2012-12-16T13:13:02


Why do you need multiple keys per node for Monkeysphere?

Another suggestion for putting tinc to good use

Michael Adams — 2012-12-16T06:15:43

A while back, I suggested adding some compressors to tinc to increase the 
options available for its use: never had the time to take a crack at doing 
such adding. I have found something else that may or may not be a good fit 
with tinc: a WAN-optimization/delta compression mechanism. Such mechanisms 
reduce the amount of traffic carried over a network, by detecting and 
omitting duplicate content.

http://wanproxy.org/tools.shtml

http://www.ezrentacar.com | http://www.facebook.com/ezrentacar

Re: Kernel 3.7 has a new layer-2 UDP networking mechanism

Guus Sliepen — 2012-12-11T20:40:32


It neither hurts nor helps tinc. You should be able to use VXLAN inside a tinc
VPN without any problems, both in router and switch mode.

The only problem I see with VXLAN is that nowhere in the draft of the standard
there is any reference to MTU issues. It is likely that most VXLAN packets will
be fragmented into two IP packets which will decrease bandwidth and effectively
increase packet loss.

Kernel 3.7 has a new layer-2 UDP networking mechanism

Michael Adams — 2012-12-11T17:00:07

http://linux-network-plumber.blogspot.com.es/2012/09/just-published-linux-kernel.html

http://blog.scottlowe.org/2011/12/02/examining-vxlan/

Not sure how this would help or hurt tinc-vpn

Re: tinc1.1pre4 tincctl restart

muh Kuh — 2012-12-06T01:02:43

Ignore that, had 1.1pre2 installed

tinc1.1pre4 tincctl restart

muh Kuh — 2012-12-06T00:31:59

I cant restart my tincd with 'tincctl restart -n $NETNAME'
I get the message: 'Could not restart tinc daemon'

It works with 'tincctl stop -n NETNAME && tincctl start -n NETNAME'
but sometimes the /var/run/tinc.$NETNAME.pid file is missing so I need
to kill tinc manually

question using android JNI with openssl,etc. to build tinc

Steven Bishop — 2012-07-30T15:04:38

Hello,
I was hoping someone already had experience on using JNI and could
help me figure out how android.mk file uses pre-built libraries with
Android SDK. I have done some research and ordered an Android NDK
book, although I am sitting at work wanting to do something(since I
have nothing to do). I know openssl and zlib libraries are able to be
found in Android SDK, which would just require LZO to be ported.
Thanks

SPAM Blokkering van uw lopende rekening bij de RABOBANK -een dringend bericht.

2012-07-09T14:47:02

[Announcement] Version 1.0.19 released

Guus Sliepen — 2012-06-25T18:07:52

With pleasure we announce the release of version 1.0.19. Here is a
summary of the changes:

 * Allow :: notation in IPv6 Subnets.

 * Add support for systemd style socket activation.

 * Allow environment variables to be used for the Name option.

 * Add basic support for SOCKS proxies, HTTP proxies, and proxying through an
   external command.

This version of tinc is compatible with 1.0pre8, 1.0 and later, but not
with earlier version of tinc.

gmane.network.tinc.devel

[Announcement] Tinc version 1.0.21 and 1.1pre7 released

Re: Automatic exchange of dynamic node-IPs between nodes

Re: Automatic exchange of dynamic node-IPs between nodes

Re: Automatic exchange of dynamic node-IPs between nodes

Automatic exchange of dynamic node-IPs between nodes

Re: Problem with local Discovery in tinc-pre

Re: Problem with local Discovery in tinc-pre

Problem with local Discovery in tinc-pre

Re: [Announcement] Tinc version 1.0.20 released

Re: [Announcement] Tinc version 1.0.20 released

Re: [monkeysphere] tinc-monkeysphere integration

Re: [monkeysphere] tinc-monkeysphere integration

Re: [monkeysphere] tinc-monkeysphere integration

Another suggestion for putting tinc to good use

Re: Kernel 3.7 has a new layer-2 UDP networking mechanism

Kernel 3.7 has a new layer-2 UDP networking mechanism

Re: tinc1.1pre4 tincctl restart

tinc1.1pre4 tincctl restart

question using android JNI with openssl,etc. to build tinc

*****SPAM***** Blokkering van uw lopende rekening bij de RABOBANK -een dringend bericht.

[Announcement] Version 1.0.19 released

SPAM Blokkering van uw lopende rekening bij de RABOBANK -een dringend bericht.