A peer-to-peer VPN is a VPN in which devices send encrypted traffic directly to each other instead of through a central server. Some service is still needed to introduce the devices, share their keys and help them through NAT, but once two devices have found a path, packets go straight from one to the other.
"Peer-to-peer VPN" and "mesh VPN" usually describe the same idea from two angles: peer-to-peer is about the data path, mesh about the shape of the network (everyone can reach everyone).
Peer-to-peer vs client-server VPNs
In a client-server VPN, every client connects to a VPN server, and traffic between two clients, or between a client and a server on the far network, passes through it. It's a hub: easy to reason about, but every packet takes the detour, and the hub carries every byte.
In a peer-to-peer VPN, each device holds a key pair and gets a list of the other devices' public keys and addresses from a coordination service. When device A needs to talk to device B, they set up an encrypted session between themselves and send packets directly.
What "direct" needs
Two devices can only exchange packets directly if the networks between them let them. Most devices are behind NAT and firewalls, which drop unsolicited inbound packets. Peer-to-peer VPNs get around this with NAT traversal:
- Each device discovers its public address and port using STUN.
- The devices swap candidate addresses through the coordination service or a relay.
- Both send UDP probes to each other at the same time, so each NAT sees outbound traffic and lets the other side's packets in ("hole punching").
How NAT traversal works covers this step by step.
When peer-to-peer isn't possible
Hole punching fails in some networks: behind a NAT that changes the public port for every destination (symmetric NAT), on networks that block outbound UDP, and through some strict corporate firewalls. A practical peer-to-peer VPN therefore keeps a relay as a fallback: a server both devices can reach outbound, which forwards their packets.
The relay doesn't break the security model as long as traffic is end-to-end encrypted between the two devices. The relay forwards ciphertext and never holds the keys.
What peer-to-peer changes for remote access
- Latency. A direct path follows the shortest route between the two devices. Two machines in the same building talk over the local network, not via a gateway in another region.
- No central bottleneck. Throughput isn't capped by one server's bandwidth.
- No public listener. Devices connect outbound, so there's no VPN port on the internet for scanners to find.
- Per-device identity. Each device has its own keys, which makes per-device access rules possible.
The trade-off: every participating device needs the client, and you depend on the coordination service to tell devices which keys belong to the network.
Peer-to-peer in Peerlify
Peerlify is a peer-to-peer mesh VPN for Windows, macOS and Linux:
- The first packets to a peer go through a Peerlify relay, so connections work immediately. In parallel, the two devices exchange candidate addresses (IPv6, LAN, router-mapped via UPnP/NAT-PMP/PCP, and STUN) and probe each other.
- Once a probe is answered, traffic moves to the direct UDP path without dropping the session. If the direct path stops answering for 20 seconds, it falls back to the relay.
- Symmetric NATs aren't currently traversed, so those pairs stay on the relay, as do networks that block UDP. Relays are reached over TLS-wrapped TCP on port 5879, 443 or 80.
- Either way, traffic is encrypted end to end with AES-256-GCM, and the control plane never carries it.
To see the path for each device:
peerlify list peers -s
peerlify ping 100.100.0.12 --until-directp2p means direct, ERPFServer means relayed. Each reply from peerlify ping shows which path it took:
pong from build-server.k3x9q2m7pa.peerlify.net (100.100.0.12) via RELAY(203.0.113.10:5879) in 58.3ms
pong from build-server.k3x9q2m7pa.peerlify.net (100.100.0.12) via 198.51.100.23:41641 in 12.9msRead more in How mesh VPNs work and the Direct and relayed connections reference.