Other feature requests

[Guus Sliepen]

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
ORIGINAL_GW=`ip route | grep ^default | cut -d ' ' -f 3`
ip route add $REMOTEADDRESS via $ORIGINAL_GW
ip route del default
ip route add default via $OFFICE_GW dev $INTERFACE

You have to do the inverse in hosts/office-down (left as an excercise for the
reader). But I wouldn't know how to do this on Windows either.

> 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).

In tinc 1.0.13, you can use the StrictSubnets option to disallow other nodes
claiming Subnets that are not in the corresponding host config file local
hosts/ subdirectory.

> 4. I don't want that any client is allowed to extend the network by giving
> access to new nodes. I should be the only person allowing a machine to join
> the VPN, by configuring 2 or 3 "master" nodes.

The StrictSubnets option also takes care of this.

> In fact, what is important is to protect nodes from being accessed by
> unauthorized nodes. So we could imagine an option that we enable on every
> node A that should be protected from unauthorized nodes: whenever A sees a
> new node B, it asks a master node if B is authorized.  A workaround would be
> to force all traffic going to the "master" nodes, and the result would still
> be better than with OpenVPN. Maybe options already exist for that.

You could force everything through the master nodes by using the IndirectData
option.

> What do you think of these features. Is there anything already implemented I
> would have missed ? Maybe only in the 1.1 branch ?

Well, 2, 3 and 4 can be done more or less with 1.x. However, I want to do it
more properly in 2.0, with real end-to-end encryption (even when intermediate
nodes forward packets), and certificate based authorisation. For the latter,
there is already a library and a command line utility to test it
(http://tinc-vpn.org/git/fides).

> I am ready to help on these topics, either for design or coding.

That would be great! I have little time myself to work on it unfortunately.
Perhaps the best way forward is to make a version of tinc (preferably based on
the 1.1 branch) that uses libfides to store and exchange host config
information.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20100910/eaf49b5f/attachment.pgp>