# snltty/linker: P2P hole punching and server relay for remote networking in C#

> Linker is a GPL-3.0 C# networking tool that combines UDP and TCP hole punching over IPv4 and IPv6 with server relay, virtual NIC subnetting and port forwarding. It targets people who need to reach machines behind NAT without a public address.

**snltty/linker** — Project brief: P2P (UDP+TCP IPV4+IPV6) + . Very distinctive, P2P hole punching (UDP+TCP, IPV4+IPV6) + server forwarding, realizing remote networking and intranet penetration. Make your connected devices scattered around the world as easy to access as if they were in the next room.

- Repository: https://github.com/snltty/linker
- Website: https://linker-doc.snltty.com
- Stars: 1,508 · Forks: 265
- Language: C#
- License: GPL-3.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/snltty-linker

## What snltty/linker solves and who it is aimed at

The README frames the project around one goal: making devices scattered across different networks reachable as if they sat on the same LAN. The mechanism it offers is a tunnel between clients, established either by direct connection or by a relay server. The project is written in C# and licensed GPL-3.0, with the default branch named master.

The audience is fairly specific. You are expected to have machines behind NAT that you want to reach, and the README pushes you toward running your own server rather than relying on someone else's. It states that the official public servers run at 1000Mbps+ and that some free relay nodes exist, but that these come with limits, and it recommends private deployment of your own server. That is an unusual posture for a tool in this space, where hosted coordination is often the default. Here, the operator is the user.

Platform coverage is broad but not complete. The README lists Windows, Linux, Android, Docker, OpenWrt, NAS, PVE, LXC and macOS. It explicitly says iOS is not supported, with the author noting he has no Apple phone and no developer account. If your fleet is iPhone or iPad based, this project is not for you.

## How the tunnel is established: IPv6, UPnP, hole punching, Mesh and relay

The README ranks connection methods by effectiveness. At the top is IPv6 direct connection, available when both sides have IPv6. Next is UPnP direct connection, available when a public IPv4 address exists, using UPnP, NAT-PMP or a configured direct port. Then comes TCP/UDP hole punching, which the README describes as supporting multiple punching methods and a relatively high success rate. Below that is a Mesh network, where clients with better connectivity relay traffic for other clients. Last is server relay, which the README says supports multiple relay nodes and large numbers of devices.

That ordering is the design in miniature. Linker tries to avoid the server for data traffic and only falls back to it when the network will not cooperate. The relay is not a single point of failure by design; the README describes multiple relay nodes rather than one.

Once the tunnel exists, the README separates transport from communication. Communication options are virtual NIC networking (point-to-point, point-to-network, network-to-network, with automatic virtual IP assignment), one-to-one port forwarding, and Socks5 proxying. The README draws a clear line between the last two: port forwarding maps one port to one port and requires specifying ports, while Socks5 can proxy all ports and behaves more like point-to-network. That distinction matters when you have many services on one host and do not want a forwarding rule per service.

## Installing snltty/linker from Docker Hub and running a first relay

The README points to Docker Hub under the image name snltty/linker-musl, and the repository ships an install-package directory and a shells directory at the top level. The documentation site is linked as the usage guide. What follows is drawn from those pointers, not from a run of the software.

The Docker image is the shortest path on a Linux server, since the musl build avoids glibc version issues on minimal hosts. The README gives the image name and links the Docker Hub page for it. The README does not include a docker pull or docker run command in the text, so the exact environment variables and port mappings have to come from the documentation site and the image page rather than from the README.

After pulling the image, start the container and point a client at it. The repository layout shows an install-package directory, which is where packaged installers live for the non-Docker platforms, and a shells directory. On a client, the README lists Windows, Linux, Android, macOS and others as supported targets, with builds published under the releases page. The README does not describe a command-line first-run sequence, so the practical first step is to install the client build for your platform and connect it to the server you deployed. Verify the tunnel mode that actually got negotiated: the README's ranking means a connection can silently fall back from IPv6 direct to relay, and that changes both latency and bandwidth.

## Where Linker's design creates real constraints

The most concrete limitation is stated by the project itself: iOS is not supported. The README gives the reason plainly, and there is no workaround described. If any part of your access pattern depends on an iPhone or iPad client, this tool cannot be that client.

The second constraint is operational. Because the README recommends private deployment and describes the public servers as limited, you are signing up to run and maintain at least one relay node. That node is reachable from the internet and carries traffic when hole punching fails, so its bandwidth and availability set the floor for your worst-case connection. A relay that is down does not degrade the tunnel; for clients that could not punch through, it removes it.

The third is the fallback ranking itself. Direct IPv6 is listed first, UPnP second, hole punching third, Mesh fourth, relay last. Those modes depend on conditions outside the software: whether your ISP gives you IPv6, whether your router honours UPnP or NAT-PMP, and whether the NAT on both ends permits the punch. The README describes hole punching as having a relatively high success rate, not a guaranteed one. Where it fails, you are on the relay, and the relay is the mode with the least favourable performance characteristics in the project's own ordering.

There is also a protocol-level trade-off the README addresses openly. Under TCP over TCP, it points to a companion project, tun324, to speed up communication, and links a blog post on redirecting a TUN virtual NIC to turn TCP/IP layer three into a layer four proxy. That is an acknowledgement that tunnelling TCP inside TCP has known performance problems, and the fix is an extra component rather than something the tunnel hides.

## Features that go past basic tunnelling: firewall, NAT, FEC and discovery

