TransparentTorProxy (ttp) is a Linux CLI that pushes every system connection through Tor via an nftables ruleset, built for privacy-conscious professionals on machines they control.

TransparentTorProxy, invoked as ttp, is a Python 3.10+ Linux CLI whose entire premise is radical simplicity: one command — sudo ttp start — and every TCP connection and DNS query on the box is pushed through the Tor network. There is no per-application SOCKS5 configuration, no http_proxy environment juggling, no browser proxy pane to forget. The project targets machines running systemd with nftables, requires root for firewall and DNS manipulation, and is MIT-licensed with CI, mkdocs documentation, and PyPI distribution under transparent-tor-proxy. At roughly 39 stars it is a young but unusually well-engineered entry in a category that has historically been dominated by fragile shell scripts.

The README positions ttp explicitly against legacy transparent-proxy tooling like TorGhost and Anonsurf, and the criticism is architectural rather than cosmetic. Those older tools, it argues, overwrote configuration files and built iptables rulesets that failed open — meaning that if the tooling broke mid-session, traffic silently reverted to cleartext. ttp inverts this: it fails closed. An isolated inet ttp nftables table carries a catch-all reject with policy drop on forwarding, so on a crash, watchdog trigger, or unclean exit, traffic is either still routed through Tor or blocked outright. For a privacy tool, that design guarantee is the difference between an inconvenience and a leak.

The second pillar of the design is ephemerality. Session state, generated torrc, the lock file, and logs live exclusively in tmpfs under /run/ttp/ and /run/tor/ttp/. A reboot leaves no residue and no stale locks, which also simplifies crash recovery: the next ttp start detects an orphaned lock file, clears stale mount stacks, and auto-restores. This matters operationally because transparent-proxy failures classically strand users with a broken /etc/resolv.conf or half-flushed firewall rules — a failure mode ttp clearly treats as a first-class design constraint rather than an afterthought.

DNS handling is where most transparent proxies betray their users, and the README devotes real attention to it. Instead of editing /etc/resolv.conf in place, ttp applies a mount --bind overlay with a RAM-backed configuration, plus a volatile drop-in that neutralizes systemd-resolved, and a kernel-level drop on any non-loopback resolver traffic. Beyond the system resolver, the tool blocks port 853 outright (killing DoT), rejects known public DoH resolvers on 443 for both TCP and QUIC, and poisons browser canary domains in torrc so a browser's built-in DoH fallback cannot silently sidestep the tunnel. This multi-layer DNS containment is the kind of detail that separates engineering from scripting.

Integrity is enforced by a watchdog governed by a formal finite state machine — the README references a transitions definition — that monitors the Tor daemon, the nftables chains, and the DNS overlay. Notably, it uses a double inotify watch specifically to catch symlink-target swapping on the overlaid resolver configuration, a subtle attack on bind-mount-based DNS interception. The watchdog's policy is repair-once: if remediation fails or tampering recurs, it applies an emergency killswitch rather than limping along degraded. That fail-closed bias is consistent across the entire architecture and is the project's most coherent theme.

The leak claims are not merely asserted; they are tested. Every containment rule is exercised in an isolated network namespace against the real generated ruleset, and the README emphasizes that each test first proves it can see a leak before asserting that none occurs — a methodological honesty that most privacy tooling never approaches. Users can verify manually after ttp start with ttp check, by confirming the exit IP via check.torproject.org, and by running a DNS leak probe where an empty TXT response is the expected, healthy result under Tor's transparent resolver.

Split tunnelling is supported at two granularities. You can exempt whole users or groups with --bypass-user and --bypass-group, implemented with native nftables UID/GID matching rather than userspace filtering, or run a single command outside Tor with ttp bypass via a cgroups v2 slice. LAN connectivity is preserved — RFC 1918 and link-local subnets stay reachable — so printers and NAS devices continue functioning. IPv6 policy is binary and deliberate: routed through Tor when loopback routing is available, dropped outright when it is not, with no leak path in between.

Tor integration is also isolation-friendly. ttp runs its own volatile ttp-tor.service on non-standard ports (9041, 9054), so it coexists with an existing system Tor instance rather than fighting it for 9050. Bridge support includes obfs4 and snowflake, plus a bring-your-own-daemon mode for operators with custom pluggable-transport setups. On Red Hat-family systems, the installer even detects SELinux enforcing mode and compiles a custom policy module from ttp_tor_policy.te so Tor can bind those non-standard ports — a level of packaging polish confirmed by the offered .deb, .rpm, and makepkg paths.

Installation is straightforward: native packages are recommended (sudo apt install ./transparent-tor-proxy_0.4.9_all.deb on Debian-family, dnf on Fedora), with release assets and a documented verification guide for signature checking. Developers can git clone https://github.com/onyks-os/TransparentTorProxy.git and run sudo ./scripts/install.sh, while pipx and virtualenv flows live in a separate reference. Day-to-day operation is a small verb set: ttp start, ttp stop, ttp status, ttp check, and sudo ttp refresh to rotate circuits for a new exit IP. Full removal is sudo ./scripts/uninstall.sh.

The README deserves credit for candor about limits. A prominent caution states that no tool guarantees anonymity, that behavior — regular browser versus Tor Browser, signing into accounts — dominates outcomes, and a blunt warning tells whistleblowers and high-risk users not to use ttp at all, directing them to audited platforms like Tails or the Tor Browser. That framing matters for professional context: ttp is best understood as a systems-level traffic-engineering tool for authorized privacy work, lab environments, and DNS/IPv6 leak research on hardware you administer — not a substitute for a hardened anonymity operating system.

For defenders and blue-team readers, ttp is equally interesting from the outside. Its footprint is observable: the inet ttp nftables table, the ttp-tor.service systemd unit, bind-mount overlays on /etc/resolv.conf, state in /run/ttp/, and Tor exit-traffic patterns from the host. Anyone auditing a fleet for unsanctioned anonymization will find these artifacts straightforward to detect, which is itself useful knowledge when writing detection rules for Tor relay contact or unexpected nftables table creation.

Overall, ttp earns attention not because transparent Tor proxying is novel — it is not — but because the engineering discipline is: fail-closed firewall semantics, ephemeral state, measured leak claims, formal watchdog logic, and honest threat-model disclaimers. For security professionals who need system-wide Tor coverage on Linux for authorized testing or privacy research, it is a substantially more defensible choice than the legacy scripts it aims to replace, provided it is deployed as one layer in a multi-layered strategy rather than treated as an anonymity guarantee.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.