Whonix and Bridges - issue behind restricted firewall

So I’ve followed this https://www.whonix.org/wiki/Bridges using obfs4.
I got a few questions (some may not related to Whonix though).

  1. If I supplied 3 bridges to /etc/tor/torrc, how are they being chosen? In random or first line first?
  2. If the chosen bridges, somehow, doesn’t work (rejecting or broken). Will there be risk of leak? And what will happen - packet is dropped or Tor will choose a new one from the list and continue without dropping (no need to resend).
  3. Is it recommended to put as many bridges as possible in /etc/tor/torrc?
  4. Is it recommended to change list of bridges often?
  5. If using bridges “makes things harder for your ISP to know that you’re using Tor”, then everyone should be using bridges whenever possible? If not, are bridges more vulnerable to attacks compared with entry guards?


Whonix does not modify Tor.
( https://www.whonix.org/wiki/FAQ#Does_Whonix_modify_Tor.3F )

Therefore most of your questions should not be duplicated here as per:

And should be asked in the more appropriate Tor support places.
( https://www.whonix.org/wiki/Support )


Quote from https://www.whonix.org/wiki/Bridges#Additional_info_and_recommendations:

Bridges are less reliable and tend to have lower performance than other entry points. If you live in a uncensored area, they are not necessarily more secure than entry guards. Source: bridge vs non-bridge users anonymity.

Patrick et al

I’ve managed to add bridges to standalone Tor browser and it works in a censored/restricted environment. However, I’ve tried mod’ing /etc/tor/torrc file per instructions for Whonix 12 - no luck. Here is excerpt of my torrc re: bridges:…

UseBridges 1
ClientTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy managed

bridge obfs4 06BE67AF09C5DCEA36551D2EDF231AE6605D4C5F cert=B60Hxey0otVnZ1jFtAJFXvoyLV/4fBRYMrXzT49A8kQtqpZOR6ab0Nwzo7PJae4kWvknNg iat-mode=0
bridge obfs4 1F1C600CE1E854E18123422EAD9267A5943815A4 cert=eDgQIFzrZzadFhWwB4Z9fl3Qlw9NDtbCUUmOsIDcO+73ait26Y0akfaCxL1ppBdKCM8WDw iat-mode=0

I’m running Whonix 12. The bridges were freshly obtained/added. I’ve tried reloading TOR and also tried restarting the Gateway. Have also tried regular bridges and other forms of bridges - none work, same results every which way. Note image below - ARM shows no message traffic.

Suggestion? Advice? - thx!

What platform / virtualizer?

Did you change any networking related settings? Don’t change stuff that is not in documentation. (If you did undo and if you don’t know how then reinstall Whonix.)

Check /var/run/tor/log for any useful messages.

kdesudo kwrite /var/run/tor/log

Any messages about the clock or other hints there?

(Some of these messages are non-issues: https://www.whonix.org/wiki/Tor#Log_Analysis)

Patrick - thx for quick response.

I’m running Whonix 12 via Virtualbox Version 5.0.10 r104061 on Windows 10.

re: network settings - no I didn’t make any changes
re: /usr/share/tor/tor-service-defaults-torrc - no changes

re: /var/run/tor/log - I config’d torrc w/ new bridges and rebooted Gateway

Jan 20 12:42:48.000 [notice] Delaying directory fetches: No running bridges
Jan 20 12:42:48.000 [notice] Signaled readiness to systemd
Jan 20 12:42:50.000 [notice] Bootstrapped 5%: Connecting to directory server
Jan 20 12:42:50.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Jan 20 12:42:51.000 [warn] Proxy Client: unable to connect to ("server rejected connection")
Jan 20 12:42:51.000 [warn] Proxy Client: unable to connect to ("server rejected connection")

re:user@host:/var/log$ tail -f sdwdate.log

1351: sdwdate (not timesync!): signal SIGTERM received...
1351: sdwdate (not timesync!): signal SIGTERM received. Cleaning up...
1351: sdwdate (not timesync!): signal SIGTERM received. Exiting.
1338: Running sdwdate... pid: 1338 | LD_PRELOAD:
1338: sdwdate_preparation: who_ami is set to user.
1338: dispatching DISPATCH_PRE (SDW_MODE: startup): /usr/lib/timesync/timesync_pre --autostart --identifier "timesync" --progressbaridx "$ID" --mode "$SDW_MODE" --whoami "$who_ami"
1338: dispatching DISPATCH_PRE done.
1338: SDWDATE_CURRENT_POOL: SDWDATE_POOL_ONE | array_length: 14 | allowed_member_failures: 5 | temp: 4.76 | array_length_remember: 0
1338: dispatching DISPATCH_PREREQUISITE (SDW_MODE: startup) (LD_PRELOAD: ): /usr/lib/anon-shared-helper-scripts/te_pe_tb_check
1338: DISPATCH_PREREQUISITE exited 2 | Tor is not yet fully bootstrapped. 10 % done. Tor reports: NOTICE BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server" | waiting...

Meanwhile… I have reinstalled Gateway 12 VM from ~.ova. Using identical bridge setup I get same problems when I try to connect in restricted environment [behind workplace firewall] whereas there are no problems connecting Gateway to TOR network using same bridges when I’m in an unrestricted/public environment.

Hope some of this helps.

Thanks! It’s good to understand these reports so we can document this better.

sdwdate log looks like expected in such a situation, no issue there.

Your description indicates that this issue is not caused by Whonix but by the workplace firewall. I speculate, that they likely block these outgoing ports that your bridge is using for any connection. Try using some [private] [obfuscated] bridges on port 80 or 443.

In case you don’t know already, or for other readers, this is what is defined as IP / port in this context. Example:

IP would be Port would be 42061.

(Less likely, I speculate, that they detect and block Tor bridge traffic.)

Or if you do not try to hide being a Tor user, you could try not using bridges. Use the public Tor network. And the following setting in /etc/tor/torrc, which will limit Tor’s outgoing ports to 80 and 443.

FascistFirewall 1

Please report if this solves it for you.

The FascistFirewall option is now fully documented here:


[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]