History

Original Cloudvpn page

CloudVPN, the secure mesh VPN

Small and secure SSL-based mesh networking tool.

history

I got bored with OpenVPN, because it allowed only one server per network (more only with dirty iptables tricks), so I extended some of my ideas and finally came up with solution of mesh-networked VPN. Each node here works exacly like a simple mesh router, therefore networks can consist of computers connected in any shape - we allow circles and complete graphs for improving the ping and/or reliability (and for using underlying real networks as best as possible), and also long-rope network lines, usuable for tunelling through many-layer network architecture.

development status

Complete. Improvements still in development.

download

  • source is available at download section, see left
  • package for ArchLinux at aur.archlinux.org (thanks to Nathan O.)
  • ebuild for gentoo is in Sunrise overlay, as net-misc/cloudvpn. see bug #258859
  • debian package will be available soon

requirements

  • some kind of reasonable unix (linux/BSD)
  • GnuTLS library (with headers if you plan to build the code yourself)
  • libev, the event polling library
  • TUN/TAP driver for your architecture (if you want ethernet VPN)

features

CloudVPN is a multi-protocol mesh virtual network. Simply - it can transport any reasonable packet protocol, for any application that needs to communicate. Cloud nodes act as a meshing and transporting layer, and applications connect to them using a gate socket. Such client applications include:

  • Ethernet tunnel, that uses the cloud as one big virtual network, which, given the mesh properties, also proves to be efficient and secure; and gives CloudVPN the "classical VPN function".
  • Secure chat client, using the same security adventages.
  • Filesharing client (which really proposed itself as a bittorrent alternative)
  • Optimized radio-like broadcasting client
  • Whatever else you like.

Running on Linux, FreeBSD, OpenBSD and most other unixes. Windows should (if you are adventurous) work too.

TLS/SSL-based security

Improved multipath routing *for pushing your data through multiple connections, for speed or security improvements)
Don't mistake CloudVPN with another "cloud" VPNs, like Citrix Cloud VPN. In fact, those are technologically far inferior to CloudVPN.

Total/per-connection upload/download bandwidth limiting.

