Reaching Your Own LAN Without Port Forwarding, Public URLs, or a VPN Concentrator

Description and use

Users behind NAT can securely connect to each other using a lightweight self‑hosted Lantunnel mesh that first attempts direct QUIC connections via UDP hole punching, falling back to an encrypted relay only when necessary, without exposing private keys or traffic.

Problem

Users with devices behind NAT need secure, private access to each other without exposing services to the public internet or relying on a VPN concentrator.

Outcome

Users can securely access devices behind NAT without exposing services to the public internet, using a self-hosted gateway and encrypted relay fallback.

Workflow

• 1. Install lantunnel-gateway on a publicly reachable host and run lantunnel-gateway init --public-ip <PUBLIC_IP>.
• 2. On a trusted machine, run lantunnel-admin init-tunnel with gateway details to generate the tunnel signing key and public scope.
• 3. For each device, run lantunnel-admin add-peer to create a signed .peer profile.
• 4. Copy the .peer file to the device and run lantunnel-client tunnel import <file> to establish the tunnel.
• 5. Applications use the local SOCKS5 proxy at 127.0.0.1:1080 or native routes to reach other devices through the tunnel.
• 6. If direct path fails, the gateway relays encrypted traffic using XChaCha20-Poly1305.
• 7. Optional: use the hosted gateway at lantunnel.app for a free, unmetered option.

Evidence

Lantunnel is my attempt at a fourth option: a small private mesh where peers talk directly whenever the network allows it, and where the fallback path still cannot read your traffic.

Source

Relayed payloads are sealed with XChaCha20-Poly1305 under keys derived from an X25519 exchange between the two peers.

Source