Hey @misc,

Here’s a brief rundown of what I’ve been dealing with:

  * tor(1) works flawlessly on my GNU/Linux machine with the exact same
    torrc configuration file, yet it fails miserably on my 64-bit
    netbook (amd64) running -current branch of OpenBSD 7.2

  * Raised the value of kern.maxfiles to 16000 and increased the maximum
    number of open files Tor daemon can utilise, running cap_mkdb(1) on
    the login.conf(5) file afterwards

  * Attempted to connect to the Tor network by using obfuscated bridges
    as well as by giving snowflake proxy a shot—nothing has changed

  * Tried disabling the firewall—to no avail

Since tor(1) works as expected on my GNU/Linux machine, I assume it’s
not about the configuration file being invalid or something like that,
though I tried using the vanilla torrc as well as making changes to it
in a gradual way. Here goes the first snippet:

  $ grep '^[A-Z]' /etc/tor/torrc
  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor

Here’s the second one in which I’m using obfs4proxy(1) without
specifying any bridges:

  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor
  ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy --enableLogging 
--logLevel=DEBUG

Here’s the third one, using snowflake:

  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor
  ClientTransportPlugin snowflake exec /usr/local/bin/snowflake_proxy
  UseBridges 1
  Bridge snowflake 192.0.2.3:1 
url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ 
front=cdn.sstatic.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

And here goes the final snippet:

  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor
  UseBridges 1
  ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy --enableLogging 
--logLevel=DEBUG
  Bridge obfs4 123.456...
  Bridge obfs4 123.456...
  Bridge obfs4 123.456...

NTP daemon states that clock is synchronised:

  $ grep 'clock is now' /var/log/daemon | tail -1
  Mar 11 08:56:18 net ntpd[31223]: clock is now synced

Some logs produced by obfs4proxy(1):

  # cat /var/tor/pt_state/obfs4proxy.log
  2023/03/11 09:12:29 [NOTICE]: obfs4proxy-0.0.14 - launched
  2023/03/11 09:12:29 [INFO]: obfs4proxy - initializing client transport 
listeners
  2023/03/11 09:12:29 [INFO]: obfs4 - registered listener: 127.0.0.1:27287
  2023/03/11 09:12:29 [INFO]: obfs4proxy - accepting connections

Weirdly enough, snowflake appears to be working, but tor(1) is still
unable to start building circuits:

  $ grep 'snowflake_proxy' /var/log/daemon | tail -1
  Mar 11 10:32:36 net snowflake_proxy[29766]: 2023/03/11 10:32:36 In the last 
1h0m0s, there were 15 connections. Traffic Relayed IN 36748 KB, OUT 7983 KB.

Some details of the tor class from login.conf(5):

  $ sed -n '/^tor:/,/^$/p' /etc/login.conf
  tor:\
          :openfiles-max=8192:\
          :tc=daemon:

Finally, here’s the Tor-related snippet taken from /var/log/daemon:

  Mar 11 10:45:11 net Tor[60413]: Tor 0.4.7.13 running on OpenBSD with Libevent 
2.1.12-stable, OpenSSL LibreSSL 3.7.1, Zlib 1.2.13, Liblzma N/A, Libzstd N/A 
and Unknown N/A as libc.
  Mar 11 10:45:11 net Tor[60413]: Tor can't help you if you use it wrong! Learn 
how to be safe at https://support.torproject.org/faq/staying-anonymous/
  Mar 11 10:45:11 net Tor[60413]: Read configuration file "/etc/tor/torrc".
  Mar 11 10:45:11 net Tor[60413]: Opening Socks listener on 127.0.0.1:9050
  Mar 11 10:45:11 net Tor[60413]: Opened Socks listener connection (ready) on 
127.0.0.1:9050
  Mar 11 10:45:11 net Tor[60413]: Parsing GEOIP IPv4 file 
/usr/local/share/tor/geoip.
  Mar 11 10:45:12 net Tor[60413]: Parsing GEOIP IPv6 file 
/usr/local/share/tor/geoip6.
  Mar 11 10:45:14 net Tor[60413]: We were built to run on a 64-bit CPU, with 
OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks 
accelerated support for the NIST P-224 and P-256 groups. Building openssl with 
such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) 
would make ECDH much faster.
  Mar 11 10:45:14 net Tor[60413]: Bootstrapped 0% (starting): Starting
  Mar 11 10:45:20 net Tor[60413]: Starting with guard context "bridges"
  Mar 11 10:45:20 net Tor[60413]: Delaying directory fetches: No running bridges

I would like to reiterate that the firewall has remained being turned
off over the course of these shenanigans, so it’s not about firewall
being the culprit; it’s not about torrc file being invalid either. As
for obfs4proxy(1), it seems to be accepting incoming connections along
with the snowflake proxy.

I realise that such issues keep arising due to my limited knowledge of
the nuts and bolts of the OS, but I look forward to expanding it by
asking for clues and possible hints here on the mailing list!

Reply via email to