n2n

a Layer Two Peer-to-Peer VPN

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: 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.

Quickstart

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

Platform-dependent Differences

MacOS

Please read this document.

Please read this document. Linux

You need to specify the tap interface name with -d. #edge node> edge -d n2n0 -c mynetwork -k encryptme -a 1.2.3.4 -l a.b.c.d:xyw

You need to specify the tap interface name with -d. Windows

The port is available and you need to compile it with a C/C++ compiler.

The port is available and you need to compile it with a C/C++ compiler. Android

you can use this application to run it on your mobile device.

n2n Security

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 e.g. 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 e.g. IKE, Kerberos, SSL, etc. to be plugged in and provide a secure key exchange method. [status = design phase]

n2n packets need to include some junk to avoid DPI applications to detect them [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.

FAQ

Q. Can I use DHCP or ZeroConf in order to configure nodes dynamically?

A. Yes, you can. You need to start the dhcpd on the n2n device on one of your nodes. For instance: “dhcp tun0”. See DHCP mini-HOWTO for further information. Please note that you should not start more than one dhcpd per n2n network (this as best practice).

A. Yes, you can. You need to start the dhcpd on the n2n device on one of your nodes. For instance: “dhcp tun0”. See DHCP mini-HOWTO for further information. Please note that you should not start more than one dhcpd per n2n network (this as best practice). Q. How many inline firewalls n2n can cross?

A. It doesn’t matter if you’re behind one NAT or behind n-NATs. n2n will cross all of them.

A. It doesn’t matter if you’re behind one NAT or behind n-NATs. n2n will cross all of them. Q. n2n is based on UDP. Do you have plans for supporting HTTP encapsulation?

A. Currently n2n supports an initial HTTP tunneling. In order to use it you need to start the edge node with -t (the supernode already listens on both TCP and UDP).

A. Currently n2n supports an initial HTTP tunneling. In order to use it you need to start the edge node with -t (the supernode already listens on both TCP and UDP). Q. How to I implement n2n supernode reliability?

A. A way to have a failsafe n2n network is to put two different n2n interfaces (with same parameters except from the supernode) in a bridge(with brctl) and tune it to use STP Spanning Tree Protocol.

Do you want to know more about n2n internals?

Have a look at the n2n paper.

Need help?

Please open a ticket on github.

License

n2n is distributed under the GPLv3 license.

Get It

The n2n code is available on github.