Core Lightning with Tor AND IPv4 clearnet

Tor can be very slow, and eventually Start9 will support clearnet options. But until it does, here’s how to get your Core Lightning to accept direct IPv4 connections.

Step 1: Expose your Core Lightning to local LAN

Credit to remcoros for the code.([DIY] Exposing electrs and bitcoind over LAN in StartOS 0.3)

Login to StartOS over SSH and switch to the root user:

sudo -i

Run the following command to switch to the “chrooted” environment, any system changes made now will be persisted across reboots.


Paste the following, this will install ‘socat’ and a new systemd service responsible for port forwarding 9735 for c-lightning

apt install socat -y

cat > /lib/systemd/system/socat.c-lightning.service <<'EOL'
Description=socat c-lighting forward

ExecStartPre=/bin/bash -c "/bin/systemctl set-environment IP=$(ip route | grep default | awk '{print $9}')"
ExecStart=/usr/bin/socat tcp-l:9735,fork,reuseaddr,su=nobody,bind=${IP} tcp:c-lightning.embassy:9735


systemctl enable socat.c-lightning

Now exit the chroot environment. Note: this will reboot StartOS!


After lightning-cli starts, your node will be accessible directly via IP on your local network.

Step 2: Expose your node to WAN/Internet

Next step is to expose it to the web. The following is an example, and will make you NO LONGER ANONYMOUS. Use a VPN if you wish to remain anonymous.

Look up your StartOS IPv4 address. You’ll find it under System > About. For example

Log into your router and follow your router’s instructions to set up port forwarding, setting incoming connection on port 9735 to point to your StartOS IP (eg.

Now other nodes can connect directly to your node without needing to use Tor. But only if they know how (you tell them your IP yourself).

Step 3: Add announce settings to let other nodes find you

Login to StartOS over SSH

Edit your C Lightning config file

sudo nano /embassy-data/package-data/volumes/c-lightning/data/main/config.main

Add the following line to your configuration, replacing the IP with whatever IP number your node is reachable through. This is either your WAN IP if you exposed it on your router in Step 2, or your VPN IP number if you set that up


Don’t forget the port at the end.

CTRL-X and Y to exit and save. Restart Core Lightning, and now your node should be broadcasting both Tor and IPv4 connections. To check, log into your c-lightning instance

sudo podman exec -ti c-lightning.embassy bash

then run the following command (once your Core Lightning is fully up and running)

lightning-cli getinfo

You should see “type”: “torv3”, “address”: and your Tor address that you had previously, but now you should also see another entry “type”: “ipv4”,“address”: and your new IP address.

After a while you should also see this reflected in online node explorers like amboss and mempool. Though some (amboss) take a long time to update.

1 Like

Since you’re editing config.main already anyway, you can also add the following

autoclean-cycle=3600  # Perform clean once an hour (60sec x 60min)
autoclean-failedforwards-age=86400   # Clean all failed forwards older than a day (60sec x 60min x 24hours)
autoclean-failedpays-age=86400  # Clean all failed payments older than a day (60sec x 60min x 24hours)
autoclean-expiredinvoices-age=86400  # Clean all expired invoices older than a day (60sec x 60min x 24hours)

After a while, especially on a node with a lot of channels, your database will end up with hundreds of thousands of these waste transactions slowing things down. This will help keep things tidy.

Just FYI for anyone looking to do this: it is generally not a great setup – Any time you restart the CLN service, or change anything in its config, or the server reboots, all those manual changes to CLN’s config are going to be wiped out. Additionally, any time the server’s lan IP changes, or your home internet’s public IP changes, the port forward job will become ineffective.

You’re better off making a PR to change CLN or at least an feature request Issue to add some of these config options to the interface.

When combined with the changes coming in StartOS v0.3.6 (and eventually v0.4.0), they could go a long way toward making what you’re trying to do a stable reality.

I don’t know if this works the same for others, but interestingly the config changes persist for me even after rebooting the node.
Regarding IP changes, I wonder if it’s possible to just use ddns service and announce that domain instead of an IP instead?

I spoke with the cln-startos package maintainer and he said in this case, actually changes will be saved across service stops and restarts, but if you change the config via the web-UI, your custom changes will be wiped out, so just beware you’ll have to readd the settings to the config.main again if you change the config in the web-UI.

Also seems that any updates to apps in Start9 will wipe the initial setup here.
After upgrading Bitcoin to version 26, socat and all its services were gone. I had to rerun the initial part of these instructions, logging into chroot-and-upgrade, creating the service, and systemctl enabling it again. Upon reboot, the lightning config.main retained the new settings already, and socat worked again.

It might be worth automating the service creation into:


That file should always be preserved, and is run after every boot if it exists.

Can I run this same script but for LND?

Pretty much, but you’d have to adapt it. For example c-lightning.embassy would be lnd.embassy, you’d change the name of the socat service etc etc

1 Like