I have a few questions regarding the use of vtund:

Is this article still valid for BBHN 1.1.2?    http://www.broadband-hamnet.org/documentation/120-creating-a-tunnel-network.html

Is the 172.31.x.x network only for the vtun interface, or, should that now be a 10.x.x.x network?

Are there plans to build a config page to allow the configuration of vtund server and clients on the backlog?

If not, I was considering creating a /cgi-bin/vpn page to allow for installation and configuration of it.  Is anyone interested in this?

73, K5DLQ - Darryl

Houston/The Woodlands/Magnolia/Conroe TX

I do not belive it's been updated to reflect version 1.1.x and higher only 1.0.x

Node tunnels should not be in the 10.x.x.x range as this would conflict with everything else.  Keep it in the 172.31.x.x space and we can easily know where these are at and you will have my less chance that a future upgrade will cause you issues or that you will cause issues on other networks with conflicts.

I have been working on getting a tunnel server running for months. I have a set oflinksys 1.0.1 WRT54GS boxes which work as a tunnel sever/client. I have yet to get a Ubiquiti box to work. I did get close with version 1.0.1.  The nodes would connect but the OLSR would not join the networks. 

I am trying again to get it going this time under 3.0.0. 

I submitted ticket 65 to ask for some help to get the changes to get 3.0.0  to work with tunnels documented. See ubnt.hsmm-mesh.org for more info. 

Clint

thanks Clint. 

I read your ticket and we in Montgomery County are in a similar situation.  Would like to get some infrastructure in place via vtun until we can fly a node up to 700' on a tower.

I have a WRT54GS (1.1.2) with vtun installed.  Would you like to coordinate and see if we can get them working first?  I also have a Ubi Bullet M2 to test with.  I have not loaded 3.0.0preview on anything just yet.

if you would like to try, email at k5dlq@arrl.net

I can open a port in my firewall and configure for you to connect.  I am upgrading to V3 beta (-20-v3) to test a few things now.

Darryl

question regarding the instructions:

1) Are these lines needed for the forwarding rules (since they are commented in the docs):

iptables -A FORWARD -i $LAN -o tun+ -j ACCEPT

iptables -A FORWARD -i tun+ -o $LAN -j ACCEPT

iptables -A FORWARD -i $WIFI -o tun+ -j ACCEPT

iptables -A FORWARD -i tun+ -o $WIFI -j ACCEPT

2) if they are needed, can they be inserted into /etc/firewall.user instead of /etc/init.d/firewall?

73, K5DLQ

Yes a "managed" switch is required for the UBNT devices.  In reality, the switch needs to support 802.1Q. 

The main node at my house is a Rocket M2.  It is connected to a Netgear GS108E switch.  I personally believe everyone using the UBNT gear needs a managed switch or two.  In my QTH setup, I have my RocketM2 and a NanoStation Loco M900 connected using dtd-linking.  This lets me combine the 2.4 GHz mesh with my 900 MHz mesh.

I wanted to get a tunnel client using Ubiquiti gear as well.   That way someone connecting to be can also have the superior performance of the UBNT gear for their local mesh.

It is also much easier to find a UBNT node and a switch such as the GS105E than a WRT54GS. 

I am using a NanoStation M5 for my client setup.  This gave me the ability to not have my nodes connecting via wifi.

Clint, AE5CA

Hi,

Yes, they can be inserted into /etc/firewall.user as well.

I´m happy to announce that we, in Sweden, has done som extensive testing with a spanish node, as can be seen in the topology by following the link, and have full connectivity not only to BBHN/HSMM mesh network, but also to AMPRnet through the tunneling.

We are also able to route AMPRnet subnets down to a single node if needed.

http://44.140.236.17:8080

Please also note that documentation is being updated with the latest information about NAT issue that might occur in tunneling depending on central solution.

Anybody wanting the documentation addendum is free to contact me.

We are also happy to help you connecting to us in Sweden if you like.

73sss SM7I

Trying to get my client connected to a server.

I'm getting a "vtund[2242]: Connection denied by...." error.

Here is a tcpdump of the conversation: (I've replaced the actual target IP with 4.5.6.7 and my actual client name with "myclientname")

Any ideas???

73, K5DLQ - Darryl

Attachments
 tcpdump.txt.zip [0 KB]

Here's my setup of vtun with instructions to install on both server and client. untar and check out the README files. Anyone that would like to connect to the mesh in Southern CA, send me email to exchange a password. My internet IP is already in the config files here...  ae6xe@cox.net 

Note, I've not tested my instructions with a fully clean test run.   let me know if I may need corrections. (but not with basic linux command line, etc.)

Download tar file here:

https://dl.dropboxusercontent.com/u/58390217/vtun_install.tar

Hi,

Well, we are using GRE tunneling as we wanted to keep the footprint of implementation to such minimum that it could successfully be run on even the GL models.

I will be releasing the latest docs soon, but please feel free to look at the documentation found at http://www.ssra.se/upload/hsmm%20scripts.pdf

For the sake of discussion, what are the advantages/disadvantages in vtun vs gre tunneling? 

I've setup gre tunneling before have not had the opportunity to play with vtun.

Corby

kd5aeq

GRE - by itself no encryption, light weight kernel mode tunnel, performance edge. Add on top ipSec for encryption also in kernel mode (or other designed encryption techniques/strengths over this tunnel). Googled internet posts claim it is more complicated to do encryption over GRE and depending on technique may limit the protocols.

vtund - on top of vtun kernal driver with everything else in user space. Packaged with basic level of 128 bit encryption->easier to setup. Doesn't limit protocols in use. I'd call this the middle ground solution.

What is best for our community? Depends... If we have no need to encrypt data carried over the internet, basic GRE with no encryption is lighter weight and straight forward. If we need to do encryption (let's say a city EOC has requirements to encrypt their data if going over the open internet), then vtund. If 'strong' encryption is required, then we'd want to look at something like openVPN (over vtun driver) and 1024 bit keys.

All, What do we as a community think are our requirements? What level of security (for the purpose of tunneling traffic over the internet to connect MESHes) should be packaged in a future release of bbhn? This need is likely the significant factor (while still considering options that are easy, supportable, and work). Any opinions?