Why is Stunnel still incredibly useful despite VPNs or SSH Tunnels?
SysAdmins are no strangers to the struggle of maintaining “vintage” applications like older versions of Redis, Memcached, or Python/Go scripts running plain TCP sockets. These services often transmit data in clear-text. If a hacker is on the same network performing sniffing, all your sensitive information will be exposed.
After six months of operating Stunnel for an internal data distribution system, I’ve found it to be the most “lightweight” solution. Instead of setting up a bulky VPN system that consumes 20-30% of processing resources, Stunnel acts as a lean SSL Proxy. It wraps the TCP connection into a solid TLS tunnel. Your original application requires zero code changes because all encryption and decryption happen transparently at the lower layer.
Installing Stunnel on Linux
Installing Stunnel is extremely fast; almost every distro has it available in its official repositories.
On Ubuntu/Debian
sudo apt update
sudo apt install stunnel4 -yOn CentOS/RHEL/AlmaLinux
sudo yum install stunnel -yA small note for Debian/Ubuntu users: You must edit the /etc/default/stunnel4 file. Change ENABLED=0 to ENABLED=1; otherwise, the service won’t start automatically with the system.
Quickly Creating a Certificate
Stunnel requires a Private Key and Certificate pair to function. If you’re only using it for internal server-to-server communication, a self-signed certificate is the fastest option.
Here is how to quickly generate a certificate valid for 365 days:
openssl genrsa -out key.pem 2048
openssl req -new -x509 -key key.pem -out cert.pem -days 365
cat key.pem cert.pem > /etc/stunnel/stunnel.pem
chmod 600 /etc/stunnel/stunnel.pemDon’t forget the chmod 600 command. The stunnel.pem file contains the private key, so only the root user or the user running the service should be allowed to read it.
Configuring Stunnel for Server and Client
Imagine you have a Backend service running on port 9000 (unencrypted) and you want clients to connect securely via port 9443.
1. Server-side Setup (Receiver)
Open /etc/stunnel/stunnel.conf and paste the following content:
pid = /var/run/stunnel4.pid
cert = /etc/stunnel/stunnel.pem
sslVersion = TLSv1.2
foreground = no
[my-secure-service]
accept = 9443
connect = 127.0.0.1:9000In this configuration, accept is the “front door” port receiving encrypted connections, while connect is the internal port where the legacy service is listening.
2. Client-side Setup (Sender)
On the client side, Stunnel performs the opposite task: it receives plain data from the local application and wraps it to be sent over SSL. The configuration is as follows:
client = yes
pid = /var/run/stunnel4.pid
[my-secure-service-client]
accept = 127.0.0.1:8000
connect = EXTERNAL_SERVER_IP:9443Now, your application only needs to point to localhost:8000. Stunnel will handle the rest.
To limit IP access to Stunnel via a firewall, I often use toolcraft.app/en/tools/developer/ip-subnet-calculator. This tool helps calculate CIDR and IP ranges very quickly, avoiding errors when you need to whitelist specific internal subnets accurately.
Testing and Monitoring Operations
Activate the new configuration with the command:
sudo systemctl restart stunnel4To ensure the port is open, use the ss command. It’s faster and provides more detailed information than netstat on servers with thousands of connections:
ss -tlnp | grep stunnelPractical experience shows that you should add debug = 7 to the config file when first deploying. Logs will be written in detail to /var/log/syslog, helping you immediately detect any SSL handshake errors. In particular, set alerts for when certificates are about to expire to avoid sudden service disconnections.
Hard-earned Lessons for Production
By default, Stunnel only handles encryption, not user authentication. For maximum security, you should use Client Certificate Authentication. In this case, only clients with valid certificates can connect to the system.
Regarding performance, Stunnel handles encryption tasks very well. However, if the system faces tens of thousands of connections per second (high concurrency), CPU usage will spike due to the continuous SSL handshake process. In that scenario, an SSL Termination solution on HAProxy would be more professional.
Finally, regarding the Firewall: only open the accept port for trusted IPs and strictly lock down the connect port (the original service) to prevent hackers from bypassing your security layer.
Stunnel is the best “quick-and-effective” choice for modernizing legacy systems without touching the code. If you encounter any difficulties during configuration, feel free to leave a comment!
