Description
The NAS is at home, the GPU box is at the office, and Ollama is still on the desktop you left behind — all three behind NAT, and none of them belong on the public internet. So you either open a port on the router and worry about it forever, or hand your traffic to some tunnelling service.
Lantunnel puts those machines into a small private mesh that only devices you handed a profile to can join; it calls that a Tunnel. When the network allows it, two peers talk over a direct QUIC path with UDP hole punching; only when that fails do they fall back to a relay — and the Gateway doing the relaying carries ciphertext it cannot read. Either way no router port is opened and no public URL is created.
Identity is signed rather than shared: no Tunnel password, no group secret, no bearer token. Every peer holds its own Ed25519 key, proves possession of it on each attachment, and that key never leaves the machine that generated it. Relayed payloads are sealed with XChaCha20-Poly1305 under keys from an X25519 exchange between the two peers.
A peer can export the private subnets it sits on, so one client at home makes the NAS, the printer and the dashboard reachable to the rest of the mesh. Access policy lives on the target machine — never on the Gateway, never on a server. Written in Rust, Apache-2.0, with clients for macOS, Windows, Linux, Android and iOS.
Direct first: new flows attempt a direct peer-to-peer QUIC path with UDP hole punching, with relay as the fallback rather than the default; the client shows whether the current path is direct or relayed and how many bytes went each way.
End-to-end encryption: relayed payloads are sealed with XChaCha20-Poly1305 under keys negotiated by X25519 between the two peers, so the Gateway forwards bytes it cannot decrypt.
No port forwarding: peers dial out, so 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 is on, making the NAS, printer and cameras on that network reachable from the rest of the Tunnel.
You own the ACL: each client decides what it serves, and the policy stays on the target machine rather than being handed down by a Gateway.
One binary, two shapes:
Apps need no changes: the client exposes a loopback SOCKS5 listener (
Three components, that is all: the client, the Gateway (rendezvous and NAT-traversal signaller, doubling as relay), and
Two ways to run it: take a permanent free Tunnel on lantunnel.app with unlimited direct traffic and LAN devices plus 5 GB a month of relay fallback, or self-host the Gateway from this repository under Apache-2.0 with no metering at all.
Self-hosting specifics: initialise the Gateway with
About iOS: the Android client ships as a signed APK with every release, but there is no iOS download — Apple binds the packet-tunnel entitlements to the developer account that signs the build, so you build that one yourself.
Lantunnel puts those machines into a small private mesh that only devices you handed a profile to can join; it calls that a Tunnel. When the network allows it, two peers talk over a direct QUIC path with UDP hole punching; only when that fails do they fall back to a relay — and the Gateway doing the relaying carries ciphertext it cannot read. Either way no router port is opened and no public URL is created.
Identity is signed rather than shared: no Tunnel password, no group secret, no bearer token. Every peer holds its own Ed25519 key, proves possession of it on each attachment, and that key never leaves the machine that generated it. Relayed payloads are sealed with XChaCha20-Poly1305 under keys from an X25519 exchange between the two peers.
A peer can export the private subnets it sits on, so one client at home makes the NAS, the printer and the dashboard reachable to the rest of the mesh. Access policy lives on the target machine — never on the Gateway, never on a server. Written in Rust, Apache-2.0, with clients for macOS, Windows, Linux, Android and iOS.
Features
Direct first: new flows attempt a direct peer-to-peer QUIC path with UDP hole punching, with relay as the fallback rather than the default; the client shows whether the current path is direct or relayed and how many bytes went each way.
End-to-end encryption: relayed payloads are sealed with XChaCha20-Poly1305 under keys negotiated by X25519 between the two peers, so the Gateway forwards bytes it cannot decrypt.
No port forwarding: peers dial out, so 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 is on, making the NAS, printer and cameras on that network reachable from the rest of the Tunnel.
You own the ACL: each client decides what it serves, and the policy stays on the target machine rather than being handed down by a Gateway.
One binary, two shapes:
lantunnel-client opens a desktop window by default and runs the identical runtime under --headless on a server.Apps need no changes: the client exposes a loopback SOCKS5 listener (
127.0.0.1:1080 by default), or you can enable native routing and use the LAN addresses directly without any app knowing the Tunnel exists.Three components, that is all: the client, the Gateway (rendezvous and NAT-traversal signaller, doubling as relay), and
lantunnel-admin, which creates the Tunnel offline with init-tunnel and add-peer and talks to nothing while doing it.Two ways to run it: take a permanent free Tunnel on lantunnel.app with unlimited direct traffic and LAN devices plus 5 GB a month of relay fallback, or self-host the Gateway from this repository under Apache-2.0 with no metering at all.
Self-hosting specifics: initialise the Gateway with
init --public-ip, which defaults to QUIC on UDP 8443 and mapping on 8444; the private key never leaves the Gateway host, only the public scope file is copied. Building from source needs Rust 1.89+, protoc and Node.About iOS: the Android client ships as a signed APK with every release, but there is no iOS download — Apple binds the packet-tunnel entitlements to the developer account that signs the build, so you build that one yourself.
