yes, i understand. this is just one step in my testing. Next, is to get a remote (across the internet/beyond my home router) client to connect. I would not expect to run in this (m2 to wrt) architecture in a normal situation. ;-) D.

Also, the Bullet M2 is the client, so no tunneling "into" the M2.  The server is on the 54GS.

Re Encryption:

This is actually still an issue that needs to be looked at, vtund either needs to be ran without encryption OR be configured/bound to only be able to connect over the WAN port.  At the moment everything I heard has it unbound and not caring so it's possible it may choose to go over the mesh.  Needs to be looked into deeper to be sure that can not happen.

Absolutely agree, any use of tunnels is soley a hold over measure and should NOT be used as a final solution should only be used as a stop gap measure to bring up more interest in an area.  Any use otherwise is asking for trouble.

I think there is a security risk in running gre over the internet.  However, given the non-authenticated, non-encrypted nature of BBHN, the same risks exists for the mesh itself.  I try to keep logging in of remote nodes to a minimal as you never know who could be sniffing.  As with all things, it's a risk analysis tradeoff.  I think there's a spot for both gre and vtun methods.

Like everyone has already stated, the tunneling is great for users who can't directly reach a mesh.  I think there is great potential in tunneling for interconnecting meshs.  It's a way to bring together everyone and create a world wide mesh network.  

Joe:

Quick glanced your tar file.

I don't see any handling of the routing table entries in your setup files. might of missed it, but important to look into otherwise routes will likely not work correctly except for one hop nodes if it isn't there.

Take a look at /etc/hotplug.d/iface/11-meshrouting

I'm actually surprised your getting across 2 hops at the moment, that should not be the case on quick thought as the right table should not be being consulted.

This was part of securing the network from inadvertent routing done in 1.1.0 release (and is the biggest reason why the document needs to be re-written from 1.0.0/1.0.1)

Ah I see why it works, rules 30200-30299 that I set to all interfaces when the loopback comes up allows it to traverse the node.  So not so surprising it works.

A new 12-vpnrouting policy should still be created however following similar to the dtdlink policy to ensure we don't have a regression and introduce the security flaw previously seen in 1.0.x

re: /etc/hotplug.d/iface/11-meshrouting

Conrad, Looks like it is still catching default rules to see the olsrd routes for these new interfaces, DEVICE=tun0:

30210:from all lookup 29

30220: from all lookup 30

30290: from all lookup main

30299: from all lookup 31

32766: from all lookup main

32767: from all lookup default

Yes it is, but as done it would be a regression of the BBHN->ticket:35 (a tunnel link could force its way to use  your internet because of rules 30290,32766   It also leaks the nodes when in nat mode too.

The 30200+ rules are meant to be used by the node itself for finding everything it may need to connect to, not to be used by traffic actually traversing the mesh itself (which a vpnlink side would be)

Question, when defining multiple vtun clients, what do I need to do to my /etc/config/network file regarding the mtmlink sections...

ie. Currently, i have:
...
#### mesh to mesh configuration
config interface mtmlink
option ifname "tun0"
option proto none
...

However, I have 4 different tun* interfaces (ie. tun0, tun1, tun2, tun3)

Do I need to change the network file to:
#### mesh to mesh configuration
config interface mtmlink
option ifname "tun0,tun1,tun2,tun3"
option proto none

any guidance from those who have multiple client connection abilities?