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 only person allowing a machine to join the VPN, by configuring 2 or 3 "master" nodes. 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. What do you think of these features. Is there anything already implemented I would have missed ? Maybe only in the 1.1 branch ? I am ready to help on these topics, either for design or coding. Regards, Julien
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>
i have not submitted a patch, not even a bit. On Fri, Sep 10, 2010 at 6:12 AM, Julien Muchembled <jm at jmuchemb.eu> 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 IPConfiguration information stored in LDAP and enforced by Kerberos.> 4. prevent nodes from giving access to new nodesFreeIPA 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.> > 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. > In fact, what is important is to protect nodes from being accessed by > unauthorized nodes.Covered by new features but could be verified with Kerberos.> > What do you think of these features. Is there anything already implemented I > would have missed ? Maybe only in the 1.1 branch ? > > I am ready to help on these topics, either for design or coding. > > > Regards, > Julien > _______________________________________________ > tinc-devel mailing list > tinc-devel at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel >