Lantunnel

---

Your NAS is at home. Your GPU box is in the office. Your ollama instance is on the desktop you left behind. All of them are behind NAT, and none of them should be on the public internet.

Lantunnel puts those machines into one small private mesh — a Tunnel — that only the people you hand a profile to can join. Peers find each other and talk directly when the network allows it. When it does not, they fall back to an encrypted relay through a Gateway that carries ciphertext it cannot read. Either way nothing is published, no router port is opened, and no traffic is decrypted in the middle.

🚀 Don't want to run a Gateway? You don't have to.

lantunnel.app gives every account one permanent Free Tunnel — unlimited direct peer-to-peer traffic, unlimited LAN devices behind each Client, and 5 GB/month of encrypted relay fallback for when direct fails. Create a Tunnel, download the Client, import your profile, done. No server, no certificates, no DNS.

And if you'd rather host the Gateway yourself, that path is in this repository, it is Apache-2.0, and it is not metered at all.

→ Create your free Tunnel

---

Contents

New here? Go straight to Quick start. It lists four ways to run Lantunnel, easiest first — and the first one is three steps with no server to set up.

• The Client — what the app looks like
• Quick start — start here
  • 1. Use the Platform's Gateway — easiest, nothing to deploy
  • 2. Host the Gateway, let the Platform run it
  • 3. Run the Gateway yourself
  • 4. Your own Tunnel, on a friend's Gateway
• What you get · Things people actually use it for
• How it works — the three pieces, and why direct comes first
• What's in this repository
• Building from source · Compatibility
• Related projects · Contributing · License

Going deeper: Full usage guide · Architecture and vocabulary · Wire protocol

---

The Client

Quick start

Four ways to run Lantunnel, ordered by how much you have to set up. Most people want the first one — it needs no server, no certificates, and no DNS.

	You run	You need	What it costs
1. The Platform's Gateway	The Client	An account	Free Tunnel, unlimited direct traffic, 5 GB/month relay
2. Your Gateway, run by the Platform	The Client, and a Gateway host	An account, and a machine with a public address	Paid plan; your relay is not metered
3. Everything yourself	All three pieces	A machine with a public address	Free, Apache-2.0, no account, never contacts the Platform
4. Your Tunnel, a friend's Gateway	The Client, and lantunnel-admin once	A friend already running a Gateway	Free; their machine carries the relay

1. Use the Platform's Gateway — easiest

Nothing to deploy. The Platform runs the Gateway fleet; you run the Client.

1. Install the Client — lantunnel.app/download.
2. Sign in — press Sign in on the Connection screen. The Client shows a short code and opens your browser; approve that code there and the Client is signed in. Nothing to download.
3. Add a Peer — press Add a Peer and pick your Tunnel by name. Then either take a Peer the Tunnel has already issued, or name this device and create a new one. Either way the profile is imported here in the same step.
4. Connect.

Repeat on every device you want in the Tunnel. Then point an app at 127.0.0.1:1080, or turn on native routing and use the LAN addresses directly.

Take the Peer that already exists rather than adding a second one for the same machine. A Peer you leave behind stays in the Tunnel and keeps its address.

Signing in is a desktop and phone feature — a headless Client has no screen to show a code on, so it takes a profile file. Create the Peer at lantunnel.app, download its .peer, and import it:

lantunnel-client tunnel import ./nas.peer

Import .peer does the same in the desktop app, and Android and iOS also import by scanning the profile's QR code.

2. Host the Gateway, let the Platform run it

Your machine carries the traffic, so relay is not metered against you, and the Platform still handles accounts, Tunnel keys, and Peer issuance. You register the Gateway once with a one-time pairing file and it stays connected outbound — no inbound port on the Platform side, no certificate to renew by hand.

→ Platform-connected Gateway installation guide · the same sequence, in this repository

3. Run the Gateway yourself

No account, no Platform, nothing phones home. You create the Tunnel offline with lantunnel-admin, issue one .peer per device, and run lantunnel-gateway on a host with a public address. Everything you need is in this repository under Apache-2.0.

→ Full self-hosted walkthrough

4. Your own Tunnel, on a friend's Gateway

Mode 3 without the server. The Tunnel stays yours — you create it offline and issue your own .peer files — and a friend who already runs a Gateway just admits it. Ask them for the transport, address, data port, mapping port, and, if their certificate is self-signed, the public server.crt:

