[OLSR-users] Gateway Plugin

John Gorkos (spam-protected)
Sat May 22 01:56:41 CEST 2004

  I've decided to go ahead with a tunneling solution for my commercial mesh
network, and I think I need to write a plugin to support it.  I'd like your

The mesh wireless network will operate on a private class C subnet (say, with no default gateway.  Packets that traverse this network
are un-encrypted and function just like a regular mesh network.  Certain
nodes will be gateway nodes.  They will be running openvpn in the server
mode, listening on port 5000.  Authorized clients will then run OpenVPN
clients over the mesh network to connect to these gateways.  The gateways
will forward authorized clients off the mesh wireless network and onto the
internet.  The solves a number of problems, and creates a couple.  One the
solution side, it allows me to control access to the commercial network at
the gateways:  only clients with the appropriate VPN keys will be allowed to
tunnel through to the internet.  Intruders who do manage to become part of
the mesh can not pass traffic off the mesh without the appropriate VPN keys.
Additionally, it solves the rogue node problem where an intruder can
advertise his node as a gateway and sink all traffic into his own honeypot,
etc.  Right now, I configure each node with the IP address of the gateway
(on the 192.168.7.x network), so the VPN is tunnel is always opened to the
appropriate gateway regardless of what happens on the mesh side (assuming
the gateway is reachable).
  This brings me to the plugin:  in order to make it redundant, I need to be
able to dynamically detect new gateways in the network, and determine if
they are "closer" than the current gateway.  I think a custom packet
announcing that a host is a VPN endpoint would fit the bill.  With an
appropriate IPC mechanism, a device that finds that it has a default route
of metric 0 would fire up the VPN server and announce itself over the mesh
as an available gateway.  Other (non-gateway) nodes on the mesh would see
this announcement and look to see if the new gateway is closer (smaller
hopcount) than any existing gateways.  If it is, it would need to shut down
any existing VPN tunnel and reestablish with the new, closer gateway.
Does this sound like a plausible scenario?  I saw on the plugins page that
there is "very experimental gateway tunneling" code.  Is that the same thing
I'm describing?  Does anyone see any gaping holes in my theory of operations
that I'm blind to?

John Gorkos

More information about the Olsr-users mailing list