Tor Onion Services

The source material covers creating Tor hidden services for the web server, mail server, and XMPP server: each gets a .onion address alongside its regular hostname, allowing access through the Tor network without revealing the server’s IP address.

The reasoning for excluding this is covered in the Tor introduction page and applies here without significant addition.

The short version

The network already has a solution for secure remote access: WireGuard VPN. A device with WireGuard active appears to be on the internal network and can reach every service by its internal hostname. There is no need to expose services to the public internet, with or without Tor, for the remote access use case.

Onion services solve a different problem: server location anonymity from the people accessing the service. That is not a requirement of this network’s threat model. The people accessing these services are known and trusted. Hiding the server’s location from them is not the goal.

The complexity cost of onion services is not trivial. Each service that gets an .onion address requires the Tor daemon to be running, the hidden service directory to be correctly configured and protected, and careful attention to avoid configuration mistakes that leak the server’s real IP address alongside the .onion address. A partially-implemented onion service provides weaker anonymity than none at all.

The source material’s approach

The source material does this carefully and thoroughly. If you are building a network where server location anonymity genuinely matters, the source material’s onion service pages are worth reading alongside the Tor Project’s current documentation:

https://community.torproject.org/onion-services/setup/

The v3 onion service format (56-character .onion addresses) is the current standard. The source material predates v3 in some sections: verify any configuration against the current Tor documentation rather than following the source verbatim.

What this series uses instead

For secure remote access from outside the network: WireGuard VPN, configured on the router section.

For services that genuinely need to be publicly accessible without VPN: nginx reverse proxy with Let’s Encrypt certificates, port forwarding, and rate limiting, as documented in the nginx and firewall sections.

For services that should never be publicly accessible: the internal-only.conf nginx snippet, which restricts access to the internal network address ranges.

This combination covers the access requirements without introducing Tor’s complexity or operational overhead.

This is the third and final page in the Tor section of this series. The Tor introduction, relay, and onion services pages share the same conclusion: Tor is the right tool for specific threat models, and the threat model of this network does not require it. The WireGuard VPN covers the remote access need more effectively for this use case.

Roll Your Own Network / Server. Next: Calibre.