Lnd: unable to restlisten IPv6 address when tor=active

Created on 26 Jan 2019  路  13Comments  路  Source: lightningnetwork/lnd

Background

When tor.active=1, unable to restlisten to any IPv6 address

Your environment

  • version of lnd 0.5.1
  • which operating system (uname -a on *Nix)
    Debian based

  • version of btcd, bitcoind, or other backend
    bitcoind 0.17.x

  • any other relevant environment details

Steps to reproduce

Create lnd.conf with the following contents:

[Application Options]
restlisten=[::]:8080

[Bitcoin]
bitcoin.active=1
bitcoin.mainnet=1
bitcoin.node=bitcoind

[Bitcoind]
bitcoind.zmqpubrawblock=tcp://127.0.0.1:8301
bitcoind.zmqpubrawtx=tcp://127.0.0.1:8302

[Autopilot]
autopilot.active=0

[tor]
tor.active=1
tor.socks=127.0.0.1:9050

Tell us how to reproduce this issue. Please provide stacktraces and links to code in question.

Run lnd with above lnd.conf.

Expected behaviour

Should listen on [::]:8080 for REST connections and operate normally (ask for wallet passphrase etc).
If it's not going to support listening on REST port while Tor is active, that should be printed in the error message along with explanation and links to documentation.

Actual behaviour

lnd aborts immediately printing only:

tor general error

Which is unexpected when the only thing added when going from a working configuration, to a non-working, is to add a restlisten line.

If you comment out either the tor.active line OR the restlisten line, it works as expected, but both together cause this error.

with tor.active=1,
restlisten=[::1]:8080 - fails
restlisten=127.0.0.1:8080 - works
restlisten=0.0.0.0:8080 - works
restlisten=x.y.z.w:8080 (where x.y.z.w is an IP on the machine) - works
restlisten=[a:b:c:d:e:f:0:1]:8080 - where a:b:c:d:e:f:0:1 is an IPv6 address on the machine - fails

One clue is,
restlisten=hostname:8080 - fails with a different error
tor host is unreachable

So my GUESS is it's trying to use Tor to resolve a DNS entry for the host, which is incorrect, it should not resolve DNS for literal IPv6 addresses, whether Tor or not.

P3 REST bug tor v0.12

Most helpful comment

This checks whether rawHost is IPv6 and then uses the tcpresolver. Starts up fine, onion connectivity tested as working
https://github.com/lightningnetwork/lnd/compare/master...EagleTM:fix-issue-2541

I don't feel comfortable doing a pull request mostly as it adds a function that might be useful more globally or might already be covered without me seeing it. More of a PoC and quick fix for for anyone who wants to bind v6 but also serve / reach Tor

All 13 comments

same issue for rpclisten=

to clarify it seems to be a bug in parsing that anything not an IPv4 literal is looked up in DNS, and if tor is active, DNS lookups are sent into Tor, so again, I am guessing that even with Tor disabled it's treating ipv6 literals as hostnames and trying to resolve them in DNS - possibly leaking information about local IPv6 addresses to the DNS server. (It's just that in the non-Tor case, lnd continues starting up successfully)

Same tor general error behavior when using listen=[IPv6 address] and externalip=[IPv6 address] along with tor.active=1

I've observed this same error with tor.active and externalip set to an ipv6 address. The error goes away if I disable tor or remove the ipv6 externalip.

I'm having issues with ipv4+ipv6+tor. A node seems limited to one of

  • ipv4+tor
  • ipv4+ipv6 and no tor

I can create a new issue, however solving this one probably solves mine too.

Yes it's because "::" or "::1" is not checked here (https://github.com/lightningnetwork/lnd/blob/f28b8097783570054645e4f7b32dae7a028aa518/lncfg/address.go#L180) so the tor resolver (lower) is used

Experiencing same problem when trying to publish externalip on IPv6 with tor enabled.

@weebl2000 that's likely to https://github.com/btcsuite/btcd/issues/1227.

@Crypt-iQ keep for 0.11?

oops, tabbed the wrong number of times lol

Same issue here.

Yes it's because "::" or "::1" is not checked here (

https://github.com/lightningnetwork/lnd/blob/f28b8097783570054645e4f7b32dae7a028aa518/lncfg/address.go#L180

) so the tor resolver (lower) is used

Some generic matching for raw IPv6 addresses would be nice, so anything with ":" in it should not be resolved at all or at least go to the v4 resolver I think?

This checks whether rawHost is IPv6 and then uses the tcpresolver. Starts up fine, onion connectivity tested as working
https://github.com/lightningnetwork/lnd/compare/master...EagleTM:fix-issue-2541

I don't feel comfortable doing a pull request mostly as it adds a function that might be useful more globally or might already be covered without me seeing it. More of a PoC and quick fix for for anyone who wants to bind v6 but also serve / reach Tor

is there any version where this is fixed?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stevenroose picture stevenroose  路  3Comments

hxsquid picture hxsquid  路  3Comments

MrManPew picture MrManPew  路  3Comments

Roasbeef picture Roasbeef  路  3Comments

anaoum picture anaoum  路  4Comments