(I’m using Whonix with Qubes 4)
After 11/06, it seems that all pluggable transports stopped working for me. I used to use snowflake and then it stopped working, and when I change the torrc file for Whonix to obfs4 it also doesn’t work.
Can anyone else try to reproduce this?
BTW I opened a ticket for that here: ⚓ T997 All pluggable transports stopped working after 11-06-2020
More useful information from my tests: When I setup obfs4 using the Anon-Connection-Wizard the previous obfs4 that I used worked fine. Unfortunately I can’t setup snowflake from it.
So maybe this problem arose from some recent change to the permissions?
Snowflake is still new and could have bugs or our design isn’t currently compatible with it. I don’t think we have it packaged and installed on the GW
As I said it’s not just snowflake, obfs4 also wasn’t working if I change the /usr/local/etc/torrc.d/50_user.conf file (but works for some reason with Anon-Connection-Wizard). Also snowflake used to work fine before the date I gave (for more than 8 months approximately).
This was functional before.
Configure (Private) (Obfuscated) Tor Bridges
I didn’t change anything related. At least not knowingly.
after I add -log snowflake-client.log -log-to-state-dir
[WARN] Managed proxy at ‘/usr/bin/snowflake-client’ reported: flag provided but not defined:
-log-to-state-dir
I doubt that follow up issue is caused by Whonix. snowflake telling you that exactly what you added -log-to-state-dir isn’t supported.
Opportunity to compare configuration files: yours vs created by ACW.
Instructions updated. Tor restart nowadays required for unknown reason and reload insufficient. Didn’t investigate. And while that was a worthwhile fix it didn’t fix the root cause.
My tests outside of Whonix using TBB build-in bridge:
6/25/20, 10:12:14.316 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
6/25/20, 10:12:14.316 [NOTICE] Switching to guard context “bridges” (was using “default”)
6/25/20, 10:12:14.316 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
6/25/20, 10:12:14.316 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
6/25/20, 10:12:14.316 [NOTICE] Opening Socks listener on 127.0.0.1:9150
6/25/20, 10:12:14.316 [NOTICE] Opened Socks listener on 127.0.0.1:9150
6/25/20, 10:12:14.316 [NOTICE] Renaming old configuration file to “/home/user/.tb/tor-browser/Browser/TorBrowser/Data/Tor/torrc.orig.1”
6/25/20, 10:12:15.766 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
6/25/20, 10:12:15.768 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
6/25/20, 10:12:15.769 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
6/25/20, 10:16:49.793 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
6/25/20, 10:16:49.793 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
6/25/20, 10:16:49.793 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
6/25/20, 10:16:49.794 [WARN] 1 connections have failed:
6/25/20, 10:16:49.794 [WARN] 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
6/25/20, 10:16:49.806 [WARN] Pluggable Transport process terminated with status code 0
6/25/20, 10:16:49.816 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
Could be snowflake upstream issues:
Here’s my user file that I’m still using and that has been working with Snowflake for months:
UseBridges 1
ClientTransportPlugin snowflake exec /usr/bin/snowflake-client -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302
Bridge snowflake 0.0.3.0:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72
With snowflake it’s a 50/50 (at least for my NAT), so you just have to sudo service tor restart (or with TB just click on Back and re-configure to snowflake) and it will hopefully work (snowflake is working for me right now with a fresh TB install).
I’ve always used sudo service tor restart instead of reload, but it’s still not working.
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?