Sure, tinc is nice, tinc is peer2peer, but without an efficient key distribution system, it eats too much workpower for maintainance.

I found ELA, “A Fully Distributed VPN System over Peer-to-Peer Network”, but it is from 2005 and written for linux 2.4.20.

I also found n2n, which looks quite promising, as it is quite new, runs in userspace, has not many dependencies and is quite small, so it should be able to run on our linksys based nodes.

One could argue, a shared key is nno security at all, if you have a big group, but security is not the main issue, it is about connectivity. without all that key exchange hassle, it could be easy to install and to configure and spread the use of vpn technology in freifunk and other wireless community networks.

I still did not find out how to run the network with more then one supernode, as stated in the paper, but it looks like it is going to be implemented soon.

I will keep playing with it and would be happy about anybody sharing his experiences with n2n as vpn backend for interconnecting meshclouds.

Update: Frithjof did an kamikaze ipkg.

Looks like the big players in muni mesh are getting pressure from below.

Have to have a look on that, did anybody see the downloadbuttom?

after being annoyed of the unfair comparisation between b.a.t.m.a.n. and olsr, resulting in “but it has gateway tunnels” i had a talk with tetzlav from freifunk leipzig about olsr and gateway tunnels.

We came to the conclusion that the concept of asymmetric tunnel should be easy to implement without messing with the olsr code:

1. install the ipip kernel module, load it on gateway(s) and your node.
2. fire you tunl0 on your gateway up with some dumy ip address.
3. add a tunnel interface on your node with your gateway ip as the destination ip
4. fire your tunl with your meship as its ip
5. add a default route with a better metric as the olsr default route pointing to your tunnel interface

As everybody is using the Freifunk firmware, i tried to do this with a few buffalo router running fff-1.6.22:

I took some already for freifunk configured meshnodes.

switched off all firewalls.
Installed the freifunk-recommended-de, freifunk-openwrt-compat and the kmod-ipip package via the webinterface.
After reboot, did a

ifconfig tunl0 10.23.23.23 up

on the gateway.

my gateway has 104.128.30.3 as its ip, my node 104.128.30.1, so on the node:

ip tunnel add tunl1 mode ipip remote 104.128.30.3
ifconfig tunl1 104.128.30.1 up
route add default dev tunl1 metric 0

Now you should be able to observe tunnel packets leaving your node and nontunneld answers coming back.

As packets coming from the LAN port will not pass nat, their answers will not routed back. To circumvent this, put a small /29 on your lan, switch off NAT and announce the /29 via HNA4.

Writing a small script to get the best gateway from olsr and to set the tunnel destination should be easy.

Thinking further, it should be possible to use the olsr service announcement plugin to advertise the available average bandwith of a gateway, giving a better advise to choose an uplink.

Involving some connection tracking, it might be possible to switch gateways with keeping the existing connections to the old gateway, resulting in less hurting behavior while using always the best gateway.

Update: the nice people from freifunk leipzig made a packet for freifunkfirmware, you find it in their packet repository.

Advice: Do not do this at home without policy routing and knowing exactly what you do, it is just a proof of concept.