Convert Figma logo to code with AI

ntop logon2n

Peer-to-peer VPN

6,175
929
6,175
137
View on GitHub

Top Related Projects

zerotier's avatar

ZeroTierOne

14,173

A Smart Ethernet Switch for Earth

tailscale's avatar

tailscale

18,532

The easiest, most secure way to use WireGuard and 2FA.

slackhq's avatar

nebula

14,290

A scalable overlay networking tool with a focus on performance, simplicity and security

gravitl's avatar

netmaker

9,373

Netmaker makes networks with WireGuard. Netmaker automates fast, secure, and distributed virtual networks.

meshbird's avatar

meshbird

3,512

Distributed private networking

xtaci's avatar

kcptun

13,893

A Quantum-Safe Secure Tunnel based on QPP, KCP, FEC, and N:M multiplexing.

Quick Overview

n2n is an open-source, peer-to-peer Virtual Private Network (VPN) system. It allows users to create secure, encrypted networks between computers, even behind firewalls or NATs, without the need for a central VPN server. n2n uses a peer-to-peer architecture to establish direct connections between nodes, making it efficient and scalable.

Pros

  • Decentralized architecture, eliminating the need for a central VPN server
  • Works well with NAT and firewalls, making it suitable for various network environments
  • Lightweight and efficient, with low overhead
  • Cross-platform support (Linux, Windows, macOS, Android)

Cons

  • May require more initial setup compared to traditional VPN solutions
  • Documentation can be sparse or outdated in some areas
  • Less widespread adoption compared to other VPN solutions, potentially leading to fewer community resources

Code Examples

  1. Creating a new edge node:
int main(int argc, char *argv[])
{
    n2n_edge_t *eee;
    tuntap_dev tuntap;
    
    eee = edge_init(&tuntap, &conf, &rc);
    if (eee == NULL) {
        exit(1);
    }
    
    run_edge_loop(eee, &keep_running);
    edge_term(eee);
    
    return 0;
}
  1. Configuring encryption:
n2n_trans_op_t transop_null;
n2n_trans_op_t transop_twofish;

edge_init_twofish(&eee->conf, &transop_twofish);
transop_null.transform_id = N2N_TRANSFORM_ID_NULL;
transop_twofish.transform_id = N2N_TRANSFORM_ID_TWOFISH;

eee->transop[0] = &transop_null;
eee->transop[1] = &transop_twofish;
  1. Sending a packet through the n2n network:
static void send_packet(n2n_edge_t * eee, n2n_mac_t dst_mac, const uint8_t * pktbuf, size_t pktlen)
{
    n2n_common_t cmn;
    n2n_PACKET_t pkt;
    
    memset(&cmn, 0, sizeof(cmn));
    cmn.ttl = N2N_DEFAULT_TTL;
    cmn.pc = n2n_packet;
    cmn.flags = 0;
    memcpy(cmn.community, eee->conf.community_name, N2N_COMMUNITY_SIZE);

    memset(&pkt, 0, sizeof(pkt));
    memcpy(pkt.srcMac, eee->device.mac_addr, N2N_MAC_SIZE);
    memcpy(pkt.dstMac, dst_mac, N2N_MAC_SIZE);

    pkt.sock.family = AF_INET;
    pkt.sock.port = 0;
    memcpy(pkt.payload, pktbuf, pktlen);
    pkt.payload_size = pktlen;

    encode_PACKET(pktbuf, &pkt, &cmn);
    sendto_peer(eee, &cmn, pktbuf, pktlen);
}

Getting Started

To get started with n2n:

  1. Clone the repository:

    git clone https://github.com/ntop/n2n.git

  2. Build n2n:

    cd n2n
./autogen.sh
./configure
make

  3. Start a supernode:

    ./supernode -l 1234

  4. Start an edge node:

    ./edge -d n2n0 -c mynetwork -k mysecretpass -a 10.0.0.1 -l supernode.example.com:1234

