Narrowlink: self-hosted remote access without public IPs

The problem is that neither end has an address

Narrowlink is a self-hosted platform for establishing secure remote connections between devices within a network that may be hindered by network address translation or firewalls. The stated use cases are worth reading because they define the scope precisely. One is sharing network access, where you need to work from home and reach a company network that only allows access from within it, so you install the Narrowlink agent on a computer on the company premises and use its internet access without the company's remote access tooling. Another is reaching devices that do not support VPN, such as an IoT sensor, a CCTV camera or a smart TV, by installing the agent on a device on the same network as those devices and connecting from your laptop. The third is using native services like RDP or SSH across different networks when both machines cannot reach each other directly and neither has a public IP address. The fourth is publishing a local webserver on the internet, including letting others publish their webservers on your public IP address.

Three components and a token generator

The architecture consists of three main components plus a helper. The Gateway is the central hub, routing packets between agents, clients and browsers. Agents act as proxies, forwarding packets to or from targeted hosts within the local network, so an agent is the piece that has to be installed on the far side of the NAT. Clients send and receive packets to and from agents, which is how your laptop reaches the target. The Token Generator is responsible for generating the tokens used for authentication and configuration within the Narrowlink network. That last component is a design decision worth noticing. The tokens are what tie a client to a specific agent and a specific published service, and generating them separately from the gateway means the credential material has a defined lifecycle that is not simply a login on the gateway. The repository is a Cargo workspace with members for gateway, network, client, agent, types and token-generator, and the top level mirrors that with a directory for each plus a `deny.toml` for dependency policy checks.

Traffic that looks like browsing, and QUIC when it can be direct

Two decisions shape the network behaviour. The first is that Narrowlink disguises traffic as regular web browsing using the WebSocket over HTTP/S protocol, which the README says enhances privacy and bypasses firewalls. That is why the port and path look like a web request to anything inspecting the flow, and it is a deliberate choice about the traffic shape rather than about the cryptography. The second is peer to peer connectivity, establishing direct connections between clients and agents when possible using the QUIC protocol, to increase performance by avoiding traffic routing through the gateway. The architectural consequence is that the gateway is not always in the path. In the peer to peer case the client and agent talk to each other directly, and the gateway's role shrinks to coordination, which is what makes the SSH and RDP scenario in the README work even when neither side has a public address, since the connection can be established directly using peer-to-peer functionality. The remaining traffic still goes through the gateway, and the design accepts both paths.

Encryption, and the SNI proxy that keeps the gateway blind

End to end encryption uses the Xchacha20-Poly1305 cipher with HMAC-SHA256 for tamper proofing, which covers the traffic between the client and the agent rather than the link to the gateway. The more interesting feature is the SNI proxy, which prevents the gateway from decrypting your TLS traffic by handling it on the agent's server with your certificate. That is a meaningful design position for a system where the gateway is the most attractive target, because a compromised gateway then sees only encrypted bytes and a SNI. Two supporting features make that workable in practice. Automatic certificate provisioning handles the generation and management of TLS certificates for published services using the ACME protocol, so a published webserver gets a real certificate rather than a self signed one. And CDN compatibility lets you set up the gateway behind CDN services to enhance the performance of your services, which is the other half of making a service that looks like ordinary web traffic. The topics on the repository list acme, quic, sni-proxy and p2p, which is the feature set in four words.

Access control and user spaces

Fine grained access control is based on IP addresses, domains and agent names, and the README states the intent directly, which is to allow you to implement zero trust network access policies. The distinction from a conventional VPN is here. A VPN grants a user a place on a network and then relies on the network's own firewall rules for what that user can reach. Narrowlink expresses the policy at the point of access, so an agent is not simply reachable by anyone who has the token, it is reachable in a way you describe per service, per IP range, per domain and per agent name. On top of that there is user management, creating different user spaces with individual access control policies and providing services to multiple users with a single gateway. For a self-hosted platform that several departments share, the user space concept is what makes one gateway viable without one gateway per team, and it is also the thing that most needs reading the documentation for, since how the policies compose is where the complexity lives.

A release profile built for a client binary

The Cargo.toml in the repository is short and its release profile is the interesting part. The workspace lists the members gateway, network, client, agent, types and token-generator with resolver 2, and the clippy lint section sets `unwrap_used` to warn, which is a reasonable stance for a codebase that parses untrusted network input. The patch section redirects the types and network crates to local paths. Then the release profile optimises for size, with opt-level set to z, link time optimization on, codegen units reduced to one, panic set to abort, debug symbols stripped, rpath disabled so the path to the dynamic library is not embedded, debug assertions removed, incremental compilation disabled, overflow checks disabled and symbols stripped. The result is small binaries with no debug information and no panics unwinding. That is a coherent set of choices for software being installed on someone else's machine or shipped in a container image, and it tells you the project expects its clients to be distributed to users rather than run only on a server you control.

Where this is the wrong choice

The limits are worth naming. First, you run the whole thing. The gateway is yours, the agents are yours, the token generator is yours, and there is no hosted offering in the description, so the operational cost of Narrowlink is the cost of running a piece of infrastructure plus the agents on every network you want to reach. That is a real answer for a team that will not use a third party, and a poor trade for an individual. Second, it is a specific shape of solution. It handles NAT and firewalls by making traffic look like web browsing and by going peer to peer where possible, and it is not a general purpose VPN with a different brand, so if you need site to site routing with full protocol support, this is not that. Third, the release history is slow relative to the commits. The recent tags are 0.2.6 from 2024-06-21, 0.2.5 from 2024-03-20 and 0.2.4 from 2024-02-15, while the last push was on 2026-06-13, so the working tree has moved a long way past the last published version, and a self-hosted platform with no tagged release to point at is harder to plan upgrades for. Fourth, the licence is dual, MPL-2.0 and AGPL-3.0, with both LICENSE-MPL-2.0 and LICENSE-AGPL-3.0 files in the repository, and project metadata lists the licence as one GitHub cannot classify, so which terms apply to which component needs reading rather than assuming. Fifth, the whole design assumes you can install an agent on the network you want to reach, which is the whole point for a home or office network and the reason it does not help with a network where you have no foothold at all.

Editorial conclusion

Narrowlink fits a team that needs to reach machines without public addresses and does not want to hand that capability to a third party operator, since the whole platform, gateway included, is yours to run. It is the wrong choice if you need a consumer-grade product with a managed service behind it, since there is no hosted offering in the picture, and the wrong choice if the one thing you need is a plain VPN between two networks you control, since a conventional VPN may be less work. Before you deploy, read the Basic and Extended guides in the documentation, decide which services you need to expose, and check the licence situation, since the project is released under both MPL-2.0 and AGPL-3.0. The last push was on 2026-06-13 with release 0.2.6 published on 2024-06-21.

Frequently asked questions

Official sources

1. Issues
2. narrowlink/narrowlink on GitHub
3. Project website
4. README
5. Releases