connecttool-qt turns the Steam network into a LAN for your games

What problem a Steam network relay actually solves

A large share of older and co-operative PC games find peers by scanning the local network, and a TCP forwarder can make two machines believe they are on the same segment. connecttool-qt is a graphical rework of the earlier connecttool project, and its stated purpose is to use the Steam Network for TCP forwarding or for a Tailscale-like remote networking effect in TUN mode. The audience is therefore people who want LAN-style multiplayer with a handful of remote friends, not people who need a general purpose VPN. The project says it improves on the original branch in cross-platform support, network performance and interface quality, and the description is blunt about positioning: use it instead of Tailscale. That last point is a claim about reachability, not about encryption or routing quality. The README also opens with a warning that use may result in an account being banned, with a suggestion to use a secondary account, and it notes that a related tool has spread since 2017 on the same principle without being blocked by Valve. Whatever the accuracy of that history, the reading for an engineer is that this project borrows a commercial platform's network for traffic it was not designed to carry, and that the platform owner reserves the right to act.

Two transports: one TCP forward and one virtual adapter

The feature list names two concrete modes. The first is a single TCP forwarding mode, where one port is proxied through the Steam network to a peer. The second is a cross-platform TUN virtual network card mode, which lets several services believe they are on a shared segment. A TUN device is an operating system level interface, so it needs elevated rights to create and usually needs careful routing, and that is a different operational profile from forwarding a single port on a user port range. There is also an in-room text chat, where right-clicking a message pins it so people joining the room later can see the context. That chat is tied to the room concept rather than to the transport, so it exists in both modes.

A network core that does not depend on Steamworks or Qt

The repository layout is the most useful part of this project for anyone assessing it, because the boundaries are explicit. src/network is a network core with no dependency on Steamworks or on Qt. The Steam SDK adapter exists only in src/integrations/steam, system specific code is collected in src/platform, and external dependency declarations plus vendored sources live in deps. The UI is a separate QML module at modules/ConnectTool with its own C++ backing target and plugin support. The stated technology is Qt 6.11.1 with C++23, strong typed identifiers, a safe protocol codec and structured concurrency, and the interface is built on a pinned version of QmlMaterial to produce a Material Design 3 desktop look. Pinning that library version is what lets the Nix build prefetch by commit and hash.

Building the core tests without a Steamworks SDK

The project lets you build and test the protocol core with no Steamworks present, which is the fastest way to judge whether the code compiles in your environment. The README gives this sequence:

nix develop
cmake --preset core-tests
cmake --build --preset core-tests
ctest --preset core-tests

The full application is a different matter. It needs the Steamworks SDK placed in steamworks/ or sdk/, or the STEAMWORKS_PATH_HINT variable set, and then built with the dev or release presets. The dev build registers protocol unit tests and an offscreen QML smoke test, and a connecttool_ui_qmllint target checks application QML bindings. Outside Nix, a first configure also needs Git LFS, because the Material Symbols font ships inside QmlMaterial. That dependency is a real onboarding step and the README is explicit about it.

Running from Nix and the Apple Silicon gap

For Linux and macOS the README points at the lix package manager, then asks you to download the Steamworks SDK and place the steamwebrtc dynamic library into the matching architecture directory under sdk, noting that it is unnecessary if you do not need ICE direct connections. The SDK location is then exported:

$ export STEAMWORKS_SDK_DIR=/your/path/to/sdk

and the application is launched straight from the flake:

$ nix run github:moeleak/connecttool-qt --impure

Apple Silicon is where the documentation turns cautious. Steamworks currently ships only an x86_64 libsteamwebrtc.dylib, so enabling ICE direct connections means building and running the x86_64 version under Rosetta. The README describes adding both platforms to extra-platforms in /etc/nix/nix.conf, restarting the nix-daemon, then building the x86_64-darwin package with nix build .#packages.x86_64-darwin.default --impure -L and launching the result under arch with arch -x86_64 ./result/bin/connecttool-qt.

Windows users can skip all of this, since compiled binaries are on the releases page.

The AppImage that loads the system Qt instead of its own

On some Linux distributions, including Ubuntu and Linux Mint, the AppImage fails at startup with a Qt version error, because the runtime picks up the system Qt libraries instead of the copy bundled inside the image. Two workarounds are documented. The first clears the library path so the bundled libraries win:

LD_LIBRARY_PATH="" ./connecttool-qt-linux-x86_64.AppImage

The second extracts the image and runs its entry point directly:

./connecttool-qt-linux-x86_64.AppImage --appimage-extract
cd squashfs-root
./AppRun

The README itself calls this a packaging problem that should be fixed properly rather than worked around. That is the honest framing: a user launching the AppImage on Mint hits a wall today, and a second launcher script in the environment becomes part of the operational cost.

What the benchmark target does and does not tell you

The release preset produces a separate binary named connecttool_protocol_benchmark for comparing codec throughput on 1200 byte packets on a single machine:

cmake --preset release
cmake --build --preset release --target connecttool_protocol_benchmark
./build/release/connecttool_protocol_benchmark

The README is careful about what that measures, because packet encoding throughput says nothing about the path between two peers. It points to iperf3 for end to end performance and keeps one historical measurement from the 1.5.x line as a network baseline, a run that reported a sender bitrate of 7.02 Mbits/sec and a receiver bitrate of 6.85 Mbits/sec. Treat that as a snapshot of an older version on one network, not as a target, because the transport path depends on the peers' connections to the Steam network far more than on local code.

Where this tool is the wrong choice

If you need an audited, encrypted or policy-controlled network, this is the wrong project, because it inherits the trust model of a game platform and the README does not document a rollback, an audit trail or a supported upgrade path. If your game already supports remote play or a matchmaking service, the tool adds little. If you want a general purpose mesh, a self-hosted overlay network takes a different approach, operating its own coordination and traversal infrastructure rather than relaying your traffic through a game platform's servers, so it carries the ban risk this project carries and does not. The project itself names Tailscale as the thing it positions against, but the README does not benchmark against it, so treat the comparison as a design claim, not a measurement. Licencing is MIT, and the repository also carries THIRD_PARTY_NOTICES.md and a licenses/ directory for the vendored code in deps, so compliance work extends past the top level file. On maintenance, the last push was on 2026-07-31 and the newest release is v1.6.1-alpha.3, so the current line is still alpha software with a moving target.

Editorial conclusion

connecttool-qt fits a narrow and specific need: playing LAN-only multiplayer with a small group, on Windows, Linux or macOS, when nobody can expose a server to the internet. It does not fit a general networking stack, a team that needs audited traffic, or anyone unwilling to put a Steam account at risk. Before building it, check three things: that you can place the Steamworks SDK, since the full app will not configure without it; that your platform is in the list the README marks as verified, since Apple Silicon needs an x86_64 build under Rosetta for ICE direct connections; and that the Linux AppImage case, where a system Qt 6 shadows the bundled one, is handled by the packaging fix rather than by LD_LIBRARY_PATH at every launch.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. moeleak/connecttool-qt on GitHub
4. README
5. Releases