1lan

1lan (“One LAN”) makes machines stuck behind NAT and firewalls reachable again - home servers, lab boxes, appliances in the field - by having each one dial home with a persistent reverse SSH tunnel to a relay server you own. Once connected, every client is one SSH command away, and selected service ports (web UIs, media servers, APIs) are reachable through the relay’s hardened HTTPS front end.

It’s the self-hosted answer to commercial tunnel and overlay services: no third-party relay in your traffic path, no proprietary agent, no subscription. The moving parts are deliberately boring - plain OpenSSH, a shell script, and a systemd unit - because boring is auditable.

One name per machine

Every machine gets its own name and answers on port 22, so reaching one is just:

ssh fred-nas.example.com

That works from any network, and scp, rsync, sftp, git and VS Code Remote-SSH all inherit it, because they use SSH underneath. The setup cost on your side is two lines of ~/.ssh/config, once, ever.

How it works

• Each machine runs a small service that establishes and maintains a reverse tunnel to the relay. The connection is outbound, which is why NAT, CGNAT and inbound-blocking firewalls are all irrelevant. It’s idempotent - safe to restart, safe on a timer - and ties the tunnel’s lifetime to the service, so there are no orphaned connections.
• The relay allocates each machine its own address, rather than deriving one from the machine’s IP. Nothing collides, nothing needs renumbering when you add a machine, and a laptop that changes networks keeps its identity.
• Because each machine owns an address outright, its services keep their natural port numbers: your 8096 is reachable as your 8096, no matter how many other machines publish one too.
• Adding a machine or a service is a registry entry. Everything downstream - key authorization, name resolution, TLS virtual hosts - is regenerated from it, never hand-edited.

Locked down by default

The relay account that accepts the tunnels can do exactly one thing: accept reverse port-forwards. No shell, no PTY, no password, and an SSH key restricted to tunnel establishment - a compromise of a field device does not yield a foothold on the relay.

Each machine holds its own key, pinned to its own address, so a compromised machine can bind what belongs to it and nothing belonging to anyone else. That boundary is enforced by the operating system, and we prove it rather than assert it: the test suite establishes two tunnels as two different tenants on a real server and checks that each is refused the other’s address.

Your relay cannot read your traffic. It authenticates who may open which pipe, then forwards ciphertext - your SSH session is end-to-end encrypted to your own machine, whose host key you verify directly. That is a deliberate choice over the simpler design used by proxy-based tunnel services, which decrypt and re-encrypt in the middle.

The public face is a native nginx + ACME TLS proxy driven by a single services registry: virtual hosts and certificate configuration are generated from the registry and installed only after passing configuration tests. Administrative services are never exposed over plaintext HTTP - HTTPS with authentication, always. Default-deny, explicit allow - the same philosophy as everything we build.

Status

1lan runs in production across our own fleet, tunneling everything from AI inference dashboards to media servers. A standalone open release is in preparation. Contact us for deployment, or to talk about managed relay setups.