Handling of following connection schemes was the goal of CloudVPN:

  1. distributed server - for example when 2 groups of users want to share one network, but they both want to be close to the server, because of latency:
              South pole,                     North pole,
              research                        satellite connected
              Station       ..distance..      Russian expedition

                 o - - - - - - - - - - - - - - - o
                /|\                             /|\
               / ||\                           /|||\
              o| o||o                         o||o| o
               o  oo                         o oo o  o
  1. server redundancy, several servers are connected to make a server farm, and users connect to random of them. If one server dies a terrible death, users can just reconnect to another (if they do it fast enough, they probably don't even lose a TCP connection).
            bunch of
            servers     load
                        balancer
              ooo             - - - -
              ooo  - - - o - - - - -   users
              ooo             - - -
  1. traversal through many complicated network layers, even when IP network does not allow direct connection to one common server.
             [guy1]
                \
                 \   long route
                  o -- o -- o -- o
                                  \
                                   \
                                  [guy2]
  1. complete network, for example for connecting several servers and minimalizing delays
  1. failover multi-path connections
              weird shapes
                o - - - - o       double
               / \       / \      connection
              /   \     /   \      .-------.
             o     o - o - - o    o         o
              \   /         /      '-------'
               \ /         /
                o - - - - o
  1. tree topology (similar to the first case)
  2. classical "star shaped" server with a number of clients
  3. as all nodes are equal in all situations, any combination of above schemes is possible. Specifically, see the CloudVPN wallpaper

security

  1. Connection is secured by GnuTLS, nothing is sent without encryption and authentication
  2. Every node has a private key and certificate, generated and signed as usual.
  3. Every node also has some CA certificates. To be able to connect to the node, client has to supply certificate signed by this authority. This means that authorization to connect is given by signing the public key and/or copying the signed keypair.
  4. Client checks server's public key by the same means.
  5. CA private key is meant to be kept away from public. Anyone who owns it can connect. (This also implies that CA key is public for public networks.)

installing

Download the git from download section, follow the instructions, use ./autogen.sh and then configure&make to compile the thing, and be sure to read the README file, it contains all the configuration options and howtos.

On Gentoo, there's already a package in Sunrise overlay, so you just need to emerge net-misc/cloudvpn

running

run it simply, usually this way:

cloud -@include /some/config.cfg

cloudvpn does NOT run as a daemon, it prints log to stderr, and terminates when interrupted by SIGTERM (signal 15), so you probably want to redirect output to some file with >> and background it by yourself (for example 'setsid cloudvpn &'). Also please note that running cloudvpn without any parameters will fail because of configuration lack, there's no "default" config file. For details about configuration options and config files please consult README file.

Q: If I'm using this for ethernet tunelling, what is the difference between CloudVPN and ... ?

tinc VPN only uses a slightly different routing scheme. CloudVPN acts similarly to common Distance Vector routing algorithms, tinc uses kind of Link State routing. Google it for details.

OpenVPN is pretty big, pretty old, pretty stable and solid, but kind of unscalable. Also doesn't allow any mesh things.

n2n's basic purpose is to route things through NATs, not the actual meshing. CloudVPN can't do STUN-like connections itself now - you have to provide it with a pre-created tunnel. This can be easily achieved by using supplied 'stunproxy' tool.

Q: You are using Distance Vector Routing, isn't it old and ugly?

Yeah, common DVR Algorithms (RIP-series and similar) are ugly and unscalable. I put much effort into removing such problems, so now:

  • Overhead with sending the routing tables is minimized, because we are sending only the differences.
  • Maximal network distance for this kind of routing is usually limited. CloudVPN fixes that, so if we extend our network to infinity, we aren't gonna die from extreme routing tables. Nodes which are too far away are routed using another (simpler and stateless) protocol.
  • Known DVR problem of node-disconnection overhead is minimized, and the needed amount of data transfer is constant for given configuration.

Q: What is the cloudvpn overhead compared to other ethernet VPNs?

Compared to other ethernet VPNs that are tuned for bandwidth, and given the flexibility of the protocol, overhead can be really large. On the other hand, don't panic - one can usually hardly tell the difference (as the overhead is usually just linearly larger), and, honestly, CloudVPN wasn't originally even meant for the performance it can bring now.

Basic problems and numbers that affect performance are here:

  • Each transferred packet has 20-byte protocol header; this can double small-packet-based traffic.
  • Route information sent has 14 bytes + address size (for example, 14+6=20B for ethernet).
  • Data copying (known problem of high-throughput applications, read about zero-copy protocols):
    o 1.x branch can handle incoming packet with one copy.
    o 2.x branch does it the same, but there's one more gate (with one more copy) in the way; so one additional copy is usually forced. (luckily this can be split among multiple processors, as the processes are separated.) I don't count Operating System overhead, as it should be minimized by operating system itself.
  • Transport is based on TCP. This can make trouble when connection is lossy - especially with TCP in TCP congestion, and lags waiting for a frame. UDP transport will be added soon.
  • Last thing - traffic is encrypted. This results in enormous overhead over unencrypted data. If you are planning to use some high-bandwidth encrypted services in the mesh, consider whether it's really needed to encrypt them by 2 layers, and preferably route them unencrypted, or without mesh.

thanks to

snajpa for overall help (2.0/security design, testing)

Adrian Goins for kicking me to start 2.0 transition, and for the donation

James Buckley (rewinder) for OSX work

Fadjar Tandabawana for intensive testing

questions, bug reports, suggestions

throw a mail at me, see contact section. Anything useful is welcomed and highly appreciated!

Also, there's now #cloudvpn channel on the Freenode network. Hope i can help there.