Tag Archives: vpn

Choosing the Right Hardware for BBHN Virtual Tunnels

Storage Space is King

The biggest challenge in installing extra software on nodes, such as tunnel solutions, is the amount of storage space that is available.  These devices usually have very limited storage capacity.  For example, a WRT54G has 4MB of flash memory.  This memory is where the entire operating system (OS), applications, and settings, must reside.  After the OS is loaded, we are left with very little space to store extra software (like tunnel/vpn software).   In fact, there is NOT enough space on a WRT54G to even install one of the required components of the tunnel solution.  On the other hand, a WRT54GS v2 has DOUBLE the amount of flash memory (8MB).  This is enough to install the tunnel solution, however, the BBHN project is stopping support for these Linksys devices in early 2015.  All of the Ubiquiti (UBNT) supported devices have at least 8GB of flash memory as well.

For this article, I will focus on the UBNT supported devices, since they have a longer support lifetime.

LAN and WAN ports

In order to support local LAN devices (ie. phones, PC’s, servers, RaspberryPi’s, etc), the node needs a LAN port.  This port also provides the PoE (power-over-ethernet) that is required to supply power to the node.  The WAN port provides access to the internet (or, perhaps, your local “home” network).   As long as you do not need to access the internet from your node, you really don’t need the WAN port.  However, since we are talking about virtual tunnels over the internet, we obviously need a way to get access to the WAN port.

Lonely Ethernet Ports

One of the “drawbacks” of the UBNT devices is that most only have a single ethernet ports.  Although the NanoStation models have two ports, the second port has not yet been enabled in the BBHN firmware.  There is an open ticket to support the second port.

So, our dilemma is… how can we provide LAN and PoE and WAN all over a single ethernet port?  Well, the answer lies in a feature/specification called 802.11Q VLAN.


The BBHN firmware uses this VLAN feature in order to provide “virtual lan”, or “virtual ports” over a single port on the device.  The way it works is that the firmware “tags” WAN traffic with “VLAN1” and LAN traffic is not tagged at all.  The switch will route the packets to the appropriate ports with the corresponding tags.

Recommended Hardware

Ubiquiti Nanostation M2 (or M5)
Netgear GS105E Smart Switch (see AE5CA’s article on configuring this)
** The “E” is important in the model number. **

A Final Note on Hardware

AE5CA (Clint) has a done a very nice job of comparing the various UBNT devices.  His blog article titled “Your first BBHN node should be a NanoStationM2” is comprehensive.


Building out a BBHN Mesh Network using Virtual Tunnels

Trees! We love them… and hate them.


Montgomery County, TX, is a heavily wooded part of the great state of Texas.  As we all know, trees are the bane of 2.4Ghz band.  In order to have a practical and effective mesh network, it requires either a high density of mesh nodes, and/or, mesh node(s) that have excellent line of sight (ie. > 40′).  While we are working on solutions to get mesh nodes at higher elevations, in the interim, it would be really nice to be able to build out the mesh and get practical experience in deploying/operating on the mesh.  In order to accommodate this, I propose the use of internet links to bridge the gaps where RF links don’t currently exist.  The technology behind this is called virtual private networks (VPN’s), or, as they are commonly called in mesh-land, virtual tunnels.


VPN’s essentially allow us to extend a network ACROSS the internet to other networks.  Using VPN’s, we can have mesh nodes that are connected across the county, across the state, or across the globe.  Odds are, your company has capabilities such as this for this for remote workers to access things on the corporate network in a secure fashion.  Mesh VPN’s are the same concept.

But it isn’t RF!

Yes, you are correct in that VPN’s are not using RF.  We are HAM’s, we MUST use RF!  I agree to a point, however,  VPN’s do offer several advantages:

  • It gets HAMs excited about the mesh technology
  • It provides for the opportunity to learn how to setup and deploy mesh nodes
  • It provides for the opportunity to USE the mesh and come up with creative uses in EMCOMM (and beyond)
  • It provides the ability to actually demonstrate the capabilities of ARES and the mesh to served agencies
  • It provides the opportunity to “piggyback” actual RF things on the fringe of the mesh (ie. packet gateways, Dstar hotspots, etc.)

While this is CLEARLY a stop-gap solution, I think the benefits of it are valid.



The enabling technology behind the mesh network is the TCP/IP protocol stack.  TCP/IP is used everywhere in today’s work in things such as: cell phones, home networks, remote controlled light bulbs, fancy remote controlled HF rig, and even DStar.  The original designers of TCP/IP did a fantastic job in creating a set of robust and flexible protocols.


So, how I do *DO* this?

I will be creating a series of blog posts to describe the process of creating virtual tunnel links between nodes.  I have created some scripts to make the process easier.  I also plan to undertake some UI work of the BBHN firmware to add some administration pages to the web interface to allow for easy administration of these virtual tunnel links.


Stay tuned!