Incoming connections/Port forwarding: is bind=<IP> needed, and why?

[Carlton Banks]

Trying to get incoming connections over tor, and it's a mixed success.

I have a static hs for the node (and so I have -listenonion=0), and I got just 1 incoming connection that actually used the NETWORK service (also BLOOM and WITNESS, all other nodes were crawling nodes without any services). That was a stable long lasting connection, so maybe it's working...

But there are alot of debug messages like

Code:

Socks5() connect to <ip:port> failed: connection refused

...so it seems that there could be something in the config that's preventing the majority of peers connecting to the node.

Also, trying to use bind=<proxy IP> gives this fatal startup error:

Code:

Unable to bind to <proxy IP>:18333 on this computer (bind returned error Cannot assign requested address (99))

What is error 99?

Or, should I simply be expecting low numbers of incoming connections over tor?

[1714130813]

1714130813

[1714130813]

1714130813

[1714130813]

1714130813

[1714130813]

1714130813

[Foxpup]

I have a static hs for the node (and so I have -listenonion=0), and I got just 1 incoming connection that actually used the NETWORK service (also BLOOM and WITNESS, all other nodes were crawling nodes without any services). That was a stable long lasting connection, so maybe it's working...

Yes, if you get any incoming connections at all over Tor, it is working. You can verify that it's over Tor because the peer will appear to have the IP address of your Tor proxy server, with a random port. You can also telnet port 8333 of your hidden service (using torsocks) to verify that it is reachable.

But there are alot of debug messages like

Code:

Socks5() connect to <ip:port> failed: connection refused

...so it seems that there could be something in the config that's preventing the majority of peers connecting to the node.

I get that too. It doesn't seem to indicate a problem. Random connection failures seem normal for Tor.

Also, trying to use bind=<proxy IP> gives this fatal startup error:

Code:

Unable to bind to <proxy IP>:18333 on this computer (bind returned error Cannot assign requested address (99))

What is error 99?

It means you don't own that IP address. You're supposed to bind to one (or more) of your own addresses, specifically the one specified in the HiddenServicePort entry in torrc. Note that this is only necessary if you need to avoid receiving incoming connections on your other addresses (in particular your public IP address, if you have one, which would compromise your anonymity).

Or, should I simply be expecting low numbers of incoming connections over tor?

I usually have at least 10 or so, but it seems to be normal for a new hidden service to not see many connections at first.

[Carlton Banks]

You can verify that it's over Tor because the peer will appear to have the IP address of your Tor proxy server, with a random port.

Right, I intended to include a question about that, namely:

If the IP of the incoming connection is that of my tor proxy, will misbehaving peers still be banned effectively? It seems to me that without knowing the originating IP, they can attack my node by getting my proxy's IP banned instead of their own.

Also, trying to use bind=<proxy IP> gives this fatal startup error:

Code:

Unable to bind to <proxy IP>:18333 on this computer (bind returned error Cannot assign requested address (99))

What is error 99?

It means you don't own that IP address. You're supposed to bind to one (or more) of your own addresses, specifically the one specified in the HiddenServicePort entry in torrc. Note that this is only necessary if you need to avoid receiving incoming connections on your other addresses (in particular your public IP address, if you have one, which would compromise your anonymity).

Right, so 127.0.0.1 is the IP for the bind setting?

Or, should I simply be expecting low numbers of incoming connections over tor?

I usually have at least 10 or so, but it seems to be normal for a new hidden service to not see many connections at first.

Ah, that's good to hear, in a way. So just need to wait a little.

When you say "at least 10", do you mean 10 incoming connection, or in total?

[Foxpup]

If the IP of the incoming connection is that of my tor proxy, will misbehaving peers still be banned effectively? It seems to me that without knowing the originating IP, they can attack my node by getting my proxy's IP banned instead of their own.

No, you can expect to see a lot of "Warning: not banning local peer" in your debug.log as well.

Right, so 127.0.0.1 is the IP for the bind setting?

Yes, unless you specified a different local address in torrc. (Assuming you're running Tor and Bitcoin on the same machine, of course. Though if you are, I'm not sure where your previous error came from.)

