Hidden service created by `--torcontrol` does not accept connections (General SOCKS server failure)

schildbach commented at 3:16 pm on May 9, 2022: contributor

I’m using the --torcontrol feature to automatically create a tor hidden service. From the logs, the control connection is established and authenticated, and the hidden service added, and correct onionv3 address assigned. However:

There are no incoming P2P connections via Tor (they fail to connect, see below).
If I try to connect manually, it fails (General SOCKS server failure)

Here is an excerpt of the failure on the tor side:

 0tor_1               | May 09 14:44:44.000 [debug] connection_exit_begin_conn(): Creating new exit connection.
 1tor_1               | May 09 14:44:44.000 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x7f5274f0c200 for circ_id 3666618028, channel ID 5 (0x7f527505dda0)
 2tor_1               | May 09 14:44:44.000 [debug] handle_hs_exit_conn(): Connecting the hidden service rendezvous circuit to the service destination.
 3tor_1               | May 09 14:44:44.000 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x7f5274f0c200 for circ_id 3666618028, channel ID 5 (0x7f527505dda0)
 4tor_1               | May 09 14:44:44.000 [debug] connection_exit_connect(): about to try connecting
 5tor_1               | May 09 14:44:44.000 [debug] connection_connect(): Connecting to "(rendezvous)":38334.
 6tor_1               | May 09 14:44:44.000 [debug] connection_connect_sockaddr(): Connection to socket in progress (sock 12).
 7tor_1               | May 09 14:44:44.000 [debug] connection_add_impl(): new conn type Exit, socket 12, address (rendezvous), n_conns 14.
 8tor_1               | May 09 14:44:44.000 [debug] connection_or_process_cells_from_inbuf(): 15: starting, inbuf_datalen 0 (0 pending in tls object).
 9tor_1               | May 09 14:44:44.000 [debug] conn_write_callback(): socket 12 wants to write.
10tor_1               | May 09 14:44:44.000 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused)
11tor_1               | May 09 14:44:44.000 [debug] connection_edge_end(): Sending end on conn (fd 12).

I specifically wonder why address “(rendezvous)”, and why address 38334? Both are wrong.

I used nc -v -x 127.0.0.1:9050 sxvxellncmexkds7h3kjy62vl67xwvrccqiigrdybbc4jutjf6amtuad.onion 38333 to connect to the hidden service, which yields nc: connection failed, SOCKSv5 error: General SOCKS server failure. @jonatack used bitcoin-cli addnode sxvxellncmexkds7h3kjy62vl67xwvrccqiigrdybbc4jutjf6amtuad.onion onetry on his bitcoin node to the same error message.

My bitcoind options are (env vars are resolved by docker-compose):

 0      -signet=1
 1      -disablewallet=1
 2      -txindex=1
 3      -blockfilterindex=basic
 4      -peerbloomfilters=1
 5      -peerblockfilters=1
 6      -logtimestamps=0
 7      -maxconnections=32
 8      -listen=1
 9      -discover=1
10      -dnsseed=0
11      -onlynet=i2p
12      -i2psam=i2pd:${I2PD_PORT}
13      -i2pacceptincoming=1
14      -onlynet=onion
15      -listenonion=1
16      -onion=tor:${TOR_SOCKS_PORT}
17      -torcontrol=tor:${TOR_CONTROL_PORT}
18      -torpassword=xxx
19      -rpcbind=0.0.0.0:${BITCOIND_RPC_PORT}
20      -rpcallowip=0.0.0.0/0
21      -rpcauth=xxx
22      -rpcthreads=2
23      -par=2
24      -debug=tor

My torrc is pretty default, but I’m using these command line options on top:

0ControlPort 0.0.0.0:9051 HashedControlPassword xxx Log "debug stdout" SafeLogging 0

I’m attaching full logs of bitcoind and tor. log-bitcoind.txt log-tor.txt.gz

I would expect bitcoind to automatically configure the hidden service for me (as documented in tor.md) and listen for incoming tor connections. As a side note, I’ve migrated from the configuration variant that manages the hidden service within tor.

System information

Bitcoin Core 23.0 within Docker version 20.10.12 under Ubuntu 22.04 LTS
Tor 0.4.7.7 within Docker version 20.10.12 under Ubuntu 22.04 LTS
All on an Intel Celeron home server.

schildbach added the label Bug on May 9, 2022

