One question: How can I force whonix-gw to use my user torrc file instead of the one that resulted from Anon-Connection-Wizard?
Possible answer: Do it by changing 40_tor_control_panel.conf instead of 50_user.conf, I’m I right? But even after changing that one to the snowflake lines I wrote in the previous answer, snowflake still doesn’t work.
@Patrick
More progress:
I just had to change -log-to-state-dir to -logToStateDir for it to be able to log and this is the error that shows what’s preventing snowflake from working:
2020/06/27 10:56:09 BrokerChannel Error: dial tcp: lookup ajax.aspnetcdn.com on [scrubbed]: dial udp [scrubbed]: connect: cannot assign requested address
2020/06/27 10:56:09 Failed to retrieve answer. Retrying in 10 seconds
I even tried with an older version of snowflake (from 9.5a5) and I got the same result.
I don’t have a solution for this.
You can safely delete the auto generated file. Either its contents or the whole file.
I messaged a snowflake dev at the Tor Project (dcf) and he had this to say:
Looks like something in Whonix is preventing snowflake-client from opening a UDP socket to do a DNS lookup for ajax.aspnetcdn.com. It appears that the earlier STUN exchange is working, though, which also involves an exchange of UDP packets. Perhaps Whonix has a special firewall rule to prevent DNS leaks.
You can try adding this to /etc/hosts:
152.199.4.33 ajax.aspnetcdn.com
I tried it and after a while it finally worked, but when I did sudo service tor restart it stopped working. Since that was inconsistent I ended up re-installing whonix-gw and after setting up snowflake again it seems like everything is working again! Sorry for not trying this last solution, but I just wanted to see if the issue was due to the updates to Whonix (hope I won’t frequent this issue again when I will update whonix-gw)
Awesome.
In Qubes sys-whonix by default file /etc/resolv.conf is non-persistent.
Not sure you could use bind-dirs for /etc/resolv.conf since that is a symlink.
see:
ls -la /etc/resolv.*
Adding /etc/resolv.conf.whonix to bind-dirs might work.
Or change /etc/resolv.conf in TemplateVM for persistence. (Which would influence all gateway’s based on that template but that wouldn’t matter if you’re using 1 sys-whonix only and/or always using that transport anyhow. See no downside yet of modification of /etc/resolv.conf in whonix-gw TemplateVM.)
On Qubes persistence:
There is indeed an upgrade which interacts with /etc/hosts see:
Upgrading (dist-upgrade) broke it again. I changed /etc/hosts and it’s seems to work though I don’t know if it work reliably (everytime and without delays in the bootstrap).
Though I wonder if this can be fixed once and for all without this /etc/hosts trick @Patrick
Upgrade after new image will change it once (as linked in previous post) but shouldn’t do it again.
Edited by previous post. Meant /etc/hosts not /etc/resolv.conf but looks like that didn’t cause confusion.
We could hardcode gateway /etc/hosts file with pluggable transports and IPs. Ship such a config by default. I guess there is not too many such cases. Better than enabling system DNS for all of Whonix-Gateway. What do you think?
//cc @HulaHoop
Yes definitely safer that way.
Also I think it’s not just ajax.aspnetcdn.com that needs to be included, but also the crucial domains contained in the ClientTransportPlugin line like in -ice stun:stun.l.google.com:19302.
Hardcoding IP addresses is really to be avoided. DNS exists for a reason. These big companies could change IP addresses for whatever reason and that this would keep breaking.
On the other hand I wonder why it’s required. User debian-tor (and thereby the tor process) already has unrestricted network access. But if tor was to run nslookup ajax.aspnetcdn.com that would fail since /etc/resolv.conf on Whonix-Gateway is non-functional.
For Qubes-Whonix-Gateway this would work.
qubesdb-read /qubes-primary-dns | sudo tee /etc/resolv.conf
But it’s non-persistent.
Tested. Starting as shell under user debian-tor.
sudo -u debian-tor bash
Test nslookup.
nslookup torproject.org
Functional.
Therefore a better solution might be a functional system DNS on Whonix-Gateway but for user debian-tor by default only.
Now what’s a good /etc/resolv.conf for all Whonix platforms?
Does this /etc/resolv.conf work for Whonix KVM?
nameserver 10.0.2.3
What /etc/resolv.conf would work for Whonix KVM? @HulaHoop
How to test: please revere to my previous post
Now that you mention the problems with the IP technique (dynamic upstream IP, different resolv.conf settings for ports) I agree with enabling DNS if well restricted to avoid leaks. I didn;t think the separate snowflake binary can work just under debian-tor
With controlport filtering I’m guessing there’s no way Tor can be tricked into passing sensitive info back to the WS.
Have you decided on the best/minimal resolver to use?
Applications running on the gateway aren’t Tor control protocol filtered. These have direct access. There’s not a lot such applications to my knowledge except nyx, onioncircuits and vanguards. Pluggable transports do not use Tor control protocol as far as I know. Even if they did, unrestricted access is OK as these applications are trusted and the workstation can’t learn about that (only white listed, filtered Tor control protozoic access).
Leaks from workstation to clearnet are very unlikely as long as we don’t enable IP forwarding. A computer connected over LAN direct connection to another computer doesn’t easily get clearnet internet access. (That 's what IP forwarding is for.) Even if gateway had full unrestricted clearnet access, that wouldn’t allow the workstation accessing any clearnet access. Restricting what gateway leaves the gateway is useful for accidental misconfiguration by users and to anonymize APT upgrade traffic.
resolver: None. No special package. Debian standard / default one. libc gethostbyname. My testing instructions above are sufficient. No special/extra DNS resolver package such as bind9 / unbound / dnsmasq required.
It’s a huge jump from “no DNS resolver” to “sophisticated DNS resolver”. Worth going for DNSCrypt? Fingerprintable at ISP level. Required in initial implementation? Also a ton harder to implement.
Thanks for the explanation.
Sounds good.
Overkill. Not worth the trouble without a fitting use case.
What root servers does gethostbyname query? I recommend OpenNIC:
I don’t trust Google for many reasons including their collusion with oppressive governments if it means they can provide service there.
I guess it depends what root servers are not censored in China
If run in VM it asks the virtualizer which then asks the host operating system which then uses the host’s /etc/resolv.conf which probably for most users the IP address of their home router which then uses their internet service provider (ISP) DNS server.
It would be very similar if not the same as using nslookup check.torproject.org on the host operating system.
Still any issue here?
I followed the exact instructions in the wiki again for setting up snowflake (on a fresh Qubes 4.1 install) but it seems that it’s no longer working. Checking /var/run/tor/log I find:
[WARN] Pluggable Transport process terminated with status code 256 [1 duplicate hidden]
I have no idea what’s wrong here. Tried to disable apparmor with sudo systemctl stop apparmor.service but it didn’t help. And I do have all the necessary stuff in /etc/hosts for the DNS lookups.
@Patrick Can you take a look? Meek is getting deprecated so it’s very important to make sure snowflake is working.
Seems like the issue is with AppArmor after all. After following this step I was able to get it working:
As it stands the wiki should be edited: Configure (Private) (Obfuscated) Tor Bridges