• Securely Exposing Your LND Node Using Tor, Socat, and a VPS
  • Introduction & Motivation
• Architecture Overview
• Why This Architecture?
  • Key Properties
  • Summary
• Implementation Overview
  • Components
    • 1. Tor Container
    • 2. Socat Container
    • 3. Autoheal
• Deployment Guide
  • 1. Start the Containers
  • 2. Check Runtime Status
  • 3. Check Container Health
  • 4. Configure Firewall
• Configuration Options
  • Environment Variables for socat
  • Changing the External Port
• Testing
  • From an external host
  • From another LND node
  • From inside the containers
• LND Configuration
• Health Checks & Autoheal
  • Tor Health Check
  • Socat Health Check
  • Autoheal Behavior
• Advantages of the Tor-Based Architecture
  • ✔ Fully Open-Source
  • ✔ Strong Privacy Guarantees
  • ✔ Resilient to Cloudflare and CDN Outages
  • ✔ Outbound-Only Connectivity
  • ✔ Minimal Attack Surface
• Disadvantages Compared to Cloudflare Tunnel
  • ❌ No Integrated Access Control
  • ❌ Higher Latency
  • ❌ More Operational Complexity
  • ❌ VPS Sees Connection Metadata
• Final Evaluation
• References

§Securely Exposing Your LND Node Using Tor, Socat, and a VPS

A Cloudflare-Free Clearnet Proxy Architecture

§Introduction & Motivation

Running a Lightning Network Daemon (LND) node with a publicly reachable TCP address is essential for channel opens, forwarding payments, and maintaining strong network connectivity. Many node operators expose LND through tunneling services such as Cloudflare Tunnel.

However, reliance on a proprietary centralized service introduces a structural single point of failure. The recent global Cloudflare outage demonstrated that even the most robust commercial infrastructures can go dark—taking dependent LND nodes offline.

To eliminate this dependency, this article presents a fully open, privacy-preserving alternative using:

• A minimal VPS exposing a public TCP listener
• Tor as an anonymizing transport
• socat to forward clearnet connections through Tor into your LND onion service
• Health checks + autoheal to keep the tunnel alive

This design preserves all the security benefits of outbound-only connectivity while removing Cloudflare from the trust chain.

Original Cloudflare-based article:
https://habla.news/a/naddr1qvzqqqr4gupzq0l6cwnvsk0242xdmkevwqp2dcgtx0h7hyksykc5att03gkk2ejhqqxnzde58yun2wpjxyerwd33tr0ph4

§Architecture Overview

Clearnet → VPS:9735 → socat → Tor SOCKS Proxy → Onion:9735 → LND Node

The system uses three containers:

• tor – Runs Tor and exposes a SOCKS5 proxy
• socat – Listens on clearnet and forwards streams to the onion service
• autoheal – Restarts containers when health checks fail

Result: a public TCP endpoint with zero exposure of your LND node’s real IP.

§Why This Architecture?

§Key Properties

§Summary

• Tor-based: privacy, independence, censorship-resistance
• Cloudflare-based: convenience, integrated access control, centralized trust

The Tor solution sacrifices some convenience in exchange for decentralization and resilience.

§Implementation Overview

§Components

§1. Tor Container

• Boots Tor
• Provides SOCKS5 on port 9050
• Considered healthy after bootstrap reaches 100%

§2. Socat Container

• Waits for Tor readiness
• Listens on clearnet port (default: 9735)
• Forwards streams through the Tor SOCKS proxy

§3. Autoheal

• Monitors health status
• Restarts unhealthy containers automatically
• Ensures continuous operation

§Deployment Guide

§1. Start the Containers

cd /path/to/tor-tunnel-lnd
docker compose build
docker compose up -d

§2. Check Runtime Status

docker compose ps
docker logs -f lnd-tor
docker logs -f lnd-socat
docker logs -f lnd-autoheal

§3. Check Container Health

