Stunnel configuration examples

Introduction

Stunnel is an open-source multi-platform software application used to provide a TLS/SSL tunneling service for already existing clients and servers.

This article contains Stunnel configuration examples that require more in-depth explanations. All examples involve 2 or more RUT routers. For a bedrock Stunnel WebUI explanation please visit VPN manual page.

Stunnel configuration specifics

To establish an Stunnel connection, there have to be a client and a server instances set up and configured properly. Fields required for bare minimum configurations are:

• Stunnel Client
  • Listen Port
  • Connect IP's

• Stunnel Server
  • Listen Port
  • Connect IP's
  • Certificate File
  • Private Key if it is not appended to the Certificate File!

Examples in this page cover the server-side set up of the Stunnel service, which requires knowledge about TLS certificates and keys. This example, however, will not cover the TLS certificate and key generation process. For detailed instructions on how to generate TLS certificates and keys please refer to our articles for Windows users.

If you are not setting up a Stunnel server yourself and instead use a third-party Stunnel service, the provider should either provide you the certificate and key, or might not require them at all.

OpenVPN over Stunnel

TLS encryption provided by Stunnel can be used as an additional layer of encryption for data sent by OpenVPN. This procedure increases the security of the established connection and provides higher chances of passing a [Packet Inspection (DPI)] check without being detected.

For the following example we will be providing the configurations used for OpenVPN client and server. However, you are expected to set them up yourself. For more information on OpenVPN configuration please refer to our article OpenVPN configuration examples.

You can imagine the visual representation of OpenVPN over Stunnel configuration for 2 routers with local networks to look similar to this:

Router information

We will be using 2 RUTxxx routers connected to the same Wide Area Network (WAN). One router will be used as the server, other one - as the client.

In this example, WAN IP addresses for the routers are:

• Server WAN IP address: 192.168.10.32

• Client WAN IP address: 192.168.10.33

Although it does not matter for Stunnel, for OpenVPN configurations it is usually better (more reliable) to configure and enable the server first. That is why we will start with the server configuration.

This specific router configuration can be imagined to be like this:

Basic server setup

On the router used as a server we have to set up OpenVPN and Stunnel server instances.

OpenVPN server configuration looks like this:

Stunnel server configuration looks like this:

After saving the Stunnel server configuration, do not forget to mark the global "Enabled" flag. To save the changed global settings you will need to click Save:

To check if both OpenVPN and Stunnel services started properly, go to the CLI section, login to the router and launch these two commands one after the other:

• ps | grep stunnel | grep -v grep

• ps | grep openvpn | grep -v grep

If one of them does not return a result, there might be a mistake in the configurations or you forgot to enable the configured instances. More information on the probable causes can be found at the end of this page.

IMPORTANT NOTES:

So far the server is configured this way:

• Take notice that the selected OpenVPN connection protocol is TCP, not UDP! This is necessary, because TLS encryption (which is what Stunnel provides) only works over the TCP protocol.
• Since OpenVPN server will receive packets from the localhost, you don't have to open a firewall for the OpenVPN server port.
• However, Stunnel server will be receiving packets from the client over the internet (WAN), so you must open a firewall for the Stunnel server port. Otherwise, the client will not be able to connect to the server through the designated port.

Firewall rule creation can be found at the Network → Firewall section, Traffic Rules tab.

The firewall rule creation for Stunnel server port looks like this:

Make sure that the firewall rule is enabled! To do that, click the Edit button next to the rule and then click Save.

Basic client setup

On the router used as a client we have to set up OpenVPN and Stunnel client instances.

IMPORTANT: Unlike in the server configuration, when configuring the client, the order in which you enable the Stunnel and OpenVPN instances matters! You should always configure/enable the Stunnel instance first, and OpenVPN second. If you enable the OpenVPN client first, you will most likely have to restart/re-enable the OpenVPN instance after enabling Stunnel.

Stunnel client configuration looks like this:

OpenVPN client configuration looks like this:

After saving the Stunnel client configuration, do not forget to mark the global "Enabled" flag. To save the changed global settings you will need to click Save:

To check if both OpenVPN and Stunnel services started properly, go to the CLI section, login to the router and launch these two commands one after the other:

• ps | grep stunnel | grep -v grep

• ps | grep openvpn | grep -v grep

If one of them does not return a result, there might be a mistake in the configurations or you forgot to enable the configured instances. More information on the probable causes can be found at the end of this page.

IMPORTANT NOTES:

Now the whole connection looks like this:

• Take notice that just like in the server case, the selected OpenVPN connection protocol is TCP, not UDP! This is necessary, because TLS encryption (which is what Stunnel provides) only works over the TCP protocol.
• Client side of the Stunnel does not require you to open a firewall port for it.

Testing the connection

Connection can be tested from either server or client. We will check it from the client side by trying to ping the OpenVPN server over the CLI (Services → CLI). In this case, the OpenVPN Server address is 10.8.0.1.

As you can see, the connection is set up properly - the ping works.

Adding peer (chain) verification

When setting up a connection, you might want to have a way to authenticate clients connecting to the server. This is done in a similar fashion to OpenVPN authentication - using TLS certificates and private keys. Then, every Stunnel client, connecting to the server, will have to have a valid certificate and private key combination assigned to it.

For verification addition examples we will be using the configuration we set up above.

Adding client certificate and private key

To add certificate and private key for the client, you can simply edit the existing configuration and upload the required files:

Server-side verification

There are two ways you can authenticate incomming connections: using a CA file to verify any certificate of the connection or using a list of certificates for each approved connection concatenated into a single file.

Chain verification

This type of verification uses the CA certificate file which was used to sign the certificates of all incoming connections. To verify the certificates against this CA file, we have to upload it and update our server configuration:

Now, test the connection from the client router:

You can ping the server - client certificate was verified against the CA file and allowed to connect. Verification works!

Peer verification

Instead of using a CA certificate file, you can use the client certificates directly, by concatenating all the approved certificates into a single file. To verify the certificates against this certificate list file, we have to upload it and update our server configuration:

Now, test the connection from the client router:

You can ping the server - client certificate was verified against the certificate list and allowed to connect. Verification works!

Client-side verification

You can use the same verification functionality to verify the server you are connecting to as a client. It works the same way the server configuration does - you can use either the CA file used to sign server's certificate (Verify Chain), or use the server certificate itself (Verify Peer).

Demonstrations of it working:

• Client configuration with chain verification:

Ping test:

• Client configuration with peer verification:

Ping test:

Configuration mistakes

Improperly configured Stunnel instances will silently stop the Stunnel service and none of the Stunnel configurations will work, even though their "Enabled" flags might be marked. To check if the Stunnel service is working, connect to the router through CLI (Services → CLI) and enter the line:

ps | grep stunnel | grep -v grep

Stunnel service is stopped if this line returns no result.

Possible causes of bad configuration:

• "Listen Port" is already taken by a different service;
• "Listen IP" is unreachable (usually - if it's not a localhost);
• Incorrect file uploaded into one of the file fields (Verification file, Certificate file, Private Key);
• Sometimes certificates and private keys might not be accepted (even if they are properly signed and are currently valid) due to desynchronization of the router's clock. If you have problems with certificates, first try to sync current system time with your browser at section System → Setup Wizard → Step 1 - General (you don't need to go through all the sections/steps).