Re: [Openvpn-users] OpenVPN with Mesh Network Topology

[Guus S. <gu...@sl...>]

On Sat, Oct 16, 2004 at 10:55:14PM -0600, James Yonan wrote:

> On Sat, 16 Oct 2004, Leonard Isham wrote
> > Do you have a technology in mind for this?  The only peer VPN I'm
> > aware of is MPLS and MPLS requires your provider to impliment it.
> >
> > Are you looking into making the server mode into eithe a multi-mode
> > (client and server) or maybe a hub mode?

Tinc (http://www.tinc-vpn.org/) allows VPN daemons to be connected to
each other in whatever way you see fit (for example, star topology), and
will automatically create a full mesh where possible. It does this in
both router (in OpenVPN terms, tun) mode and in switch (tap) mode.

> This is my current plan for doing single-hop full-mesh VPNs:
>=20
> With the current client/server star-topology VPN framework, a VPN client=
=20
> initially connects with a server.  Through the server, if configured, the=
=20
> client can then reach another client over 2 hops, i.e. client -> server -=
>=20
> client.
>=20
> Single-hop full-mesh is an optimization on this model, where client to=20
> client traffic is transmitted directly between clients without needing to=
=20
> pass through the server.

Tinc works with a similar principle, although it doesn't distinguish
between servers and clients. Peers can also see other peers if they are
more than 2 hops away.

> How is is this implemented?
>=20
> (1) When a client connects to the server, it tells the server: I am
> available for direct client-to-client connections.  I will be listening on
> IP address A and port P for such connections.  Here is a list of subnets=
=20
> which I own, and would like to advertise.

Advertising your own address is not done in tinc, because it is hard to
figure out your own address in a consistent way (especially if you have
multiple addresses assigned to the outgoing interface), and you also
don't know if there is a NAT in the way changing your address. Instead,
the recpient of such an availability messages records the IP address
=66rom which it was apparently sent, and passes that on to other peers.
This is also not perfect but works much better in our experience.

> (2) The server then makes this information available to all clients over
> the same control channel used to push/pull config info.  If a client finds
> itself attempting to send a packet over the VPN to an IP address which
> exists inside of a subnet owned by another client which has advertised
> its willingness to accept direct connections, the client will then
> attempt to generate a dynamic, direct client-to-client tunnel.
>=20
> Advantages: (1) The principal advantage of this approach, in my view, is
> that it retains the simplicity of the star-topology configuration.  All
> that really needs to be done by the VPN admin is to add a single flag to
> the config to tell the server to request a direct-connect IP and port + a
> list of owned subnets from each client. (2) The potential instability
> inherent in dynamic routing protocols is sidestepped, because the topolog=
y=20
> remains single-hop between any two nodes.

Tinc uses a flooding protocol to exchange this information between
peers. Flooding is not a routing protocol on its own. This is similar to
how OSPF router daemons exchange information. It is not hard to
implement and there is no instability. On the other hand, if you _want_
to enforce a star topology (for example, if you don't want clients to
see each other), then changing the way tinc works to accomodate for that
is much harder.

> Disadvantages:  (1) In the simple implementation, the server is a still a=
=20
> single point of failure.  The single point-of-failure can be=20
> alleviated somewhat by allowing multiple servers which use a=20
> multicast-oriented control channel to distribute routing info.  This of=
=20
> course adds complexity and moves the model closer to that of a fully=20
> decentralized "cloud-oriented" VPN which uses a dynamic routing protocol.=
=20

Just exchanging the information doesn't require a dynamic routing
protocol, however:

> (2) Doesn't work well with NAT, because each client must be able to liste=
n=20
> on a public IP address for direct connections from other clients.

That will require a dynamic routing protocol if you don't stick to the
strict client/server star topology model. In the ideal case of every
node being able to listen and send to every other node, you don't need a
routing protocol: just send it directly. If some nodes are not reachable
via one hop, you have to figure out which route to take to that node.
Tinc handles that case as well by using an OSPF like routing algorithm.

James, feel free to use the knowledge gathered in tinc.

--=20
Met vriendelijke groet / with kind regards,
    Guus Sliepen <gu...@sl...>