Anywherelan (awl): a peer-to-peer mesh VPN with no coordination server

The problem awl solves, and who it is actually for

A laptop behind a home NAT, a server in a rack, an old Android phone that runs one app you still need: these machines cannot reach each other by default, and the usual fixes cost either money or exposure. Port forwarding puts a service on the public internet. A commercial mesh VPN puts a coordination server in the middle, which means an account, a control plane someone else operates, and a single endpoint that can be blocked or shut down.

Anywherelan takes the third path. It is a peer-to-peer mesh VPN that gives each device a stable .awl address and connects them at the IP level, so SSH, RDP, VNC and selfhosted web apps work as if the machines shared a LAN. The README is explicit about the audience: personal use, selfhosters, groups of friends, small device fleets of roughly ten machines. It also states plainly that awl is not a replacement for commercial mesh VPNs in a team setting, because there are no ACLs, tags, SSO or admin dashboards. That honesty is worth more than a feature list.

The pitch that separates awl from Tailscale, Netbird and ZeroTier is decentralization. There is no coordination server to trust, fund or depend on. Peers find each other through libp2p's DHT and connect directly. The README argues this also makes the network harder to block, since there is no single endpoint an ISP or government can blackhole. That is a real architectural difference, not marketing: it changes who can turn your network off.

How awl moves packets: TUN, libp2p and the DHT

The mechanism is two layers stacked. The bottom layer is a virtual network interface: TUN on Linux, macOS and Android, wintun on Windows. The top layer is a peer-to-peer networking stack built on libp2p. IP packets written into the awl interface are wrapped into libp2p streams and delivered directly to the addressed peer.

Discovery works through the libp2p DHT. On startup, awl announces itself via community bootstrap nodes, and to reach a peer it looks that peer up in the DHT before opening a connection. Transport is negotiated per connection: QUIC with native TLS 1.3, or TCP+TLS. NAT traversal is libp2p's job, and when both peers sit behind restrictive NATs with no direct path available, traffic is forwarded through a libp2p circuit relay. According to the README, relays only see encrypted bytes.

Identity is not a separate layer. Each peer holds an ed25519 keypair, and the peer_id is the public key, so there is no CA and no certificate to revoke. Trust is mutual approval: the README states peers must add each other before traffic flows. The go.mod confirms the shape of the stack: go-libp2p 0.48.0, go-libp2p-kad-dht 0.39.2, quic-go 0.59.1, and a replace directive pointing github.com/tailscale/wf at an anywherelan fork. The wireguard dependency is present for the Windows networking layer rather than as the tunnel protocol, which is a detail worth knowing if you assumed awl was WireGuard-based. It is not.

Installing awl and connecting two devices

The README lists install paths for Android (F-Droid package com.anywherelan.awl), Windows and Linux desktop via awl-tray, macOS, and a Linux server binary called awl. There is also a web UI and a terminal-based client. The fastest way to see the whole thing work is a Linux server plus the web UI.

The README documents install.sh at the repository root, and the release artifacts are the normal distribution channel for the compiled binary. The README does not publish a one-line curl pipe for that script, so fetch it from the repository and read it before running it.

./install.sh

Once the daemon is up, the README points you at the built-in web UI for day-to-day use. Open it in a browser on the same machine and you should see this device's .awl name and a peer list with an option to add one.

Adding a peer is a two-sided action. The README states peers must add each other before traffic flows, so you share the peer identifier from one machine and approve it on the other. After both sides approve, the peer appears in the list with its .awl address, and the built-in DNS means you can reach it by name rather than by IP. The README's example of the naming scheme is work-laptop.awl.

If a connection to that name succeeds, the mesh is working and you can drop the .awl name into SSH or a browser. If it hangs, the peer is either not approved on both sides or no path has been negotiated yet, and the README's note about relay fallback applies.

The SOCKS5 proxy and the full-tunnel exit node

Two features go beyond plain device-to-device reachability, and they are the reason people search for awl in the first place.

The SOCKS5 mode lets you route traffic through a remote device as a proxy. Point a browser or a command-line tool at the SOCKS5 listener on the peer, and requests egress from that peer's network. The practical use the README names is bypassing regional blocks. The v0.17.0 release notes mention a SOCKS5 performance boost, which suggests the implementation was reworked rather than merely added. Note the dependency: go.mod replaces github.com/haxii/socks5 with an anywherelan fork, so the proxy layer is maintained in-tree rather than upstream.