When you say "at least 10", do you mean 10 incoming connection, or in total?

10 incoming connections, in addition to the usual 8 outgoing connections.

[Carlton Banks]

Thanks for the help.

Do we know why a static hidden service is needed? It would be so much better if port forwarding worked using a dynamic hidden service addresses (i.e. with listenonion=1), for both ease of use and anonymity reasons. A fundamental limitation of Tor hidden services?

[Foxpup]

Do we know why a static hidden service is needed?

It's not needed, but it's often desirable to have nodes with a static .onion address, eg as fallback nodes.

It would be so much better if port forwarding worked using a dynamic hidden service addresses (i.e. with listenonion=1), for both ease of use and anonymity reasons. A fundamental limitation of Tor hidden services?

Huh? It's not supposed to work. By default, public IP discovery is disabled when using Tor, for anonymity, so forwarding port 8333 is useless (doubly so if you bind to 127.0.0.1 instead of the address you forwarded the port to). If you want to be able to receive incoming connections over both Tor and clearnet (anonymity be damned), additional configuration is required. I'm not sure what you're trying to accomplish.

[Carlton Banks]

I'm sorry, I'm not being clear.

Do we know why a static hidden service is needed?

It's not needed, but it's often desirable to have nodes with a static .onion address, eg as fallback nodes.

So, what I mean is: why is it needed to use a static hs address in order to accept incoming connections over tor? If the bitcoin client can create a new hidden service dynamically every startup, surely it's possible for the tor client to forward the dynamically created address to the tor network in the same way as it does for a static address, along with the port number it's using? It seems like it's just a limitation of the way hidden services function, but is that something that could be added to the hidden service design in future, or is it inherently impossible?

It would be so much better if port forwarding worked using a dynamic hidden service addresses (i.e. with listenonion=1), for both ease of use and anonymity reasons. A fundamental limitation of Tor hidden services?

Huh? It's not supposed to work. By default, public IP discovery is disabled when using Tor, for anonymity, so forwarding port 8333 is useless (doubly so if you bind to 127.0.0.1 instead of the address you forwarded the port to). If you want to be able to receive incoming connections over both Tor and clearnet (anonymity be damned), additional configuration is required. I'm not sure what you're trying to accomplish.

As above, I can't see a reason why the tor client cannot be designed to function in a way that helps p2p software accept incoming connections and have the anonymity of using throwaway hs urls. I appreciate that this cannot be done with tor and bitcoin right now, but is there a more general reason why that will never be possible? An inherent problem with tor seems like the most likely reason (I don't know alot about how tor works)

[Foxpup]

So, what I mean is: why is it needed to use a static hs address in order to accept incoming connections over tor?

It isn't. Ephemeral hidden services created via listenonion work exactly the same as static hidden services, and you can receive incoming connections through them (they'd be entirely useless if you couldn't, since they serve no other purpose). If you can't get listenonion to work, I would suggest checking the logs (both Bitcoin's and Tor's) for relevant errors.

I fail to see what any of this has to do with port forwarding, which is entirely irrelevant to running a hidden service.

[Carlton Banks]

ahhhhh, well that explains it.

I assumed (incorrectly) that listenonion=1 was intended to only make outgoing connections (which is how I experience that parameter on my setup). So incoming connections should work using listenonion/ephemeral hs addresses.

[Foxpup]

For reference, making outgoing connections over Tor (including to other hidden services) only requires that you set the address and port of your Tor server as your proxy in Bitcoin's network options (or, equivalently, the proxy option in bitcoin.conf). It does not require that you run a hidden service of your own and no further configuration is required.

[Carlton Banks]

Ephemeral hidden services created via listenonion work exactly the same as static hidden services, and you can receive incoming connections through them (they'd be entirely useless if you couldn't, since they serve no other purpose). If you can't get listenonion to work, I would suggest checking the logs (both Bitcoin's and Tor's) for relevant errors.

So this has proven helpful, I previously assumed listenonion/ephemeral hs was working without really checking it was! Currently looking into why not... some success so far.