Replace `supernode.

Competitor Comparisons

zerotier logo

ZeroTierOne

14,173

A Smart Ethernet Switch for Earth

Pros of ZeroTierOne

  • More user-friendly setup and management through a centralized web interface
  • Better scalability for large networks with thousands of nodes
  • Advanced features like multi-path routing and traffic optimization

Cons of ZeroTierOne

  • Closed-source central infrastructure, potentially raising privacy concerns
  • Requires an internet connection for initial setup and peer discovery
  • More complex codebase, which may be harder to audit or customize

Code Comparison

ZeroTierOne (C++):

void Node::processVirtualNetworkFrame(
    uint64_t now,
    const SharedPtr<Network> &network,
    const MAC &fromMac,
    const MAC &toMac,
    unsigned int etherType,
    const void *data,
    unsigned int len)

n2n (C):

int edge_init(n2n_edge_t *eee)
{
    memset(eee, 0, sizeof(n2n_edge_t));
    eee->start_time = time(NULL);
    eee->allow_routing = 0;
    eee->known_peers = NULL;

Both projects aim to create peer-to-peer virtual private networks, but ZeroTierOne offers a more polished, feature-rich experience at the cost of some privacy and customization flexibility. n2n, being fully open-source and simpler, may appeal more to users prioritizing complete control and transparency over ease of use and advanced features.

tailscale logo

tailscale

18,532

The easiest, most secure way to use WireGuard and 2FA.

Pros of Tailscale

  • Easier setup and management with automatic key distribution
  • Built-in NAT traversal and relay servers for better connectivity
  • Integrates with existing identity providers (e.g., Google, Microsoft)

Cons of Tailscale

  • Closed-source server component
  • Requires a central coordination server
  • Less flexible for custom network topologies

Code Comparison

Tailscale (Go):

func (c *Conn) ReadFrom(b []byte) (n int, addr net.Addr, err error) {
    for {
        n, addr, err = c.pconn.ReadFrom(b)
        if err != nil {
            return 0, nil, err
        }
        if addr.(*net.UDPAddr).IP.Equal(c.remoteAddr.IP) {
            return
        }
    }
}

n2n (C):

static int edge_init(n2n_edge_t *eee) {
    memset(eee, 0, sizeof(n2n_edge_t));
    eee->start_time = time(NULL);
    eee->allow_routing = 0;
    eee->drop_multicast = 1;
    return 0;
}

The code snippets show different approaches: Tailscale uses Go and focuses on connection handling, while n2n uses C and initializes edge structures. Tailscale's code is more network-oriented, whereas n2n's code is lower-level and deals with edge node initialization.

slackhq logo

nebula

14,290

A scalable overlay networking tool with a focus on performance, simplicity and security

Pros of Nebula

  • More robust security features, including certificate-based authentication and encryption
  • Better scalability for large networks, supporting thousands of nodes
  • Built-in monitoring and metrics for easier network management

Cons of Nebula

  • Steeper learning curve and more complex setup compared to n2n
  • Requires more resources to run, potentially impacting performance on low-end devices
  • Less suitable for simple peer-to-peer connections due to its focus on larger networks

Code Comparison

n2n example (simplified):

int main(int argc, char *argv[]) {
    tuntap_dev tuntap;
    n2n_edge_t *eee;
    n2n_edge_init(&eee, &tuntap, &conf);
    n2n_edge_start(eee);
    return 0;
}

Nebula example (simplified):

func main() {
    config, err := nebula.LoadConfig("config.yml")
    if err != nil {
        log.Fatal(err)
    }
    control, err := nebula.NewControl(config)
    if err != nil {
        log.Fatal(err)
    }
    control.Start()
}

Both projects aim to create secure, decentralized networks, but Nebula focuses on larger-scale deployments with advanced security features, while n2n prioritizes simplicity and ease of use for smaller peer-to-peer networks. The code examples highlight the difference in complexity, with Nebula requiring more setup and configuration.

gravitl logo

netmaker

9,373

Netmaker makes networks with WireGuard. Netmaker automates fast, secure, and distributed virtual networks.

Pros of Netmaker

  • More comprehensive network management features, including a web UI
  • Better scalability for large deployments
  • Built-in support for access control and user management

Cons of Netmaker

  • More complex setup and configuration process
  • Requires additional infrastructure (e.g., database) to run
  • Potentially higher resource usage due to additional features

Code Comparison

n2n (edge.c):

static int edge_init(n2n_edge_t * eee) {
    memset(eee, 0, sizeof(n2n_edge_t));
    eee->start_time = time(NULL);
    eee->allow_routing = 0;
    eee->known_peers    = NULL;
    eee->pending_peers  = NULL;
    eee->last_sweep     = 0;
    eee->last_p2p       = 0;
    eee->last_register_req = 0;
}

Netmaker (netclient/functions/common.go):

func (c *Client) Init() error {
    c.SetDefaults()
    if err := c.ReadConfig(); err != nil {
        return err
    }
    if err := c.SetPeers(); err != nil {
        return err
    }
    return nil
}

Both projects initialize their respective client/edge structures, but Netmaker's approach is more Go-idiomatic with error handling and method chaining.

meshbird logo

meshbird

3,512

Distributed private networking

Pros of Meshbird

  • Built with Go, offering better cross-platform compatibility
  • Designed for distributed systems and cloud environments
  • Supports automatic peer discovery and NAT traversal

Cons of Meshbird

  • Less actively maintained (last commit over 3 years ago)
  • Fewer features compared to n2n
  • Limited documentation and community support

Code Comparison

n2n:

int edge_init(n2n_edge_t* eee) {
    memset(eee, 0, sizeof(n2n_edge_t));
    eee->start_time = time(NULL);
    eee->allow_routing = 0;
    eee->known_peers    = NULL;
    eee->pending_peers  = NULL;
    return 0;
}

Meshbird:

func NewAgent(cfg *Config) (*Agent, error) {
    a := &Agent{
        config: cfg,
        state:  stateInit,
    }
    return a, nil
}

Both projects aim to create peer-to-peer virtual private networks, but they differ in implementation languages and target use cases. n2n is written in C and focuses on creating lightweight, encrypted VPNs, while Meshbird is written in Go and targets distributed systems. n2n has a larger community and more active development, whereas Meshbird offers easier integration with modern cloud environments but lacks recent updates.

xtaci logo

kcptun

13,893

A Quantum-Safe Secure Tunnel based on QPP, KCP, FEC, and N:M multiplexing.

Pros of kcptun

  • Utilizes KCP protocol for improved performance over lossy networks
  • Offers multiple encryption methods for enhanced security
  • Supports both client and server modes for versatile deployment

Cons of kcptun

  • May have higher CPU usage due to KCP protocol overhead
  • Limited to TCP traffic, unlike n2n's support for both TCP and UDP
  • Requires more complex configuration compared to n2n's simpler setup

Code Comparison

kcptun (Go):

func (l *Listener) AcceptKCP() (*UDPSession, error) {
    var timeout <-chan time.Time
    if l.rd > 0 {
        timeout = time.After(l.rd)
    }
    select {
    case conn := <-l.chAccepts:
        return conn, nil
    case <-timeout:
        return nil, &errTimeout{}
    }
}

n2n (C):

int edge_init(n2n_edge_t *eee) {
    memset(eee, 0, sizeof(n2n_edge_t));
    eee->start_time = time(NULL);
    eee->allow_routing = 0;
    eee->known_peers = NULL;
    eee->pending_peers = NULL;
    return 0;
}

The code snippets showcase different programming languages and approaches, with kcptun focusing on KCP session handling in Go, while n2n initializes edge structures in C.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Build Status

n2n

n2n is a light VPN software which makes it easy to create virtual networks bypassing intermediate firewalls.

In order to start using n2n, two elements are required:

  • A supernode: it allows edge nodes to announce and discover other nodes. It must have a port publicly accessible on internet.
  • edge nodes: the nodes which will be a part of the virtual networks

A virtual network shared between multiple edge nodes in n2n is called a community. A single supernode can relay multiple communities and a single computer can be part of multiple communities at the same time. An encryption key can be used by the edge nodes to encrypt the packets within their community.

n2n tries to establish a direct peer-to-peer connection via udp between the edge nodes when possible. When this is not possible (usually due to special NAT devices), the supernode is also used to relay the packets.

Quick Setup

Some Linux distributions already provide n2n as a package so a simple sudo apt install n2n will do the work. Alternatively, up-to-date packages for most distributions are available on ntop repositories.

On host1 run:

$ sudo edge -c mynetwork -k mysecretpass -a 192.168.100.1 -f -l supernode.ntop.org:7777

On host2 run:

$ sudo edge -c mynetwork -k mysecretpass -a 192.168.100.2 -f -l supernode.ntop.org:7777

Now the two hosts can ping each other.

IMPORTANT It is strongly advised to choose a custom community name (-c) and a secret encryption key (-k) in order to prevent other users from connecting to your computer. For the privacy of your data sent and to reduce the server load of supernode.ntop.org, it is also suggested to set up a custom supernode as explained below.

Setting up a Custom Supernode

You can create your own infrastructure by setting up a supernode on a public server (e.g. a VPS). You just need to open a single port (1234 in the example below) on your firewall (usually iptables).

  1. Install the n2n package
  2. Edit /etc/n2n/supernode.conf and add the following: 
    -p=1234
  3. Start the supernode service with sudo systemctl start supernode
  4. Optionally enable supernode start on boot: sudo systemctl enable supernode

Now the supernode service should be up and running on port 1234. On your edge nodes you can now specify -l your_supernode_ip:1234 to use it. All the edge nodes must use the same supernode.

Manual Compilation

On Linux, compilation from source is straight forward:

./autogen.sh
./configure
make

# optionally install
make install

For Windows, MacOS, optimizations and general building options, please check out Building documentation for compilation and running.

IMPORTANT It is generally recommended to use the latest stable release. Please note that the current dev branch usually is not guaranteed to be backward compatible neither with the latest stable release nor with previous dev states. On the other hand, if you dare to try bleeding edge features, you are encouraged to compile from dev – just keep track of sometimes rapidly occuring changes. Feedback in the Issues section is appreciated.

Security Considerations

When payload encryption is enabled (provide a key using -k), the supernode will not be able to decrypt the traffic exchanged between two edge nodes but it will know that edge A is talking with edge B.

The choice of encryption schemes that can be applied to payload has recently been enhanced. Please have a look at Crypto description for a quick comparison chart to help make a choice. n2n edge nodes use AES encryption by default. Other ciphers can be chosen using the -A_ option.

A benchmark of the encryption methods is available when compiled from source with tools/n2n-benchmark.

The header which contains some metadata like the virtual MAC address of the edge nodes, their IP address, their real hostname and the community name optionally can be encrypted applying -H on the edges.

Advanced Configuration

More information about communities, support for multiple supernodes, routing, traffic restrictions and on how to run an edge as a service is available in the more detailed documentation.

Contribution

You can contribute to n2n in various ways:

  • Update an open issue or create a new one with detailed information
  • Propose new features
  • Improve the documentation
  • Provide pull requests with enhancements

For details about the internals of n2n check out the Hacking guide.

Further Readings and Related Projects

Answers to frequently asked questions can be found in our FAQ document.

Here is a list of third-party projects connected to this repository:

  • Collection of pre-built binaries for Windows: lucktu
  • n2n for Android: hin2n
  • Docker images: Docker Hub
  • Go bindings, management daemons and CLIs for n2n edges and supernodes, Docker, Kubernetes & Helm Charts: pojntfx/gon2n
  • Windows GUI (along with a custom version of n2n) but also working with regular n2n: HappyNet

(C) 2007-22 - ntop.org and contributors