Yes, any of the following, apparmor or seccomp is likely the cause.
cat /lib/systemd/system/tor@default.service
apparmor:
# Hardening
AppArmorProfile=system_tor
seccomp:
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
CAP_DAC_OVERRIDE
Thank you so much for your instructions, @Patrick !
As you pointed out, the problem turns out to be a common apparmor issue which has been fixed by:
For Qubes-Whonix, it can be tested as follows:
First, open Whonix-Gateway Template, and write the line below to /etc/apparmor.d/local/system_tor and shutdown the template:
/usr/bin/snowflake-client rix,
Second, open an AppVM that is based on it, and extract the snowflake-client executable from the latest experimental TBB to /usr/bin:
sudo install -o debian-tor -g debian-tor -m 700 snowflake-client /usr/bin/
Third, restart Tor with:
systemctl restart tor
Now, Tor is using snowflake in Whonix-Gateway!
Whoops, I forgot to say the torrc file in AppVM should look like this:
user@host:~$ cat /usr/local/etc/torrc.d/50_user.conf
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 -max 3
Bridge snowflake 0.0.3.0:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72Next tasks:
There are three ways to complete task 1, the methods below should be applicable to many other censorship circumvention tools shipped with TBB :
snowfalke-client executable.Doesnât work for users under censorship?
Great question!
All the traffic in Whonix-Gateway is enforced to go through Tor so if when Tor canât connect to the network but we need to download something without Tor, it becomes a chicken-egg problem. Right?
If we can temporarily and safely allow a clearnet connection, then Github may be the best way to download experimental TBB:
Done:
Once we get snowflake-client into Whonix-Gateway, I will merge this branch into master branch. 
//cc @HulaHoop
iry:
Great question!
All the traffic in Whonix-Gateway is enforced to go through Tor so if when Tor canât connect to the network but we need to download something without Tor, it becomes a chicken-egg problem. Right?
Thatâs it.
If we can temporarily and safely allow a clearnet connection, then Github may be the best way to download experimental TBB:
Itâs possible.
We could do gpg verification, we have such code in tb-updater which
could be made into tpo-downloader but very messy:
iry:
- Whonix distributes the executable ourselves
- pros: more controls by Whonix and it should be more stable
- cons: trust issue, a lot of extra work for Whonix developer
We could handle it âsame way we handle Tor Browser default installation
in Whonix-Workstationâ.
It would require (major workâŚ):
transforming tb-updater into tb-downloader (just a better name, no
actual separate development step, just conceptual for explanation) since
itâs really a downloader, not updater (doesnât persist user settings
like TBB internal updater)
transforming tb-downloader into tpo-downloader
installing tpo-downloader by default on Whonix-Gateway
download, verify, extract snowflake during the build of Whonix (like
tb-updater currently does for Tor Browser on Whonix-Workstation)
Minor (details, easy):
making the Tor Browser Downloader (by Whonix developers) launcher
invisible on Whonix-Gateway using config-package-dev displace (easy
since I did it before many times, existing code examples in Whonix code,
I can handle)
making the snowflake Downloader (by Whonix developers) launcher
invisible on Whonix-Workstation using config-package-dev displace (easy
since I did it before many times, existing code examples in Whonix code,
I can handle)
iry:
There are three ways to complete task 1, the methods below should be applicable to many other censorship circumvention tools shipped with TBB :
- Wait until snowflake-client gets into Debian: Make a deb of snowflake and get into Debian (#19409) ¡ Issues ¡ Legacy / Trac ¡ GitLab
- pros: Whonix developers only need to include snow-flake and future maintenance cost is nearly zero.
- cons: Needs someone to make it into Debain, considering the fate of meek, this may never happen.
This is the very very best solution.
Even snowflake available von deb.torproject.org would be better than anything below which is very hacky, very maintenance intense long time.
âconsidering the fate of meek, this may never happen.â - Why? How is snowflake being blocked by meek?
- Use a script to download the latest experimental TBB in Whonix-Gateway and extracted the
snowfalke-clientexecutable.
- pros: the script will be simple
Not simple unless file hashes are hardcoded since gpg verification automation done right is hard.
- cons: need to figure out how to run the script regularly, a lot of maintenance work
Yes.
- note: it seems these are not blockers at least in the case of snowflake: https://phabricator.whonix.org/T118 and make TBB usable as "system Tor" (#14121) ¡ Issues ¡ Legacy / Trac ¡ GitLab
Correct.
I was thinking that meek never got into Debian because of the lack of manpower and cooperation. Will snowflake suffer from the same fate that it keeps waiting for someone to get it into Debian?
I agree. Here are the 4 ways to distribute snowflake binary:
I am not sure why âgpg verification automation done right is hardâ. Would you please explain it a little bit more?
@iry donât worry about how someone in a censorship zone can bootstrap the Whonix build process. If we assume the user has a currently connecting version and/or managed to get their first image smuggled into the country via sneakernet, it simplifies the model greatly and so using deb.torproject.org becomes the obvious choice to add snowflake support (is it included there now?)
If snowflake is not packaged by Tor devs yet then the next best solution for now is to use the bundled transports in Tor Browser (which we would now include on the GW too) and hide it from the user. I remember we considered this for another ticket too (where we wanted curl to use the torproject.org self signed key when checking for updates to secure it against MITM from exits). This solution has the great advantage where we can make use of the latest and greatest transports now and in the future without having to wait for packaging by any upstream teams. It is also the most realistic path (though inconvenient) if what our past experience is anything to go by. Hopefully after going thru it once it will be set and forget and we can take advantage of it in the future without problems.
iry:
[quote=âPatrick, post:31, topic:5190â]
âconsidering the fate of meek, this may never happen.â - Why? How is
snowflake being blocked by meek?
[/quote]I was thinking that meek never got into Debian because of the lack of
manpower and cooperation. Will snowflake suffer from the same fate that
it keeps waiting for someone to get it into Debian?
Possibly. However, should someone wish to contribute then time spent on
the packaging way is much better spent then solutions below.
iry:
I agree. Here are the 4 ways to distribute snowflake binary:
- Distribute it from deb.torproject.org
- pro: a little bit easier than getting it into Debian
- con 1: torproject.org is already censored, causing a chicken-and-egg problem
Yes, but only matters for downloaded by user after boot based
approaches. Doesnât matter for preinstallation / installation during
Whonix build.
- con 2: still needs someone from TPO to get it into deb.torproject.org
- Distribute it from Debian repository
- pro: Debian repository is not censored in China
Same. Preinstallation / installation during Whonix build would even work
when deb.torproject.org and packages.debian.org both would be censored.
- con 1: need a Debian Maintainer to do the job (Itâs actually really cool if I can do the job but I still need to learn more about Debian packaging and policy.)
- con 2: It needs the approval from TPO. I remember infinity0 was ready to get meek into Debian but never got a response from TPO.
I donât think packing Libre Software and uploading to Debian requires
approval from TPO.
- Distributing it from Whonix repository
- note: Whonix repository is not censored by GFW yet but blocking it wonât cost as much as blocking Debian repository.
Same.
- Distributing it from Whonix Github
- pros: Github is not censored by GFW and download from it will be really fast
Same.
- cons: User must trust Whonix.
If pre-installed during build of Whonix: Same trust issue same as
currently existing with Tor Browser default installation in
Whonix-Workstation.
iry:
[quote=âPatrick, post:31, topic:5190â]
Not simple unless file hashes are hardcoded since gpg verification
automation done right is hard.
[/quote]I am not sure why âgpg verification automation done right is hardâ.
Would you please explain it a little bit more?
Not yet: Make a deb of snowflake and get into Debian (#19409) ¡ Issues ¡ Legacy / Trac ¡ GitLab
Yes! This solution looks very promising to me. 
I agree that it wonât affect Whonix build process.
I still would like to emphasis that having a reliable upgrading path is very important to a censorship circumvention tool. This is because the upgrade of GFW will paralyze the censorship circumvention tools and this always happens unexpectedly. Even if later the circumvention tools got updated, it is still hard for user in censored area to get the latest copy of it.
Let me try this as my next step:
any update on this?
The Tor Project released an addon for Firefox and Chrome so that one can easily run snowflake proxies. You can find their links in this page: snowflake (dot) torproject (dot) org
Snowflake if you donât know is a WebRTC pluggable transport for Tor.
By the way what is the current status on Snowflake support in Whonix? Is there anything more recent than github (dot) com/Whonix/anon-connection-wizard/pull/22 ?