I've been using OpenVPN to manage a network between a few computers, but it needs a central server and all data need to go through it. Additionally, changing the central server potentially means updating the whole network.

I'm looking for an open-source decentralized (P2P) VPN network that doesn't require a central server. Requirements:

  • No central server (all peers are equal).
  • Secure - all data must be encrypted. Peers that are allowed to connect should be managed by giving them a signed certificate that others can verify.
  • Some peers don't have a public IP address (and this can change dynamically as some of them could be mobile); the software should be able to determine this and let peers forward traffic as needed.
  • It should be possible to give peers fixed IP addresses in the internal network.
  • The software needs to be actively maintained (to fix security issues).
  • Low memory and CPU impact, if possible.
  • I'm not looking for a Social VPN, in particular, I don't want the system to rely on any social network.
  • Linux and Windows support.
  • The system should run as a system service, without requiring any GUI for administration.
  • Optional IPv6 support would be beneficial (some peers can have a public IPv6 address, but not an IPv4 one).
  • Optionally also internal DNS so all computers can be addressed by local names.

2 Answers 2



At first I thought Tor was the solution for you, but it is an open network: anyone can join, so your "secure" requirement doesn't work.


So I would suggest taking a look at tinc. It's a p2p VPN where peers are authenticated through public keys and supports some NAT transversal, although it may not deal so well with hosts changing addresses because those are hardcoded in the config. It also has full IPv6 support. Short primer:

apt-get install tinc
mkdir -p /etc/tinc/net0/hosts
cat >> /etc/tinc/net0/tinc.conf <<EOF
Name = host
Mode = switch
Address = host.example.com
tinc -n net0 generate-keys
cat >> /etc/tinc/net0/tinc-up <<EOF
ifconfig $INTERFACE netmask up
chmod +x /etc/tinc/net0/tinc-up
tincd -d4 -D -n net0

Do this on each host, changing tinc.conf and tinc-up as appropriate. The hosts directory contains copies of each host's tinc.conf and sharing that configuration is out of band (e.g. I used git).

Also note that there were some serious security issues with Tinc, and it's not clear to me that the security design is sound.


If I would start from scratch now, I would look at Wireguard which has better roaming support and sound crypto. Their quickstart is excellent and basically amounts to:

apt install wireguard-dkms wireguard-tools
ip link add dev wg0 type wireguard
ip address add dev wg0
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
wg set wg0 listen-port 51820 private-key /etc/wireguard/private.key peer $(cat /etc/wireguard/peers/peer0.pub) allowed-ips endpoint
ip link set up dev wg0

This assumes the other has its public key already generated and stored in /etc/wireguard/peers/peer0.pub. That peer should be reachable at and have a similar configuration with assigned on the wg0 interface.

Have fun!


It is not possible without coordinator.

For example you have find some code on github like wireguard-p2p. After searching a bit you will find its dht bootstrap node: bootstrap.ring.cx:4222.

Another thing is hyprspace. It is using IpfsDHT with a list of bootstrap nodes. Of course, this code won't work in China, because GFW is just dropping IPFS traffic. Same thing about Tor and others.

Personally, I am using 2 approaches:

  1. Git repository as coordinator. Each machine updates its own config when it receives RTM_NEWLINK, RTM_DELLINK, RTM_GETLINK. Other machines are watching git repository updates and reading other machine configs. I am using this approach for development purposes to keep machines in the same network.
  2. Your own cloud coordinator. It uses a special tunnel that imitates regular web browser traffic, uses cloud fronting, and is reaching clients in China. I am using this approach for production purposes.

I am not using UDP, because firewalls can just block it or reduce its performance. Of course, I am not recommending using UDP hole punching.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.