lantunnel-admin init-tunnel --gateway-transport quic \
  --gateway-ip <THEIR_IP> --gateway-port 8443 --gateway-mapping-port 8444 \
  --gateway-cert ./server.crt --output-dir ./provision

lantunnel-admin add-peer --tunnel ./provision/<tunnel-id>.tunnel \
  --name laptop --output ./provision/laptop.peer

Send them <tunnel-id>.scope, and nothing else. They drop it into their scopes.d and reload; one Gateway admits as many Tunnels as it has scopes.

A .scope is a Tunnel ID and a signing public key. It lets their Gateway admit your Peers and grants nothing else: they cannot issue a Peer into your Tunnel, move one out of it, or read your traffic — relayed bytes are sealed between the two Peers. The .tunnel that signs memberships never leaves your machine.

→ Both sides of a shared Gateway

Being handed a finished .peer from someone else's Tunnel is not a mode of its own: install the Client, Import .peer — or scan its QR code on a phone — and connect. One profile per device, though; a .peer carries that device's private key, so ask for your own rather than sharing another.

📘 Full usage guide — installation, LAN exports, access rules, servers, mobile, troubleshooting →

What you get

Direct-first	New flows try a direct peer-to-peer QUIC path with UDP hole punching. Relay is the fallback, not the default.
End-to-end encrypted	Relayed payloads are sealed with XChaCha20-Poly1305 under keys from an X25519 exchange between the two Peers. The Gateway relays bytes it cannot decrypt.
No port forwarding	Peers dial out. Nothing on your LAN needs an inbound rule, a public IP, or a hostname.
Whole-LAN reach	A Peer can export the private subnets it sits on, so one Client on the network makes the NAS, the printer, and the dashboard reachable to the rest of the Tunnel.
You own the ACL	Each Client decides what it will serve. Access policy lives on the target machine — never on the Gateway, never on a server.
One binary, UI or headless	lantunnel-client opens a desktop window by default and runs the exact same runtime under --headless on a server.
Everywhere	macOS, Windows, Linux, Android, and iOS.

Things people actually use it for

• Game and media streaming — Sunshine/Moonlight, Jellyfin, Plex from the machine at home.
• Private AI and dev tools — Ollama, Open WebUI, an internal API, a staging box, a database that must never leave the LAN.
• Home and office services — NAS, Home Assistant, cameras, internal dashboards, SSH.

How it works

flowchart LR
    A["Peer A<br/>laptop"]
    B["Peer B<br/>home NAS"]
    GW["Gateway<br/>forwards ciphertext only<br/>it cannot read it"]
    A <== "① Direct QUIC (preferred)" ==> B
    A -. "② when direct fails" .-> GW
    GW -. "it goes by encrypted relay" .-> B

Three pieces, and that is the whole system:

• lantunnel-client runs on every device that joins. It imports one signed .peer profile, attaches to the Gateway, and exposes a loopback SOCKS5 proxy plus optional native routes so ordinary apps reach the Tunnel without knowing it exists.
• lantunnel-gateway is a rendezvous point and NAT-traversal signaler. It admits a Tunnel by holding its public .scope file, helps Peers punch a direct path, and relays sealed bytes when they cannot. It never holds Peer private keys and never sees plaintext.
• lantunnel-admin creates the Tunnel offline. Two commands: init-tunnel makes the owner file and the Gateway's public scope, add-peer issues one signed profile per device. It talks to nothing.

Identity is signed, not shared. There is no Tunnel password, no group secret, and no bearer token — every Peer holds its own Ed25519 key, proves possession of it on every attachment, and that key never leaves the machine that generated it.

📖 Architecture and concepts → · 📐 Wire protocol →

What's in this repository

Everything needed to run Lantunnel yourself, under Apache-2.0:

Path	What it is
apps/lantunnel-client	The Client. Tauri desktop UI + the headless runtime, one binary.
apps/lantunnel-gateway	The Gateway.
apps/lantunnel-admin	Offline provisioning: init-tunnel, add-peer.
apps/android-proxy	Android app (VpnService).
apps/ios-proxy	iOS app (NetworkExtension).
crates/tp-*	Shared implementation — protocol, transports, proxies, P2P, gateway and client engines.
docs/PROTOCOL.md	Normative wire format.
CONTEXT.md	Architecture and vocabulary.
docs/USAGE.md	How to actually use it.
docs/BUILD_MOBILE.md	Installing the Android APK, and building the iOS Client yourself.

