n2n revisited (by alaric)
I have spoken before about n2n, the peer-to-peer VPN tool that makes it easy to create efficient virtual networks.
Normal VPN products are really more of a "virtual private cable" than a "virtual private network" - they just establish a point-to-point link over the Internet, requiring a login to set it up and encrypting the traffic. This means you can have a virtual connection to a real private network somewhere; and if a few people connect into that network via VPN links, then there really is a virtual private network between you all, but all going through a central point where all your links meet.
While with n2n, everyone connects to a shared "supernode" that keeps a list of who is connected to the VPN, and from where; then when you want to connect to somebody else, you use the list from the supernode to establish a direct encrypted connection between yourself and them, rather than going through any central point. So it's an actual virtual network out of the box. You can even have more than one supernode running, so that any one can fail; all the supernode does is to provide the directory service.
Also, you don't need to maintain a database of user logins; a supernode can carry any number of virtual networks. When you connect to the supernode, you just tell it the name of the community you want to join, and it will share your connection details with anybody else in the same community - you can make communities up on the fly rather than needing to maintain a central list. Access control is handled by the simple fact that you need to know the correct encryption key for the community you want to join, or your messages will be received garbled by everyone else, and ignored.
Anyway, for a long time, I wanted to get into n2n, but I couldn't as it didn't compile out of the box on NetBSD; but a desire for a better VPN solution at work has led to me getting it working. It wasn't that much work, in the end, as the existing FreeBSD support already had a BSD approach to things.
n2n is distributed via Subversion, so they don't have version tarballs - this is a problem for my NetBSD port. So I decided to mirror it into git with git svn, then forked it as "Kitten n2n", made my NetBSD port, tagged a release, pushed it to github, uploaded a tarball from that tag, and then made a NetBSD package of net/kitten-n2n.
I'll tinker with it for a few more days, then I'll submit it to the NetBSD folks for consideration.
I'll keep pulling in from the official n2n Subversion repo, to pull down patches, and I'll see if they'd like my patches pushed up - as well as NetBSD support, there's a few things I'd like to fix as well (I've spotted passing an integer through a void* by casting, which is slightly dodgy practice and produces warnings on my 64-bit machine, but is easily fixed by passing a pointer to a heap-allocated copy of the integer!)
Crypto / security | alaric | 
Sat 22nd Aug 2009 12:49 pm
Subscribe
By alaric, Tue 25th Aug 2009 @ 12:26 pm
We've since spotted a few more neat features of our n2n vpn.
Firstly, it's not fragile, because it has good state recovery. The old PPTP VPN would, if we moved network or suspended and awoke our laptops, go down and require manual re-connection. However, n2n works by having the edge nodes send regular keep-alives to the supernodes, updating the supernodes' directory tables. So if we're offline, the edge nodes' keep-alives are discarded due to lacking a route out; and when we come online again, one gets to the supernode, and then we're back.
This means that we've ended up leaving our n2n connections running, as once they're running, they stay running. Being connected to the VPN is something that's just there, rather than being something you manually initiate when needed.
And this has led to a second dimension: the laptops of anybody who's online are all joined on a virtual Ethernet LAN. So we can see if people are online by just pinging them. And we see each other appear in Bonjour.
We have a Nabaztag in the office; it announces (via text-to-speech) when people push to 'mainline' git repositories, and we want to make the continuous-integration system so it can announce when somebody breaks the build. But that's not so useful for people who are working from home; so we've been considering running a reliable-multicast group (using the Spread Toolkit) that team events can be published into, and things like the Nabaztag listen from - but then we can extend it over our VPN, so it can drive Growl notifications on my Mac, and similar mechanisms for the Linux users.