Several features in the README are not typical of a minimal tunnelling tool. There is an application-layer firewall that applies to virtual NIC traffic, port forwarding and Socks5, and the README gives a concrete example: allowing A to reach B's 3389 while other clients cannot. That is per-client access control at the tunnel layer, not at the host firewall.

Network segment mapping addresses a problem that shows up the moment you join two home networks: both commonly use 192.168.1.0/24, so addresses collide. The README presents segment mapping as the answer. Related is subnet division, described as similar to VLSM but with selectable main and sub network options, supporting communication isolation, one-way communication and two-way communication.

On lossy links, the README describes an optimized FEC implementation with batch encoding, direct output of source packets and batch decoding output, supporting strategic redundancy or multiple transmissions, trading bandwidth for stability. It also describes an optimized KCP with ACK Range, selective acknowledgement, fast retransmit and batch flush, so that port forwarding and Socks5 can run over a UDP tunnel. Both are explicitly bandwidth-for-reliability trades, and the README does not quantify the cost.

Two smaller items are worth noting for anyone with a mixed fleet. Application-layer NAT uses iptables or NetNat by default, and falls back to a built-in application-layer NAT when the system NAT is unavailable. And a discovery protocol proxy covers mDNS, SSDP, LLMNR, NBNS, WS-Discovery and Hikvision SADP, which is what lets devices such as cameras and printers appear across the tunnel. The README says more protocols will be added as they come up, which is an admission that the current list is not exhaustive.

## How Linker differs from FRP and from mesh VPNs

The README itself names FRP as the comparison point for intranet penetration, describing Linker's penetration feature as similar to FRP: reach an internal service through a server using a port or a domain, with scheduled tasks for timed on and off, such as opening the tunnel at 9am daily and closing it an hour later.

The difference in approach is in what happens before the server is used. FRP is a reverse proxy: the client connects out to the server, the server exposes a port, and traffic always flows through that server. Linker treats server relay as the last resort in a ranked list, after IPv6 direct, UPnP direct, TCP/UDP hole punching and Mesh. When punching succeeds, the server coordinates the connection but does not carry the payload. That is the whole point of the project, and it is why the README bothers to rank the modes.

The cost of that approach is variance. An FRP setup has predictable throughput: it is the server's bandwidth. A Linker tunnel can be direct and fast on one network pair and relayed and slower on another, with the mode decided by NAT behaviour you do not control. If you need a stable, predictable path and do not care that traffic transits a server, a reverse proxy is simpler to reason about. If you want the server out of the data path, that is exactly what Linker is built for.

Mesh networking sits between the two. Clients with good connectivity relay for other clients, so the relay role is distributed among peers rather than centralised on one host, though the README does not describe how that election works.

## Licence position and the cost of staying current

The project is GPL-3.0. The README's badge area links to an MIT licence page, which conflicts with the repository's stated GPL-3.0 licence, and the repository also carries a NOTICE file alongside LICENSE. That discrepancy is worth resolving before you build anything on top of the code, since the two licences impose very different obligations on redistribution. This is a description of what the files say, not legal advice; if you plan to ship a modified build, have someone qualified read the actual LICENSE and NOTICE files.

For a self-hosted tool, GPL-3.0 mainly matters if you distribute modified binaries. Running your own relay and clients internally is a different situation from shipping a rebranded client to customers.

Upgrade cost is shaped by the release cadence. The most recent release listed is v2.0.20, dated 2026-08-21, with v2.0.19 on the same date and v2.0.18 on 2026-08-06. Three releases in roughly two weeks, and two of them on one day, suggests active iteration. The last push to the repository was on 2026-08-21, so the codebase was being changed within the last month. The practical implication is that pinning a version is wise for a relay you depend on, because the pace means behaviour can shift between builds. The repository includes a version.txt file and a global.json, which are the places to check what a given build expects.

## Conclusion

Adopt Linker if you control at least one server you can run as a relay and your clients run on Windows, Linux, Android, Docker, OpenWrt, NAS, PVE, LXC or macOS; the README states iOS is not supported. Skip it if you need a zero-configuration hosted service, because the README recommends private deployment and describes the public servers as limited. Before committing, verify that your network allows the hole punching mode you plan to use (IPv6 direct, UPnP, or TCP/UDP hole punching), and read the licence text, since GPL-3.0 governs redistribution of modified builds.

## FAQ

### Which platforms does snltty/linker support?

The README lists Windows, Linux, Android, Docker, OpenWrt, NAS, PVE, LXC and macOS. It states that iOS is not supported because the author has no Apple phone and no developer account.

### Does snltty/linker always route traffic through a server?

No. The README ranks connection methods by effectiveness, with IPv6 direct first, then UPnP direct, then TCP/UDP hole punching, then Mesh, and server relay last. Relay is the fallback when the direct methods do not succeed.

### What is the difference between port forwarding and Socks5 in snltty/linker?

The README states that port forwarding maps ports one-to-one and requires specifying the port, while Socks5 can proxy all ports and behaves similarly to point-to-network access.

### What licence does snltty/linker use?

The repository states GPL-3.0, and a LICENSE and NOTICE file are present at the top level. The README's badge area links to an MIT licence page instead, so the two sources disagree and the files themselves should be checked.

## Sources

- [Official documentation](https://linker-doc.snltty.com)
- [Official README](https://github.com/snltty/linker#readme)
- [Project repository](https://github.com/snltty/linker)
- [Release notes](https://github.com/snltty/linker/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/snltty-linker