The hosted Lantunnel Platform at lantunnel.app — accounts, billing, managed Gateway fleet — is a separate closed-source service and is not in this repository. Nothing here depends on it. A self-hosted deployment never contacts it.

Building from source

Requires Rust 1.89+, protoc for the gRPC transport, and Node for the Client frontend.

# Gateway and provisioning tool
cargo build --release -p lantunnel-gateway
cargo build --release -p lantunnel-admin

# Client (build the frontend first)
npm --prefix apps/lantunnel-client/frontend ci
npm --prefix apps/lantunnel-client/frontend run build
cargo build --release -p lantunnel-client

On Linux the Client links against webkit2gtk, appindicator, and rsvg; see .github/workflows/ci.yml for the exact -dev packages.

The Android Client ships as a signed APK on every release. The iOS Client has no download — Apple binds the packet-tunnel entitlements to the developer account that signs the build, so you build it under your own. Both are covered in docs/BUILD_MOBILE.md.

Checks, and a three-Peer end-to-end acceptance that proves every directed TCP and UDP pair over Direct and then again over Encrypted Relay:

cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
tests/e2e/v2_docker/run.sh

Compatibility

Peers, Gateways, and profiles must come from the same 2.0.x line — the wire format is not negotiated across versions. Coming from a 1.x install? Its profiles cannot be imported; create new ones with lantunnel-admin.

Related projects

Reaching your own machines behind NAT is a crowded and friendly problem space. Lantunnel takes the peer-to-peer, end-to-end encrypted route; the projects below solve nearby problems in different ways, and several of them pair well with it.

Peer-to-peer and mesh networks

Same goal as Lantunnel — put your own machines on one private network instead of publishing them.

• Tailscale — WireGuard-based mesh; the client is open source, the coordination server is not.
• headscale — self-hosted, open-source implementation of the Tailscale control server.
• ZeroTier — layer-2 overlay network with global roots, written in C++.
• Nebula — certificate-based peer-to-peer overlay from Slack; no WireGuard, no central data path.
• NetBird — WireGuard overlay with SSO, MFA, and granular access policies; hosted or self-hosted.
• Netmaker — kernel-WireGuard mesh with a self-hosted server and admin UI.
• EasyTier — decentralized Rust mesh VPN with NAT traversal, subnet proxying, and a web console.
• innernet — small Rust WireGuard network that models access as CIDRs rather than ad-hoc ACLs.
• iroh — Rust library that gives your own application QUIC plus NAT traversal, dialing peers by public key.
• MeshLAN — self-hosted P2P-first virtual LAN built on Nebula, with service sharing and multiple relays.

Relay and reverse-proxy tunnels

The other answer to NAT: a public server in the middle that forwards to your LAN. Worth reaching for when you need to hand a URL or a port to someone who will never install a client.

• frp — the reference reverse proxy for exposing a service behind NAT, and the engine most of the tools below drive.
• MoonProxy — free, open-source (MIT) desktop GUI client for frp built on Tauri v2 + Rust + Vue 3, with visual proxy rules, real-time traffic monitoring, and one-click frpc start/stop on Windows and macOS.
• rathole — lightweight, high-performance Rust reverse proxy for NAT traversal.
• frp-panel — multi-node web control panel for managing frp servers and clients.
• chisel — fast TCP/UDP tunnel carried over HTTP, in a single Go binary.
• bore — minimal Rust CLI for exposing one localhost port through a public relay.
• zrok — sharing built on OpenZiti; public or private, ephemeral or reserved.
• sish — HTTP/WS/TCP tunnels to localhost over plain SSH, with nothing to install on the client.
• p2ptunnel — P2P TCP/UDP intranet penetration tunnel that connects directly, without a relay server.
• umbra — self-hosted TCP/UDP gateway for services behind NAT, with source-IP authorization and ticket-based visitor tunnels.

Lists and comparisons

• awesome-tunneling — the reference catalogue of tunneling and overlay-network options, self-hosted and commercial.

Maintain something that belongs here? Open an issue — we are happy to add it.

Contributing

Issues and pull requests are welcome — see CONTRIBUTING.md for build, test, and style guidance. Found a vulnerability? Please report it privately per SECURITY.md rather than in a public issue.

License

Apache License 2.0 — see LICENSE and NOTICE.

---