Re: Local address announces

On Thu, Aug 26, 2010 at 10:09:06AM +0200, Daniel Schall wrote:

> Please find attached an archive, which contains my latest version, as
> well as a diff patch.

Hm, it still had the segfault problem, and I noticed some differences between
the diff and the tarball. I fixed the segfault, but it still did not work on my
network.

> Did you set the configuration to "LocalAnnounce = AnnounceAndReceive"?

I did set that.

> By the way, I tried to commit my changes by issuing "git push", but I
> get the error: "fatal: The remote end hung up unexpectedly" :-/
> Same if I type "git push git://tinc-vpn.org/tinc"..

You cannot push to the main git repository. You can send me your commits via
email (you can use git format-patch and send-email commands, or attach the
output of git diff to an email), or you can make your git repository public so
I can pull from it.

Anyway, since I still believe broadcasting PMTU discovery packets is easier, I
tried to implement that. The changes necessary were:

1. Find out the port a remote node is listening on on his own LAN. This
   information is available from any edge_t to that node.

2. Enable broadcast transmission and reception on the UDP sockets.

[PATCH] New '-o' option to configure server or hosts from command line

Options given on the command line have precedence over configuration 
from files.

This can be useful, for example, for a roaming node, for which 
'ConnectTo' and <host>.Address depends on its location.
---
This patch is against stable branch. Merging this patch to the 1.1 
branch is trivial.

I use this patch on my Debian for several weeks.
Here is the ifupdown script I use (some information are obfuscated with 
'X' or 'Y'):

#!/bin/sh -e

IP=X.X.X.X

post_up () {
   [ -e /sys/class/net/jmuchemb ] && return
   set -- -d -o ConnectTo=srv  -o srv.Address=$IP \
             -o ConnectTo=srv2 -o srv2.Address=Y.Y.Y.Y
   case $LOGICAL in
     wifi-amuchemb)
       set -- -o ConnectTo=srv2 -o srv2.Address=192.168.1.1
       ;;
     wifi-jmuchemb|eth-jmuchemb)
       set -- -o ConnectTo=srv -o srv.Address=192.168.2.2
       ;;
     *)
       ip route get $IP 2>&- | grep -q "^$IP \\(via [^ ]* \\)\\?dev 

[PATCH] New '-o' option to configure server or hosts from command line

Options given on the command line have precedence over configuration from files.

This can be useful, for example, for a roaming node, for which 'ConnectTo' and
<host>.Address depends on its location.
---
(Oops, Thunderbird trashed everything. Resending. Sorry.)

This patch is against stable branch. Merging this patch to the 1.1 
branch is trivial.

I use this patch on my Debian for several weeks.
Here is the ifupdown script I use (some information are obfuscated with 
'X' or 'Y'):

#!/bin/sh -e

IP=X.X.X.X

post_up () {
  [ -e /sys/class/net/jmuchemb ] && return
  set -- -d -o ConnectTo=srv  -o srv.Address=$IP \
            -o ConnectTo=srv2 -o srv2.Address=Y.Y.Y.Y
  case $LOGICAL in
    wifi-amuchemb)
      set -- -o ConnectTo=srv2 -o srv2.Address=192.168.1.1
      ;;
    wifi-jmuchemb|eth-jmuchemb)
      set -- -o ConnectTo=srv -o srv.Address=192.168.2.2
      ;;
    *)

Re: [PATCH] New '-o' option to configure server or hosts from command line

On Fri, Sep 03, 2010 at 01:34:22PM +0200, Julien Muchembled wrote:

> Options given on the command line have precedence over configuration from files.
> 
> This can be useful, for example, for a roaming node, for which 'ConnectTo' and
> <host>.Address depends on its location.

Thanks for the very nice patch! I have applied it.

> +	result = !b->file - !a->file;

I could not have done better myself :)

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>

On Fri, Sep 03, 2010 at 01:34:22PM +0200, Julien Muchembled wrote:

> Options given on the command line have precedence over configuration from files.
> 
> This can be useful, for example, for a roaming node, for which 'ConnectTo' and
> <host>.Address depends on its location.

Thanks for the very nice patch! I have applied it.

> +	result = !b->file - !a->file;

I could not have done better myself :)

RE: Local address announces

> 
> > Please find attached an archive, which contains my latest version, as
> > well as a diff patch.
> 
> Hm, it still had the segfault problem, and I noticed some differences
> between the diff and the tarball. I fixed the segfault, but it still did
not work
> on my network.
> 

I'll give it a try myself, as soon as I've got the time to have a look at
it.

> > Did you set the configuration to "LocalAnnounce = AnnounceAndReceive"?
> 
> I did set that.
> 
> > By the way, I tried to commit my changes by issuing "git push", but I
> > get the error: "fatal: The remote end hung up unexpectedly" :-/ Same
> > if I type "git push git://tinc-vpn.org/tinc"..
> 
> You cannot push to the main git repository. You can send me your commits
> via email (you can use git format-patch and send-email commands, or attach
> the output of git diff to an email), or you can make your git repository
public
> so I can pull from it.
> 
> Anyway, since I still believe broadcasting PMTU discovery packets is
easier, I
> tried to implement that. The changes necessary were:

Other feature requests

Hello,

Great to see that my patch for new '-o' command-line option has been accepted :)
It was the most important missing feature for me.
But there are other ones I'd like to see implemented:

