n2n is a layer-two peer-to-peer virtual private network (VPN) which allows users to exploit features typical of P2P applications at network instead of application level. This means that users can gain native IP visibility (e.g. two PCs belonging to the same n2n network can ping each other) and be reachable with the same network IP address regardless of the network where they currently belong. In a nutshell, as OpenVPN moved SSL from application (e.g. used to implement the https protocol) to network protocol, n2n moves P2P from application to network level.
The main n2n design features are:
- An n2n is an encrypted layer two private network based on a P2P protocol.
- Encryption is performed on edge nodes using open protocols with user-defined encryption keys: you control your security without delegating it to companies as it happens with Skype or Hamachi.
- Each n2n user can simultaneously belong to multiple networks (a.k.a. communities).
- Ability to cross NAT and firewalls in the reverse traffic direction (i.e. from outside to inside) so that n2n nodes are reachable even if running on a private network. Firewalls no longer are an obstacle to direct communications at IP level.
- n2n networks are not meant to be self-contained, but it is possible to route traffic across n2n and non-n2n networks.
The n2n architecture is based on two components:
- edge nodes: applications installed on user PCs that allow the n2n network to be build. Practically each edge node creates a tun/tap device that is then the entry point to the n2n network.
- an supernode: it is used by edge nodes at startup or for reaching nodes behind symmetrical firewalls. This application is basically a directory register and a packet router for those nodes that cannot talk directly.
Edge nodes talk by means of virtual tap interfaces. Each tap interface is an n2n edge node. Each PC can have multiple tap interfaces, one per n2n network, so that the same PC can belong to multiple communities.
- Download and compile the code
- Decide where to place your supernode. Suppose you put it on host a.b.c.d at port xyw.
- Decide what encryption password you want to use to secure your data. Suppose you use the password encryptme
- Decide the network name you want to use. Suppose you call it mynetwork. Note that you can use your supernode/edge nodes to handle multiple networks, not just one.
- Decide what IP address you plan to use on your edge nodes. Suppose you use IP address 10.1.2.0/24
- Start your applications:
#supernode > supernode -l xyw
#edge node1> edge -a 10.1.2.1 -c mynetwork -k encryptme -l a.b.c.d:xyw
#edge node2> edge -a 10.1.2.2 -c mynetwork -k encryptme -l a.b.c.d:xyw
Now test your n2n network:#edge node1> ping 10.1.2.2
#edge node2> ping 10.1.2.1
- OSXIn some OSX version, the tun/tap device is missing. In this case you need to download and install the tuntapdriver.
- LinuxYou need to specify the tap interface name with -d.
#edge node> edge -d n2n0 -c mynetwork -k encryptme -a 188.8.131.52 -l a.b.c.d:xyw
- WindowsThe port is available. You need to compile the project part of the SVN code using Visual C++ .NET 2008 Express. For your convenience from time to time we compile Win32 binaries that you can download from this URL.
n2n 1.x has been designed to be simple and used in private n2n networks. We’re aware that it has some security limitations such as
- Keys on the command line are a problem.
- Lack of nonces in encryption makes it relatively easy to perform replay attacks.
- Lack of HMAC makes man in the middle relatively easy. (I don’t think this is a valid criticism as n2n is not trying to attach trust to a connection, just opacity).
- Difficulty in rolling keys and integrating secure key exchange protocols.
For this reasons the next n2n 2.x release will feature the following security extensions:
- Each encrypted payload gets a 32-bit nonce (salt) so the same packet will get encrypted differently each time. This makes it harder to perform replay attacks, discover keys, etc. [status = WORKING]
- Each encrypted packet carries a key index in clear-text so the edges can signal key changes to the receiver. Key exchange could be done by eg. IKE (IPSec) or Kerberos, or just having a list of shared keys that is updated from time to time. Having a key index allows for reliable key rolls if the clocks on the two edges are skewed slightly. [status = WORKING]
- Edge program will have a key discovery channel to allow eg. IKE, Kerberos, SSL, etc. to be plugged in and provide a secure key exchange method. [status = design phase]
- Each n2n packet carries a transform identifier so a mixture of encrypted and unencrypted packets can be carried and the decoding transform identified at runtime. The transform identifier allows data transform plugins and extensions. When new encryption or compression types are added, the n2n packet format does not need to change and receivers can detect if know how to process the packet. [status = nearly finished]
The above statements do not mean that n2n is insecure, just that security will be better addressed in the next major release.
n2n Gui: graphical frontend for n2n.