Not sure if this is related to Whonix 14, but I replaced a KVM Whonix-Gateway 13 by the newest version (14.0.0.7.4) and now I cannot access a v3 hidden service anymore (works with Whonix 13). Am I missing something? Has something changed? Here is what I have done on the Whonix Gateway 14:
copied the v3 hidden server folder containing hostname and keys in/var/lib/tor/ directory of the Whonix-Gateway 14;
added the following lines in /usr/local/etc/torrc.d/50_user.conf (as it was in /etc/tor/torrc in the Whonix 13 Gateway):
HiddenServiceDir /var/lib/tor/server-name/
HiddenServiceVersion 3
HiddenServicePort 80 10.152.152.12 80
Made sure owner of /var/lib/tor/ is debian-tor (sudo chown -R debian-tor:debian-tor /var/lib/tor/)
Then I restarted tor/rebooted the Gateway multiple times. The v3 hidden server is still unreachable (time out).
I checked that the VM where the server is actually located does have the correct internal address 10.152.152.12. It is connected to the Gateway and can reach the external internet through the Gateway (i.e. I can curl urls and I can see that I am connected to Tor).
What is wrong? How to correctly configure the Gateway for v3 hidden services (and maybe v2 too, didnāt try it) in Whonix 14?
Hi. Did you install the latest version of 14? technically not a KVM problem but hopefully we can get to the bottom of it. Have you tried updating from our testers repo?
@Patrick what is the status of Tor v3 support in the latest RC?
Hi. Yes probably not KVM related, must be some kind of misconfiguration somewhere. I downloaded and used this version, I believe it is the last one (14.0.0.7.4):
I will try again later today, maybe Iāll have more luck.
For testing purposes, I have set up a new debian9 virtual machine with another apache2 server and generated a new v3 onion address on the Whonix Gateway. I also assigned a new internal 10.152.152.** address to this dummy devian vm. It works!
But the oriignal server still does not workā¦ I have tried rebooting several times both the Gateway and the vm where the server is located. I have tried changing its IP internal addressā¦ Still no luckā¦ I really donāt know whatās wrong. I have also tried generating a new v3 onion for my server, but it automatically resolves to the first, real v3 address (why?) and then fails to connectā¦
Iāve seen a few posts here about the mysterious āmy v3 onion is suddenly unreachableā (including the Whonix.org v3 onion, which predated my time here), and thought Iād let you know of a known issue about v3 descriptors being re-published to the HSdirs.
I first saw this in OnionShare whilst working on persistent v3 onions there, and this led to it being reported upstream. But even have seen it after migrating a simple website to another server (and migrating its v3 keys) and being surprised it wouldnāt be reachable (but then did, by itself, hours later)
In all such cases, as seem to be the cases Iāve seen in this forum, the v3 onion magically starts working again all by itself later, without any other action taken by the admin. This is because some sort of TTL/counter expires and eventually leads to the v3 onion successfully republishing its descriptor to the HSdir.
A fix has been implemented (we know it fixes the OnionShare use case of re-publishing a v3 descriptor) and is expected to arrive in Tor 0.3.5 in December.
(Note the Tor ticket: the devs there are preoccupied with the fact that it affects āscalabilityā of clustered v3 onions, and generally have overlooked the fact that the bug actually occurs for basic single-server v3 onions (and only when ārestartingā or republishing the key). However, at least one Tor dev in that ticket is aware that it fixes republication of a pre-generated v3 onion key too (the OnionShare use case, and the scenario in which I think many āmy v3 onion has disappeared!ā cases can be attributedā¦ just my theory though.))