1. push options to clients (see push/pull options of OpenVPN)
2. automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN
(see redirect-gateway of OpenVPN)
3. prevent a node from stealing an IP
4. prevent nodes from giving access to new nodes

Yes, the list is quite long and implementation is probably not trivial. You could reply that I should still
use OpenVPN, but really centralized VPN are so inefficient when clients are all around the world.
I'd like to get rid of OpenVPN completely. For my personal use, current tinc is ok (although feature 1 & 2
would be nice). I am the administrator of the OpenVPN network of my company and I'm afraid tinc does not
provide enough security (features 3 & 4).

More details on the requested features:

1. Pushing options to clients allows to centralize configuration, without having to reconfigure every
node when one decide to change IP or any other network setting.

2. redirect-gateway is a nice shortcut (especially on Windows, because currently, I don't know how to do
otherwise). I like securing wifi connection with a VPN instead of wifi encryption.

3. I don't know the status of Tinc about this. I'd like to be sure that if a node A steals the IP of another node B,
intentionally or not, B is not affected (and A just loses all packets).

4. I don't want that any client is allowed to extend the network by giving access to new nodes. I should be the

Re: Other feature requests

On Fri, Sep 10, 2010 at 01:12:48PM +0200, Julien Muchembled wrote:

> Great to see that my patch for new '-o' command-line option has been accepted :)
> It was the most important missing feature for me.
> But there are other ones I'd like to see implemented:
> 
> 1. push options to clients (see push/pull options of OpenVPN)
> 2. automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN
(see redirect-gateway of OpenVPN)
> 3. prevent a node from stealing an IP
> 4. prevent nodes from giving access to new nodes
> 
> 1. Pushing options to clients allows to centralize configuration, without
> having to reconfigure every node when one decide to change IP or any other
> network setting.

This is something not possible with the protocol used in tinc 1.x. For 2.0, I
plan to have a system to exchange and update small certificates, which could
contain configuration information for clients.

> 2. redirect-gateway is a nice shortcut (especially on Windows, because
> currently, I don't know how to do otherwise). I like securing wifi connection
> with a VPN instead of wifi encryption.

This is possible using host-up/down scripts. For example, if the tinc node
called "office" is willing to be default gateway, then you could add the
following in hosts/office-up:

#!/bin/sh
OFFICE_GW=192.168.1.1

Re: Other feature requests

i have not submitted a patch, not even a bit.

On Fri, Sep 10, 2010 at 6:12 AM, Julien Muchembled <jm@...> wrote:
> Hello,
>

Enterprise tinc needs a central/distributed repository of nodes and
configuration information.
A plugin for one of the following would go far.
DNS, OCSInventory-NG, FreeIPA (DNS, LDAP and Kerberos).

> 1. push options to clients (see push/pull options of OpenVPN)
OCSInventory-NG has ability to store configuration information and
push software and settings to remote LinMacWin clients.  But most
configuration info could be stored in a tinc accessible only DNS
server.

> 3. prevent a node from stealing an IP
Configuration information stored in LDAP and enforced by Kerberos.

> 4. prevent nodes from giving access to new nodes
FreeIPA could determine which nodes that NodeX has access to via Kerberos.

> 1. Pushing options to clients allows to centralize configuration, without
> having to reconfigure every node when one decide to change IP or any other
> network setting.

Configure each tinc client with a DNS server accessible only by tinc
clients.  Store network names, public certificates, port numbers,
dynamic ip addresses and of course hostnames in dynamic DNS.

friend of a friend type darknets

Hi!
here a little patch for darknet functionality, i hope it does what its
intended for sufficiently ... but it seems to work :).

what should it do?

imagine your friend-network. A trusts B and C. B trusts D and E, D trust
F, C trusts G. All trust relationships are mutal

 A <---> C <---> G
 ^
 \
  \-----> B <---> D <---> F
          ^
          \
           \---> E

now they want to share some files, but they do not want that untrusted
users know who shares the files.

The idea: just route over friend-routes. solution: use IndirectData
connections of tinc, and connect only to trusted persons.

what was missing from tinc: anonymity. do a killall -USR2 tincd and you
can see the ips of everybody in your syslog.

what the patch adds: if FriendOfAFriend is set, then your node does not
distribute information about the IP and port of other known nodes. so A
can reach G only indirect, because C does not disclose the real IP of G
to A.

Re: friend of a friend type darknets

On Sat, Sep 18, 2010 at 12:25:29AM +0200, Alex wrote:

> here a little patch for darknet functionality, i hope it does what its
> intended for sufficiently ... but it seems to work :).
> 
> what should it do?
> 
> imagine your friend-network. A trusts B and C. B trusts D and E, D trust
> F, C trusts G. All trust relationships are mutal
> 
>  A <---> C <---> G
>  ^
>  \
>   \-----> B <---> D <---> F
>           ^
>           \
>            \---> E

You have drawn an acyclic graph, but tinc can work with any kind of topology,
including cycles (in fact, that makes it more robust in case some connection
fails).

> now they want to share some files, but they do not want that untrusted
> users know who shares the files.
> 
> The idea: just route over friend-routes. solution: use IndirectData
> connections of tinc, and connect only to trusted persons.

I don't really see why you want to avoid nodes from connecting to each other
directly. If you use IndirectData, it just decreases the efficiency of the