The FreeBSD Diary
Providing practical examples since 1998If you buy from Amazon USA, please support us by using this link.
stunnel - encryption and security 10 March 2002
I'm about to enter into a business relationship with a west coast hosting company. They actually gave me the box just over two months ago, but various things have prevented us from completing the deal. For the most part, the delay has been because of other commitments and project planning. It's only a matter of timing now. I will still retain a box at iStop, but my primary websites will be moved to this new server (which is fast. VERY fast!).
I want to create a tunnel from this box to my home LAN. I will use stunnel to do that. It was November when the first article on stunnel appeared on this website. For more information on stunnel, please refer to Stunnel -- Universal SSL Wrapper. This tunnel will use SSL, which is a secure encrypted method for communicating between two sites. I will be using this tunnel for my cvsup'ing my website from my cvsup server at home. But the example should provide sufficient detail for your particular situation. If this article does not supply enough information, I urge you to read the examples on the stunnel website.
NOTE: If you upgrade from v3 to v4, the the stunnel invocation has changed! The program no longer accepts command-line options, but is controlled by a config file instead. Please refer to the stunnel(8) manual page for more information. See Upgrading to stunnel 4 for more information.
Creating the server tunnel
I started with the first stunnel article. That allowed me to install stunnel and get it running.
The latest port of stunnel will create an SSL certificate for you. This will be sufficient for most people.
The port installs the certificate to
As mentioned previously, you will be asked to create a certificate. I just followed the prompts, and a certificate was created. Easy.
Here is the command for starting the server side of the tunnel:
The options are:
The client tunnel
I followed the same instructions on the client as for the server. The client tunnel is created this way:
These client options are:
Testing the tunnel
Here's what I did on the client:
Here is what I found on the server:
The first entry is stunnel starting up. The second command is the incoming connection.
/etc/hosts.allow is your friend
In addition to a firewall, I also make use of
/etc/hosts.allow. It allows
you to restrict connections to daemons/services which are started from
If you see this message on the client, I bet you have a host.allow issue:
This pretty much means you need to add an entry to your hosts.allow in order to permit your remote client to attach. My intial thoughts were "I need to add an entry for cvs". I was wrong. Read Examples of TCP wrapper service names for stunnel for details.But your first clue is in
/var/log/message. Look for this:
The clue is in bold. It is
In this case, the entry for
where 192.168.0.91.example.org is your client machine.
Selecting the service name
Of note is the
which will produce:
In this case, the name of the server is mycvsserver, which can be used in /etc/hosts.allow instead of localhost:5999.
I actually haven't used the tunnel for anything more than what you see above.
Using it for the intended purpose
The original intention of this tunnel was to allow me to use a remote cvs server but at the same time, ensure the
traffic was secure and encrypted. For the cvsup, you would specify localhost as the host
That should get you going.
Other things to consider
In all of these examples, you've seen the server stunnel running as root. That does not have to be.
In fact, it is probably a good idea to not run it as root. See the
You should also notice that the client tunel I opened was not run as root. If you leave the tunnel around for a while, you should use another user. Perhaps one dedicated to the task of tunnelling.