schildbach renamed this:
~~Hiden service created by `--torcontrol` does not accept connections (General SOCKS server failure)~~
Hidden service created by `--torcontrol` does not accept connections (General SOCKS server failure)
on May 9, 2022

schildbach commented at 3:18 pm on November 10, 2022: contributor

I retested this using 24.0rc5, and I also set up a second bitcoind instance just for testing my hidden service. Similar setup, but I use

0-connect=xxx.onion:8333

to specifically only connect to my hidden server (address redacted). However, all I get in the log of the connecting bitcoind is:

0Socks5() connect to xxx.onion:8333 failed: general failure

Note that if I configure a hidden service manually (in the tor container), I can connect. So my test setup seems to be fine.

It would be great if I could somehow see in the logs what bitcoind tells tor via the control port. For example, does it perhaps tell to connect to localhost rather than bitcoind? Does such a tracelog exist?

schildbach commented at 9:57 am on November 11, 2022: contributor

I’m now pretty confident that the hidden service configuration of bitcoind via control port is broken in the following way:

If you bind the port for incoming onion connections via wildcard, like this

0-bind=[::]:8334=onion

it uses that wildcard address as a target address for the hidden service. Which will fail, because a wildcard has a different meaning to the container that has Tor. The result is zero incoming connections via hidden service, and the above errors on the client side of the hidden service.

vasild commented at 11:02 am on November 11, 2022: contributor

The default for signet is -bind=127.0.0.1:38334=onion. From your attached log-bitcoind.txt:

Bound to 127.0.0.1:38334

Then bitcoind is telling the tor daemon to redirect connections destined to the .onion address to 127.0.0.1:38334. This obviously does not work when Tor is running on a different machine than bitcoind. You need to modify the default to something like -bind=a.b.c.d:38334=onion such that bitcoind can bind to a.b.c.d and the tor daemon can connect to it. [::] fulfills the first but not the second :(

Is it not possible to have the docker-assigned IP address of the machine in an environment variable, like e.g. ${TOR_SOCKS_PORT} from above?

schildbach commented at 12:14 pm on November 11, 2022: contributor

Sorry for the signet/mainnet mismatch between my May and current configurations. Btw. the hidden service address from May also doesn’t exist any more, I think.

Then bitcoind is telling the tor daemon to redirect connections destined to the .onion address to 127.0.0.1:38334.

It probably shouldn’t do that and instead print a message to the log? And, like I suggested in the other issue, maybe a configuration option for what address to use in this case would make sense?

Is it not possible to have the docker-assigned IP address of the machine in an environment variable, like e.g. ${TOR_SOCKS_PORT} from above?

Afaik no. Docker recommends using hostnames.

vasild commented at 1:32 pm on November 11, 2022: contributor

It probably shouldn’t do that and instead print a message to the log?

Why? It works well in the default case when tor is on the same machine and -bind=127.0.0.1:8334=onion and -torcontrol=127.0.0.1:9051 (these are the default values). You have changed -torcontrol, but not -bind=...=onion. If you change the latter, then it will work too.

The only problem is that you want to use a hostname instead of an IP address for -bind, right?

schildbach commented at 2:25 pm on November 11, 2022: contributor

What I meant is it should probably not silently convert [::] to 127.0.0.1. Yes, if you bind to 127.0.0.1 then it’s expected to use 127.0.0.1 for the hidden service target. Of course running bitcoind and tor in the same container is not really recommended.

An elegant way to support the container isolated case would be

0-torcontrol=tor:9051
1-bind=bitcoind:8334=onion

or

0-torcontrol=tor:9051
1-bind=[::]:8334=onion
2-hiddenservicetarget=bitcoind:8334

“hiddenservicetarget” being a new option that would separate the bind address from the target address. If it exists, bitcoind would not try to derive the target address from the onion bind address and instead use the value of the option.

I think one of these two ways should be considered in order to support container isolation.

vasild commented at 2:55 pm on November 11, 2022: contributor

What I meant is it should probably not silently convert [::] to 127.0.0.1

Yes, probably it makes sense to print something like “tor control returned an invalid address for the socks5 proxy: [::]:9050, falling back to the default 127.0.0.1:9050`.

I think one of these two ways should be considered in order to support container isolation.

I agree.

kosuodhmwa commented at 5:38 pm on March 28, 2024: none

Hidden service created by --torcontrol does not accept connections (General SOCKS server failure) #25094

Hidden service created by `--torcontrol` does not accept connections (General SOCKS server failure) #25094