pull down to refresh

A few things worth trying come to mind:
  • Whenever you update items like tlsextradomain in the lnd.conf file, you need to regenerate the tls.cert so it has the latest values included. Restarting LND should do the trick (I believe there also might be an LND command for this)
  • You might additionally need to publish the full host and domain in Docker along the lines of -p <external-ip>:10009:10009 to expose it externally
  • Have you tried using the onion address instead? That should be reachable from anywhere.
Hope this helps. Docker networking is never fun, I've been there. Good luck!
Whenever you update items like tlsextradomain in the lnd.conf file, you need to regenerate the tls.cert so it has the latest values included
I think this is the answer. Just restarting won't do the trick though. You need to delete the original tls.cert file before starting it back up again.
I suspect that the networking bit is not the problem. OP mentioned that they can telnet port 10009 from external networks. That means the port is successfully forwarded, it's the app that's not working.
reply
I think this is the answer.
unfortunately, this is not the answer. every time i made changes i deleted both tls files and restarted lnd. my tls certs are always up to date.
OP mentioned that they can telnet port 10009 from external networks.
on that note: while i do get a response when i telnet <public-ip>:10009 can i assume that this is actually reaching my lnd? Is A response the RIGHT response or is there a RIGHT response apart from A response or NO response?
reply
A telnet response is always better than a timeout. That means something is responding. But since you say you already did delete the tls.cert beforehand, I'm wondering what else can be wrong.
If you decode the contents of the tls.cert file using https://www.sslchecker.com/certdecoder for instance, do you see all your IPs and domains?
Another way to check if you can connect is, use Zap Wallet to connect to your node. Zap uses the gRPC interface to connect. It might even give you useful error messages if initially you run into trouble connecting.
reply
no i do not see any of my IPs or domains that is provided, interesting.
however i know that the cert was just regenerated because the issuance date got updated (the last one was yesterday). are the entries form tlsextraip and tlsextradomain supposed to be listed in the decoded dataset somewhere?
reply
Yes your extra IPs and domains you provided in tlsextraip and tlsextradomain config entries should appear in the 'SAN' subject in the certificate. If they are not there, your app will not be able to perform the necessary SSL handshake.
You need to investigate why they are not getting picked up by lnd.
I don't use Umbrel so I do not know if they have hidden config files somewhere that overrides your manual lnd.conf entires. Maybe you can check with them Umbrel folks.
reply
dude, thank you. you helped a lot. i've asked a question on umbrel about this because it actually looks like they ignore the lnd.conf entries when generating the cert. waiting for the reply...
btw. i ended up using voltage.cloud and it works like a charm!
reply
I did some digging, it looks like it is a known issue with Umbrel after upgrade 0.5.0.
reply
How the fuck did i miss this... Well, another argument for using voltage. Imagine being reliant on this for a production app and your certificates becoming void after a restart or update.
Glad to hear it!
reply