[Quick Start Guide/Fix]Snowflake Proxy in Qubes-Whonix Tor Control Panel


Here is the summarized and easily readable version of my Qubes-Whonix Tor Control Panel snowflake proxy installation fix/guide. The full version of my guide can be found at the bottom of the page.

Tired of your snowflake proxy not working in whonix? Follow the guide! :slight_smile:

Qubes-Whonix Tor Control Panel with Working Snowflake Proxy [Quick Start Guide]

1) whonix-gateway-17 template terminal:

sudo nano /etc/resolv.conf.whonix

Replace “nameserver 10.0.2.3” with “nameserver 10.139.1.1(or the output of ip qubesdb-read /qubes-netvm-primary-dns run in a sys-whonix terminal, which should be 10.139.1.1, but if it is different, then use that output ip)”

Save & exit

2) whonix-workstation-17 template terminal:

qvm-copy-to-vm whonix-gateway-17 /var/cache/tb-binary/.tb/tor-browser/Browser/TorBrowser/Tor/PluggableTransports/snowflake-client

3) whonix-gateway-17 template terminal:

sudo cp ~QubesIncoming/whonix-workstation-17/snowflake-client /usr/bin/snowflake-client

sudo chmod og+rx /usr/bin/snowflake client

sudo nano /usr/share/anon-conection-wizard/bridges_default

Replace snowflake Bridges with:

Bridge snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://1098762253.rsc.cdn77.org/ fronts=docs.plesk.com,www.phpmyadmin.net ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn Bridge snowflake 192.0.2.4:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://1098762253.rsc.cdn77.org/ fronts=docs.plesk.com,www.phpmyadmin.net ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.net:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn

Save & exit

5) Shutdown whonix-gateway-17 template

6) Restart sys-whonix

7) Start Tor Control Panel

Click Stop Tor

Click Configure

Select Bridges type: snowflake

Click Restart Tor

Enjoy Snowflake on Qubes-Whonix working the way it’s supposed to be! :slight_smile:

Here is my original guide, on the Qubes-OS website:

Thanks to u/glockmane for summarizing the guide! :slight_smile:

1 Like

Thank you!

I am not a big fan of maintaining documentation in a forum, because it doesn’t really support collaborative edits.

Much better to have documentation in the wiki:
Snowflake

(Improve the Documentation / Edit the Whonix Wiki)

It seems Debian’s snowflake version is too old so the version coming from Tor Browser Bundle is required?

There is no need for the binary to be owned by debian-tor.

sudo install

I don’t think this is required. A simple copy command should suffice.

sudo cp ~/Qubesincoming/whonix-workstation-17/snowflake-client /usr/bin

For this one, updates would be welcome as pull requests here:
anon-connection-wizard/usr/share/anon-connection-wizard/bridges_default at master ¡ Kicksecure/anon-connection-wizard ¡ GitHub

(Already updated in git by me just now.)

1 Like

Thank you, I had seen you mention that debian-tor was not required in previous posts about the bug, but it was part of the commands I used to get it working(if you read my original guide, there is a paragraph in it even discussing that I don’t know if the command with debian-tor is necessary or not because of your post). thank you, I can now remove it from my guide since i didn’t know if it was required or not.

From my reading into the subject of broken snowflake in whonix, the version of snowflake-client that ships with whonix-gateway-17 is broken(I would have to do a lot of digging to find this as it was found in another forum post and it took days if not weeks of digging to get snowflake to work.) But somebody in the Qubes forum discovered that the version in whonix workstation does work. So to fix the bugs in non-Qubes Whonix snowflake, it seems to be a matter of getting that binary from the workstation into the gateway, that is if it doesn’t work with the new bridges.

I’m not the most skilled linux user, So it’s nice to have one of my posts even noticed by a big shot in the community such as yourself, I almost didn’t want to post this here because I guess I have imposter syndrome, and I figured through all of my reading that you’d have a gajillion people asking you to fix snowflake, and I didn’t want to be one of those…

Also, Patrick, I’m a big fan, I have consulted your posts for solutions a lot over the years(now the tables have turned, just this once :wink: ), allow me to formally introduce myself, haha, it’s weird talking to the person whose posts I have read for years lurking on here. :slight_smile: (senpai noticed me today lol jk)

One question, why is the debian-tor command not needed? I’m a noob about these things. Don’t answer if it’s a waste of your time. I imagine that it’s because the gateway and might workstation share permissions and groups or something. Anyway, there is how you fix snowflake, it would be cool to see my ‘contribution’ working in the next release!(forgive me, i have no clue how a lot of this git dev jargon works.)

Don’t worry about this.

I give you advice on this one once I have one. Just kidding. It’s going to be a long story. The issue is, I don’t know any coherent write-up on Linux file permissions that I can recommend. It’s just bits and pieces I have picked up over the years.

When you check other files in /usr/bin folder (ls -la /usr/bin), lets take this for an example:

-rwxr-xr-x 1 root root 71K Jan 8 2023 xargs

Owned by Linux account user root (left “root word”).
Owned by Linux group root (right “root word”).

-rwxr-xr-x just a weird way to express permissions which is still hard for me to read even after all of these years. Here is some ChartGPT generated text which I can confirm so I don’t have to type it…

The file you provided has the following attributes:

  • -rwxr-xr-x: This indicates the file permissions. Specifically:

    • rwx: The owner (root) has read, write, and execute permissions.
    • r-x: The group (root) has read and execute permissions but cannot write.
    • r-x: Others have read and execute permissions but cannot write.
  • 1: This represents the number of hard links to the file.

  • root root: This indicates the owner and group of the file. In this case, both the owner and group are root.

  • 71K: This is the size of the file in kilobytes (71 kilobytes).

  • Jan 8 2023: This is the last modification date of the file (January 8, 2023).

  • xargs: This is the name of the file, which is typically an executable file used on Unix-like systems. xargs is a command that constructs argument lists and executes commands, often used to build commands from standard input, particularly when dealing with a large number of arguments.

In summary, this file is the xargs executable, owned by the root user, with 71 KB in size, and was last modified on January 8, 2023. It is executable by both the owner and other users.

Linux account user debian-tor (which which Tor is running) only needs to be able to read and execute the file. That’s it. Tor has no business attempting to write to that file. Updates are (ideally) handled by the package manager (APT). (Or in this very special case, the user.)

debian-tor here (in reference to above text) is considered “others”.

How does it help? The theory goes, even if a Linux user account is compromised, it still cannot rewrite files in /usr/bin folder to contain the security breach within the Linux account user. Therefore Linux file permissions should always be minimal.

No, none of that sort.

Since you have shown a big amount of time investment, frustration tolerance, this seems like a good time investment.

Thank you for clearing that up for me! That was very nice of you. I’ll continue to to help any way I can. Cheers! Imposter syndrome level completed.

-amn3sia0x1337

1 Like

Hi thank you for this guide. I implemented all and was working. Unfortunately after the last qubes update of the template snowflake is now stuck on 10%.

Any reasons?
I have log tor snowflake connection files but I cannot paste them here

Thanks in advance for your thoughts / your help
BR