Ligolo-ng v0.9.1 turns one TLS callback into routed access
Ligolo-ng v0.9.1 connects a small remote agent to a proxy and presents the far network through a local TUN interface. The proxy uses a gVisor user-space network stack to translate packets into socket operations on the agent. That gives Nmap, RDP clients, and other ordinary network programs a route to the target subnet without individual SOCKS settings. For a pentester moving through a segmented environment, that is a cleaner working model than wrapping every command in proxychains.
The agent is unprivileged, while the proxy owns the TUN interface
In v0.9.1, the agent does not require administrator or root access. The proxy side must be allowed to create a TUN interface and install routes. On Linux, the CLI can create the interface, or the operator can use ip tuntap and ip route. Windows requires the correct wintun.dll beside the program. The official quickstart tells macOS users to choose a utun device and provides a separate route command. Those are operational prerequisites, not optional tuning.
TLS also needs a deliberate choice. The proxy can request a Let's Encrypt certificate, use supplied certificate and key files, or generate a self-signed certificate. Automatic issuance needs port 80 reachable for validation. With self-signed TLS, the docs recommend copying the proxy's certificate fingerprint into the agent command. The -ignore-cert flag exists for labs and debugging, and the documentation warns about man-in-the-middle attacks. A production engagement should carry the fingerprint or a trusted certificate in its deployment procedure.
What happened when we ran it
Our sandbox installed 198 Go packages in 43 seconds, and the build finished successfully in 42 seconds. We tested commit bec34a6, which is the commit named in the v0.9.1 release history. The checkout contained 133 files and about 12,390 lines of source, occupying 1 MB before dependencies. Our test method used a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM, so these results cover repository setup and compilation rather than a privileged TUN session.
The Go test step failed with exit code 1 after 11 seconds. The supplied summary counted 6 passed and 3 failed out of 9. Its tail names pkg/agent/smartping as a failed target, while pkg/protocol, pkg/proxy/netstack, and pkg/relay passed. Several other packages reported that they had no test files. The log does not show why smartping failed, so it would be wrong to blame missing privileges, networking, or a dependency. The useful result is simply that this commit did not pass its full test command in our sandbox.
Our scan found 1 CI workflow, no Dockerfile, and no separate tests directory. Go projects commonly keep test files beside source, and the passing targets show that tests do exist here. The absence of a Dockerfile matters in a different way: operators who want a containerized proxy must own the image, TUN device mapping, capabilities, and route setup themselves. Our run did not measure tunnel speed, packet loss, or scan accuracy, so the README's performance example remains the project's result rather than ours.
SYN scans become connect scans because raw packets stay local
Ligolo-ng v0.9.1 carries TCP and UDP traffic plus ICMP echo requests, but the unprivileged agent cannot forward raw packets. A SYN sent into the TUN interface becomes a connect() call on the remote host, and the proxy synthesizes the corresponding answer. The README tells Nmap users to select --unprivileged or -PE to avoid false positives. This is the central tradeoff: normal tools gain routed access, while low-level packet behavior is approximated.
That tradeoff rules out some reconnaissance methods. Scanners that depend on unusual TCP flags, raw ICMP types, or exact packet responses will not see the same network that a privileged routed host would. The README's supported list is narrow enough to make the boundary clear. Treat service discovery and ordinary TCP connections as the good fit. If an engagement depends on packet craft or forensic fidelity, place a suitable relay inside the network or choose a path that forwards raw traffic.
Two open reports affect macOS routes and hostname TLS
Issue 178 reports that autoroute created a macOS utun interface but route additions returned network is unreachable on Apple Silicon. The reporter documented manual interface addressing and routing that worked around the failure, while leaving the diagnosis to the maintainers. Issue 195, filed September 11 against commit bec34a6, says a bare hostname such as tunnel.example.com:443 leaves the TLS server name empty. The report describes failed certificate validation and missing SNI; pull request 196 proposes a fix.
These reports deserve a pre-engagement check because they touch reachability rather than cosmetic behavior. Use the exact agent connection syntax, certificate mode, proxy operating system, and route layout planned for the job. A 5-minute lab connection can expose the hostname parsing problem, while a route check on macOS can confirm whether autoroute works on that host. Long scan sessions also deserve soak testing: a September pull request discusses connection leaks during repeated short-lived connections, though that change was still open when researched.
The August release and September activity show ongoing maintenance
Release v0.9.1 and the last repository push both landed on August 11, 2026. The release contains fixes for denial-of-service issues reported to the maintainer. GitHub showed 4,967 stars and 20 combined issues and pull requests when fetched. New issue and pull request activity continued on September 11, including the SNI report and its proposed patch. That mix points to an active project with visible defects under discussion, rather than a frozen utility.