Inbound Connection not possible when running a node behind tor.

[ziggie1984]

My Understanding of the issue:

Umbrel runs one tor_proxy with a specified controlport and SOCKSPort (10.21.21.11) and a bunch of tor instances which soley act as relay from the outside (SOCKSPort 0).

Here is the problem:

Bitcoind is not able to fetch its .onion address bc for this it needs connection to a running tor-instance with a control port. So thats why my output of the bitcoin-cli getnetworkinfo shows an empty address array. Even when I try to past the onion address I can find in /data/tor/bitcoin-p2p (externalip=ONION_ADDR) bitcoind is not able to get inbound connections to my onion address.

In the bitcoind logfiles I clearly see an error related to the control port:

2022-05-21T09:57:37Z tor: Error connecting to Tor control socket

When I try to set the -torcontrol=tor_proxy:29501 bitcoind is able to create a hidden service and it shows up in the addresses of the bitcoin-cli getnetworkinfo command but the problem there is, that now bitcoind want to access the proxy on 127.0.0.1:9050 which is somehow not possible and I get a refused log:

 connect() to 127.0.0.1:9050 failed after wait: Connection refused (111)

I am not sure why bitcoind now looks for the proxy on the localhost although the proxy setting in the bitcoin.conf is proxy=10.21.21.11:9050.

Seems like some of the configuartion is not compatible with the bitcoin daemon, any clarification of the problem is much appreciated.

[kroese]

Very good catch!

I think there are two solutions: OR let Bitcoin connect to the controlport OR let Bitcoin know the existing addres. It all depends on wether Umbrel already creates these addresses during installation. In which case it only needs to add:

externalip=addressofhiddenservice.onion

to bitcoin.conf so it knows which address to advertise.

[kroese]

@ziggie1984 I created a pull request which fixes this issue. See #1408

[5dsadsa8ds]

@kroese AFAIK bitcoin.conf is not part of umbrel anymore since v0.5.0

that file is removed by the migration script: https://github.com/getumbrel/umbrel/blob/79fcec983b62dc7b3e7a5d2469c08eb14be85cfa/scripts/update/steps/migrate-bitcoin.sh#L60

[kroese]

@5dsadsa8ds I created that pull before 0.5 was released, made a new one now.

[5dsadsa8ds]

I've been experimenting a bit with the --externalip set but so far I've yet to see a inbound TOR connection after around 48hours of running over a stable connection

been monitoring closely ./umbrel/scripts/app compose bitcoin exec bitcoind bitcoin-cli getpeerinfo

and so far the only inbound connections are local ones from local umbrel apps :(

Local addresses is properly shown on ./umbrel/scripts/app compose bitcoin exec bitcoind bitcoin-cli -netinfo

[kroese]

At least it should advertise your address to other nodes now. It does take some time for everybody to receive that announcement, but 48 hours seems long enough.

If you are willing to share your address I can see if I can make a connection to it?

[5dsadsa8ds]

I've tested and it's reachable over TOR.

Maybe that's normal to not see inbound connections over TOR, are you getting inbound connections spontaneously?

[kroese]

I've looked into this a bit more. It seems that bitcoind uses a special port for incoming tor connections (8334 instead of 8333). It does this so it can differentiate between which peers are tor and which ones are ipv4 (because it is hard to tell otherwise, since incoming tor connections look just like a normal ipv4 connections).

The umbrel hidden service uses 8333, so all incoming tor connections show up as ipv4 in getpeerinfo. So you will never see any incoming tor listed there. Only solution right now is to check if the incoming ipv4 are from an exit-node or not to determine it.

[5dsadsa8ds]

@kroese are you getting any in connection at all on your node after a few days of running with that patch?

For example when running this command: ./umbrel/scripts/app compose bitcoin exec bitcoind bitcoin-cli -netinf

I never see in connections at all

and double checking the details with ./umbrel/scripts/app compose bitcoin exec bitcoind bitcoin-cli getpeerinfo

I can confirm that they are all outbound

[kroese]

@5dsadsa8ds I am not sure, because I was looking at the tor column instead of ipv4, and my node is also reachable over ipv4 so I have a lot of inbound there (which may have been tor connections).

If you go to this website, https://bitnodes.io/#join-the-network , you can fill in your onion address and it will make an inbound connection to fetch your nodes info.

[5dsadsa8ds]

Yeah, I've been testing with that site as well but it works even on vanilla Umbrel without your patch.

So, even without the patch, seems like the node is reachable over the onion address.

for some reasons tho both with and without patch it's not advertised into peering list of other clients that find it only when manually adding and not "naturally"

[kroese]

The node is reachable without the patch, but the patch causes the node to advertise that address to others (as can be seen with -netinfo). Without advertising the address you will never get any inbound.

[5dsadsa8ds]

yeah, you are right

without the patch the it is reported as: Local addresses: n/a

with the patch instead it shows its own onion address

[lukechilds]

Hey guys, this decision was made intentionally because it opens up DoS attack risks. Inbound connections over Tor are possible, Bitcoin Core just doesn't broadcast your Tor address publicly, so only peers you intentionally share your address with can make inbound connections to you. This was done so you can still pair client wallets that can connect to a trusted node via it's P2P port with Umbrel.

We enable peerbloomfilters to allow connecting BIP37 clients to Umbrel. There are some DoS risks with having BIP37 enabled for nodes publicly exposed. However it's safe if your node is not publicly reachable and you only manually add trusted wallet clients as peers.

Even without the DoS risk, I'm still not sure this is a sensible default for most Umbrel users. You could potentially end up uploading hundreds of GBs to other nodes as you serve them for their IBD. That could seriously disrupt many users home internet connections. You can limit upload with maxuploadtarget to some sort of sensible amount, but then you introduce a new DoS attack vector where someone can pull blocks from your node until you hit your maxuploadtarget limit and then disconnect your full node from any of your SPV connected wallet clients.

Ultimately, we don't think this makes sense as a default enabled option for users. If you're someone technical who's aware of the risks and increased bandwidth usage and still want to enable this you can do it manually by creating a bitcoin.conf file at app-data/bitcoin/data/bitcoin/bitcoin.conf with the contents:

externalip=yourP2pTorHiddenService.onion

[kroese]

@lukechilds Both of the potential dangers (some peer executing a cpu-heavy bloom filter or requesting lots of blocks), do also apply to outbound peers.

So you still have the same risk to get DoSed in the current situation, wether the peer is inbound or outbound makes little difference for that. As it only needs 1 connection to do it (unlike a traditional DoS where you are flooded by connections).

The only difference is that it would be harder for the attacker to do some kind of targeted attack on your node. But as the node is running fully anonymous behind Tor, I cannot really see a real-world scenario where that would apply.

And yes, since Bitcoin accepts 150 inbound peers by default and only 10 outbound, you will use more bandwith in any case. But it's very simple to limit that number to a ratio of 10 in and 10 out for example.

[5dsadsa8ds]

bitcoin app has now been updated on master.

I tried to update it on a vanilla umbrel but apparently https://bitnodes.io/ cannot connect to 8334 (over tor) and fails most of the time while checking 8333

is there maybe some limits on the amount of inbound connections that could be stopping that?

[nevets963]

@5dsadsa8ds The bugfix here is; the same port (8333) is still exposed on the Tor network, but that traffic will be sent a Tor specific port (8334) that bitcoind has open (this allows bitcoind to distguinish between clearnet and Tor peer connections). It's therefore expected that port 8334 is not accessible over Tor as 8333 is open and remains the same as before.

[UAJHSG]

Require all TOR connection running to continue. Exiting orbot