The VPN gateway, sometimes called a full-tunnel exit node, routes all of your traffic through a remote device at the IP layer. It arrived in v0.18.0, and v0.19.0 added the Windows gateway. That sequence matters: the feature is young, and the platform coverage for the gateway is narrower than for the base mesh. If your exit node is a Linux box and your client is Linux or Android, you are on the ground the releases have already covered. If both ends are Windows, you are on the newest path.

The trade-off between the two modes is scope. SOCKS5 is per-application and opt-in: only the programs you configure use the proxy, and everything else keeps its normal route. The gateway is system-wide, which is what you want for a captive-portal-free travel setup and what you do not want if a single misconfigured route can cut off your access to the peer itself.

Where awl is the wrong tool

The README's own tradeoff list is the honest starting point: no centralized policy management, meaning no ACLs, no device tags, no SSO, and a smaller feature set than commercial alternatives. If you are onboarding contractors and need to revoke one person's access to one subnet, awl gives you no console for that. You remove the peer from the other peers' approved lists, one machine at a time.

The relay fallback is the second limitation, and it is structural rather than a bug. When both peers are behind restrictive NATs and no direct path exists, traffic goes through community circuit relays. Those relays are operated by the community, not by you. The README says they see only encrypted bytes, and that is a meaningful protection, but it does not change the fact that your availability depends on infrastructure you do not run. A self-hoster who chose awl precisely to avoid depending on someone else's servers should understand that the dependency is reduced, not eliminated.

Scale is the third boundary. The README describes fleets of roughly ten devices. Nothing in the repository suggests awl was designed for hundreds of peers, and the absence of tags or groups means the per-peer approval model grows linearly with the fleet. Finally, the client coverage is Windows, Linux, macOS and Android. iOS does not appear in the README's feature list or install section.

How awl differs from EdgeVPN and the commercial mesh VPNs

EdgeVPN is the closest comparison in kind: another open-source, peer-to-peer mesh built on libp2p, with no central coordinator. The difference is the surface area. awl ships a GUI on Windows, Linux and macOS, an Android app on F-Droid, a web UI, and a terminal client, plus a SOCKS5 proxy mode and a full-tunnel gateway. That is a product shaped for people who want to click through device approval rather than edit a topology file. If you are choosing between the two, the question is whether you want a GUI and an Android build or a smaller, more scriptable core.

The commercial comparison is a different axis. Tailscale, Netbird and ZeroTier all give you an admin plane: ACLs, tags, SSO, dashboards. awl gives you none of that and instead removes the coordination server entirely. The README's framing is accurate: awl is a different shape, not a worse one. For a team, the admin plane is the product. For one person with ten devices, the admin plane is a dependency you did not ask for.

One more distinction worth stating. awl is not a WireGuard wrapper, despite wireguard appearing in go.mod. The tunnel is libp2p streams over QUIC or TCP+TLS, with ed25519 peer identities. If your mental model of a mesh VPN is WireGuard plus a key distribution service, awl does not fit that model, and its security properties should be evaluated on the libp2p transport docs rather than on WireGuard's.

Maintenance, upgrades and the MPL-2.0 licence

The repository is not archived, and the last push was on 2026-09-07. The release cadence visible in the release list is roughly every two months: v0.17.0 on 2026-04-24, v0.18.0 on 2026-06-28, v0.19.0 on 2026-07-18. The README has an Upgrading section, and go.mod pins Go 1.26.0, so building from source requires a recent toolchain. There is a BUILDING.md at the repository root and a build.sh script, plus a GitHub Actions test workflow referenced by the README badge.

Upgrade cost depends on how you installed it. The desktop and Android builds come from releases and F-Droid, so upgrades follow those channels. A Linux server built from source means tracking the master branch and rebuilding, and the replace directives in go.mod point at anywherelan forks of socks5, go-log and tailscale/wf. Those forks are part of the supply chain you inherit, and they are maintained by the same project rather than by their original authors.

On licensing: awl is MPL-2.0, a file-level copyleft licence. Modifications to MPL-covered files must be published under the same licence, while larger works that combine MPL files with other code can be licensed differently. That is a summary of the licence's general structure, not legal advice, and anyone embedding awl in a product should read the LICENSE file at the repository root and consult counsel if the distinction matters to them. The README notes that the whole stack, including bootstrap nodes and relays, is open source.

Editorial conclusion

Adopt awl if you are a selfhoster or a small group of friends connecting roughly ten devices you own, and you accept that policy lives in each peer's config rather than in an admin console. Do not adopt it if you need ACLs, device tags, SSO or an admin dashboard, because the README states those do not exist. Before committing, verify the peer approval flow on two machines behind the same NAT, confirm the config path for your platform, and check whether your network lets the libp2p DHT and community relays through at all.

Frequently asked questions

Official sources

1. anywherelan/awl on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases