[OLSR-users] Gateway Plugin

[Andreas Tønnesen]

Hi John,

Yes - your tunnel scheme sounds like something that can be handled by
a plugin. As you noticed some preliminary tunneling code exists.
I am planning on moving this code to a plugin(it's currently implemented
in olsrd).

The whole idea behind the tunneling implementation is for hosts to
be able to control what Internet gateways they use. IP in IP tunnels
are used. But the design should work when using encrypted tunnels
as well AFAIK. What the code does right now is this:

- If a node detects that it is a HNA Internet gateway at olsrd startup
then it goes into "tunnel endpoint mode". Is sets up a
multipoint-to-point IP-in-IP tunnel that allows for incoming tunneled
traffic from any node. Traffic back to a node(from the Internet) is
routed normally.

- If a node is not a Internet gateway, then it will set up a IP-in-IP
tunnel to the first Internet gateway it hears HNA from.

This is a very static implementation only suited for testing purposes
(after all - this is reasearch ;-) ). In some future version I would
imagine a solution like this:

- Nodes detect Internet connectivity dynamically(like in the gw plugin)
and tunnel endpoints are set up and taken down accordingly.

- Clients track TCP connections. Whenever there are no TCP connections
going trough a tunnel a recalculation for the network reachable trough
that tunnel is initiated. If a gateway with less hopcount is located
then the old tunnel is taken down and a new one set up.
One should of cause look at other parameters than TCP conn = 0 for
this recalculation, but that's a startingpoint.


I think these ideas are pretty much the same as you've got?

Bottom line: I think it sounds like a good plan :)

- Andreas

John Gorkos wrote:
> Andreas-
>   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
> thoughts.
> 
> The mesh wireless network will operate on a private class C subnet (say,
> 192.168.7.0) 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?
> 
> Thanks!
> John Gorkos
> 
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users

-- 

-- 
Andreas Tønnesen((spam-protected))
UniK University Graduation Center
University of Oslo
http://www.olsr.org