[tor-relays] Call for more Snowflake proxies!

Mailing Lists tor-relays
,
1

Dear relay operators,

The Snowflake network is currently overloaded and we need more Snowflake
proxies.

If you have spare bandwidth or available servers, please consider
running Snowflake proxies.

As online censorship continues to increase around the world --
particularly with the recent Internet restrictions in Iran[1] --, we are
seeing a significant increase on snowflake usage. We urgently need more
Snowflake proxies to help handle this surge and ensure that users can
continue to access the open Internet.

Please share this call with your friends, communities, hackerspaces and
anyone who may be able to help!

Gus

How to help

There are multiple ways to run snowflake proxies:

FAQ for relay operators

Q: I’m operating a Tor relay, can I run a Snowflake proxy on the same IP?
A: It might not be helpful for censored users as Tor relays are
frequently blocked on censored regions.

Q: I’m operating a Tor bridge, can I run a Snowflake proxy on the same IP?
A: It might expose your bridge IP address and censors might take this
opportunity to block your bridge.

Q: Can I run Snowflake proxy for a short period?
A: Yes. Proxies can run for any amount of time. Even short periods help
increase available capacity.

Q: Do I need to share my Snowflake proxy manually?
A: No. Your proxy is automatically distributed by the Snowflake broker.
After setup, no further action is required.

Q: Where can I see Snowflake proxy statistics?
A: Snowflake proxy statistics are available from Tor Collector. You can
download the data here: Index of /recent/snowflakes.

[1] Censorship analysis in Iran: [Iran] unrest 2025-2026 (#40068) · Issues · The Tor Project / Anti-censorship / censorship-analysis · GitLab.

–
The Tor Project
Community Team Lead

7 Likes
2

Hello.

It seems like 2.10.1, at least, does not respect -outbound-address and
always tries to use the default IP. Unfortunately this means I won't be
able to run a Snowflake proxy for now, as the default IP is a Tor exit.

If I can't find a simple workaround, I'll see if I can set up a firewall
rule to NAT it, or I'll write a simple LD_PRELOAD wrapper.

Regards,
forest

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

3

Hello.

This is the workaround I came up with, so I wrote a simple guide. It
assumes you are running Debian stable with two IPv4 addresses, one of
which has never been used to relay Tor traffic, and are using nftables
for your firewall. The iptables version should be just as simple.

Add the following postrouting chain to your nftables config, changing
the secondary IPv4 and interface name to whatever you have:

  chain postrouting {
      type nat hook postrouting priority srcnat; policy accept;
      skuid snowflake oif eth0 ip saddr 203.0.113.9 snat to 203.0.113.9
  }

In order to get a not-so-outdated version on Debian stable without using
bloated Docker or compiling from source, you can install the package in
testing. It doesn't require many dependencies since it's a largely self-
contained Go application, so there are no issues with dependency hell.
Put the following in /etc/apt/preferences.d/no-default-testing.pref:

  Package: *
  Pin: release a=testing
  Pin-Priority: -1

Then create /etc/apt/sources.list.d/testing.list and put in:

  deb Index of /debian testing main

Now you will have access to the Debian testing repository, but it won't
try to update your entire system to testing. Update the apt repositories
and install snowflake-proxy from testing. You have to mask the service
during installation so that it won't automatically start:

  adduser --system --group snowflake
  systemctl mask snowflake-proxy.service
  apt update
  apt install snowflake-proxy/testing
  systemctl unmask snowflake-proxy.service

By default, the systemd unit will try to use a dynamic user. You can
disable that so that it uses a real user in order for nftables to work.
I also add a bit of hardening and block IPv6 so that the proxy doesn't
try to use the same IPv6 subnet that you use to relay traffic. Edit the
service file with "systemctl edit snowflake-proxy.service" and add:

  [Service]
  User=snowflake
  KeyringMode=private
  LockPersonality=yes
  DevicePolicy=closed
  ProtectSystem=strict
  ProtectHome=yes
  ProtectClock=yes
  ProtectKernelLogs=yes
  ProtectKernelModules=yes
  ProtectKernelTunables=yes
  RestrictAddressFamilies=AF_INET
  MemoryDenyWriteExecute=yes
  SystemCallFilter=@system-service # this can be tighter
  AppArmorProfile=snowflake_proxy # so can this

Now create a trivial AppArmor profile for extra security:

  #include <tunables/global>

  profile snowflake_proxy {
    #include <abstractions/base>
    #include <abstractions/openssl>
    #include <abstractions/nameservice>

    /usr/bin/snowflake-proxy mr,
  }

And finally, apply the changes and start the proxy:

  systemctl daemon-reload
  systemctl reload apparmor.service nftables.service
  systemctl enable --now snowflake-proxy.service

If everything went right, you should be running a hardened and fairly
up-to-date snowflake proxy on your Debian Tor relay, without using the
same IP address that you use to relay Tor traffic.

Regards,
forest

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org