docker inspect --format='{{.State.Health.Status}}' lnd-tor
docker inspect --format='{{.State.Health.Status}}' lnd-socat

§4. Configure Firewall

sudo ufw allow 9735/tcp
sudo ufw reload

§Configuration Options

§Environment Variables for socat

§Changing the External Port

ports:
  - "19735:9735"

§Testing

§From an external host

nc -v <VPS_IP> 9735

§From another LND node

lncli connect <pubkey>@<VPS_IP>:9735

§From inside the containers

docker exec lnd-socat nc -z tor 9050
docker exec lnd-socat netstat -tlnp | grep 9735

§LND Configuration

Advertise both the clearnet and onion endpoints:

externalip=<VPS_IP>:9735
externalip=b3pje4vztlrbilix7wp6fisyrdflbrx232v75xl4eyx4hjn2756avkyd.onion:9735

Restart LND and check:

lncli getinfo

Expected:

• 03abc...@<VPS_IP>:9735
• 03abc...@b3pje4vztlr...onion:9735

§Health Checks & Autoheal

§Tor Health Check

Verifies:

• Tor bootstrap completion
• Tor exit IP is recognized as a Tor exit
• SOCKS proxy remains reachable

Interval: 30s
Timeout: 30s
Start period: 60s

§Socat Health Check

Verifies:

1. Socat is listening
2. Forwarding works end-to-end
3. LND responds with a Lightning handshake

This ensures the tunnel isn’t just running but fully functional.

§Autoheal Behavior

• Monitors container health
• Restarts unhealthy containers
• Logs all restart actions

§Advantages of the Tor-Based Architecture

§✔ Fully Open-Source

No central provider; no API tokens; no dashboards.

§✔ Strong Privacy Guarantees

The VPS cannot identify your LND node or its network location.

§✔ Resilient to Cloudflare and CDN Outages

No reliance on commercial infrastructure.

§✔ Outbound-Only Connectivity

The LND node exposes zero inbound ports.

§✔ Minimal Attack Surface

Only the VPS port is exposed; LND remains unreachable.

§Disadvantages Compared to Cloudflare Tunnel

§❌ No Integrated Access Control

Cloudflare’s Service Tokens provide elegant authorization.
Tor + socat relies on LND’s inherent authentication, which is strong but not policy-based.

§❌ Higher Latency

Tor paths increase latency slightly, although this is irrelevant for Lightning gossip and peer maintenance.

§❌ More Operational Complexity

Requires Docker, health checks, and Tor maintenance.
Cloudflare’s solution is plug-and-play.

§❌ VPS Sees Connection Metadata

It cannot identify your LND, but it sees:

• number of incoming connections
• timing patterns
• clearnet origin IPs

Mitigations require additional layers if desired.

§Final Evaluation

Both the Cloudflare and the Tor-based approaches achieve the same goal: providing a stable clearnet endpoint for your Lightning node without exposing the node itself to the internet.

The Cloudflare solution favors convenience, centralized control, and access management.
The Tor solution favors privacy, sovereignty, decentralization, and resilience to third-party outages.

For operators who value independence and censorship resistance, the Tor + socat architecture is a strong upgrade, fully eliminating proprietary dependencies while maintaining robust Lightning connectivity.

§References

1. Original Cloudflare-based article (Habla.news):
   https://habla.news/a/naddr1qvzqqqr4gupzq0l6cwnvsk0242xdmkevwqp2dcgtx0h7hyksykc5att03gkk2ejhqqxnzde58yun2wpjxyerwd33tr0ph4

2. Tor Project – Tor Documentation
   https://community.torproject.org/

3. Socat manual (Linux man pages)
   https://linux.die.net/man/1/socat

4. Lightning Network Specification
   https://github.com/lightning/bolts

5. LND Documentation
   https://docs.lightning.engineering/

6. Autoheal Docker Project
   https://github.com/willfarrell/docker-autoheal