Issue with plugin when using always-use-proxy=true and a local tower

[21M4TW]

Hi,

So I have teosd running locally in case lightningd crashes or something goes really wrong with its lightning DB. I have always-use-proxy set to true because I want all peers connections to go through Tor. However when always-use-proxy is set to true, the watchtower-plugin tries connecting through Tor to reach teosd which is running on localhost, so the connection fails. What would make sense here to make it work? Should there be a list of IPs that could be whitelisted to be reacheable directly, should there be a specific exception for 127.0.0.1? Should this be implemented within the watchtower-plugin or within CLN? Thanks!

[sr-gi]

Hi @21M4TW,

there're a couple of things to have in mind here:

• First, running a tower locally in the same machine that your Lightning node is running is an anti-pattern. You're gaining little, if anything, by doing so, given that if there is any issue that causes downtime to your node that is also likely to affect your tower. The only exception would be the node software crashing due to a bug instead of a power/internet outage.
• Second, teosd is set to honor the always-use-proxy from CLN, which means that if the flag is set, all HTTP traffic should be routed through Tor.

I guess we could make a single exception for localhost, even if this is not the intended use case.

[21M4TW]

Yes I understand your point about not providing protection if there is a power/internet outage. I would not rely solely on a local tower for sure. Maybe it could make sense for the plugin to honor always-use-proxy as it currently does, by using an additional watchtower-always-use-proxy parameter whose value defaults to always-use-proxy's value, but that could be set differently if needed? The issue I have when I set always-use-proxy to false (or undefined), is that my node tries to reach its pears through clearnet even if I connect to them using an onion address (the onion address gets replaced by IPv4 when I connect the peer, I don't know why). Maybe the issue I have has more to do with the fact that CLN favors clearnet when a peer can be reached either through Tor or clearnet and always-use-proxy is not set to true?

[sr-gi]

Given this is a pretty minimal change, I've created a hotfix for it you can easily try:

https://github.com/sr-gi/rust-teos/tree/cln-proxy-localhost

I'll wait to reach consensus on whether this is a usecase we'd like to support, but you can go ahead and try it out if this is given you a hard time.

This mainly just creates an exception for localhost so it bypassed the proxy.

[21M4TW]

Given this is a pretty minimal change, I've created a hotfix for it you can easily try:

https://github.com/sr-gi/rust-teos/tree/cln-proxy-localhost

I'll wait to reach consensus on whether this is a usecase we'd like to support, but you can go ahead and try it out if this is given you a hard time.

This mainly just creates an exception for localhost so it bypassed the proxy.

Hi,

I tested it, but it does not seem to work unfortunately. I regenerated both the plugin and teosd, and I restarted both teosd and lightningd.

I tried:
lightning-cli registertower [tower_id]@127.0.0.1:9814

and it says:
"Cannot connect to the tower. Connection refused"

If I set always-use-proxy it is able to register it...

Thanks!

[sr-gi]

Sorry, I should have tested that, there was an issue with he localhost parsing. It should work now.

[21M4TW]

Sorry, I should have tested that, there was an issue with he localhost parsing. It should work now.

Thank you. It seems to be working so far. I have not seen any error in the log at least.

[mariocynicys]

Maybe it could make sense for the plugin to honor always-use-proxy as it currently does, by using an additional watchtower-always-use-proxy parameter whose value defaults to always-use-proxy's value.

We had something like this before honoring CLN's own always-use-proxy, but it makes sense that if the users want to keep their IPs anonymous from peers then they would want the same with towers.

I guess we could make a single exception for localhost, even if this is not the intended use case.

Local IP addresses aren't always this loop back one (localhost/127.0.0.1), sometimes it's a local network device or the same device but using the local network provided IP.

I think we can have the users provide a list of non-proxyable addresses in the config file, those which we won't ever use Tor with.

[sr-gi]

I think we can have the users provide a list of non-proxyable addresses in the config file, those which we won't ever use Tor with.

That could work

[21M4TW]

Yes I agree it would be the most flexible solution :)

[jfrader]

Is there any solution to this?

[mariocynicys]

@jfrader I guess this #219 (comment) is a sought after solution right now, but there is no PR for it yet.

Would be nice if someone could take it from there (maybe start with an incomplete PR and I can provide help as needed).

[aruokhai]

@mariocynicys i could take a look at this .