|
|
(5 intermediate revisions by the same user not shown) |
Line 1: |
Line 1: |
| =Introduction=
| | {{Template: Networking_device_configuration_examples_openvpn_over_stunnel |
| | | | name = RUT955 |
| '''Stunnel''' is an open-source multi-platform software application used to provide a TLS/SSL tunneling service for already existing clients and servers.
| | | file_topology = Networking_device_vpn_stunnel_working_scheme_v4.png |
| | | | file_server_scheme = Networking_device_vpn_stunnel_server_working_scheme_v2.png |
| 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#Stunnel|VPN manual page]]'''.
| | | file_openvpn_server = Networking_rutxxx_configuration_examples_openvpn_over_stunnel_openvpn_server_configuration_v1.png |
| | | | file_stunnel_globals = Networking_rutxxx_configuration_examples_openvpn_over_stunnel_stunnel_globals_configuration_v1.png |
| =Stunnel configuration specifics=
| | | file_stunnel_server = Networking_rutxxx_configuration_examples_openvpn_over_stunnel_stunnel_server_configuration_v1.png |
| | | | file_client_scheme = Networking_device_vpn_stunnel_complete_configuration_scheme_v2.png |
| 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:
| | | file_stunnel_client = Networking_rutxxx_configuration_examples_openvpn_over_stunnel_stunnel_client_configuration_v1.png |
| | | | file_openvpn_client = Networking_rutxxx_configuration_examples_openvpn_over_stunnel_openvpn_client_configuration_v1.png |
| * '''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 '''[[How to generate TLS certificates (Windows)?|Windows]]''' and '''[[How to generate TLS certificates (Linux)?|Linux]]''' 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 '''[[https://en.wikipedia.org/wiki/Deep_packet_inspection|Deep 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:
| |
| | |
| | |
| [[Image:draw_io_openvpn_stunnel.png]]
| |
| | |
| | |
| ==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:
| |
| | |
| | |
| [[Image:draw_io_example_visual.png]]
| |
| | |
| | |
| ==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:
| |
| | |
| [[Image:demo_openvpn_server_config.png]]
| |
| | |
| Stunnel server configuration looks like this:
| |
| | |
| [[Image:demo_stunnel_server_config.png]]
| |
| | |
| 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''':
| |
| | |
| [[Image:demo_stunnel_server_global_enabled.png]]
| |
| | |
| 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 [[Stunnel configuration examples#Configuration mistakes|end of this page]].
| |
| | |
| '''IMPORTANT NOTES:'''
| |
| | |
| So far the server is configured this way:
| |
| | |
| | |
| [[Image:draw_io_server_config_image.png]]
| |
| | |
| | |
| * 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:
| |
| | |
| | |
| [[Image:demo_firewall_stunnel.png]]
| |
| | |
| | |
| '''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:
| |
| | |
| | |
| [[Image:demo_stunnel_client_config.png]]
| |
| | |
| | |
| OpenVPN client configuration looks like this:
| |
| | |
| | |
| [[Image:demo_openvpn_client_config.png]]
| |
| | |
| | |
| 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''':
| |
| | |
| | |
| [[Image:demo_stunnel_client_global_enabled.png]]
| |
| | |
| | |
| 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 [[Stunnel configuration examples#Configuration mistakes|end of this page]].
| |
| | |
| '''IMPORTANT NOTES:'''
| |
| | |
| Now the whole connection looks like this:
| |
| | |
| [[Image:draw_io_connection_config_image.png]]
| |
| | |
| * 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'''.
| |
| | |
| | |
| [[Image:demo_client_test_connection.png]]
| |
| | |
| | |
| 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:
| |
| | |
| | |
| [[Image:demo_client_add_cert_pk.png]]
| |
| | |
| | |
| ===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:
| |
| | |
| | |
| [[Image:demo_server_add_ca.png]]
| |
| | |
| | |
| Now, test the connection from the client router:
| |
| | |
| | |
| [[Image:demo_client_test_verify_chain.png]]
| |
| | |
| | |
| 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:
| |
| | |
| | |
| [[Image:demo_server_add_peer.png]]
| |
| | |
| | |
| Now, test the connection from the client router:
| |
| | |
| | |
| [[Image:demo_client_test_verify_peer.png]]
| |
| | |
| | |
| 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:
| |
| | |
| | |
| [[Image:demo_client_add_ca.png]]
| |
| | |
| | |
| Ping test:
| |
| | |
| | |
| [[Image:demo_client_test_server_ca.png]]
| |
| | |
| | |
| * Client configuration with peer verification:
| |
| | |
| | |
| [[Image:demo_client_add_peer.png]]
| |
| | |
| | |
| Ping test:
| |
| | |
| | |
| [[Image:demo_client_test_server_peer.png]]
| |
| | |
| | |
| =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).
| |
Introduction
Stunnel is an open-source a proxy service that adds TLS encryption to clients and servers already existing on a VPN network. 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 Deep packet inspection (DPI) check.
This article contains instructions on how to configure an OpenVPN over Stunnel topology.
Overview
You will need
- two routers of the RUTxxx series (except RUT850);
- at least one router (server) with a public IP;
- TLS certificates for the server and the client (for instructions on generating TLS certificates, click here).
Topology
Explanation
An OpenVPN client is connected to an OpenVPN server (both hosted on RUT routers) via a TLS encrypted Stunnel connection. This provides the possibility to transfer data between remote private networks (LAN A and LAN B) and adds an additional TLS security layer for the connection.
Server configuration
First, configure the OpenVPN and Stunnel servers. The Stunnel server will listen for incoming client connections on the specified TCP port (9999 in this example) and connect them to OpenVPN server running on the local host.
The logic of the connection can be visualized like this:
OpenVPN server
Navigate to the Services → VPN → OpenVPN page. Select Role: Server, enter a custom name and click the 'Add New' button. An OpenVPN server instance with the given name will appear in the "OpenVPN Configuration" list. To begin configuration, click the 'Edit' button next to the server instance.
The figure below displays the configuration used for our example. Take note of the comments that are provided next to fields that differ from the default value:
Don't forget to click the Save button located at the bottom-right side of the page.
Stunnel server
Navigate to the Services → VPN → Stunnel page and enable the "Stunnel Globals" configuration:
Click Save.
To create a new Stunnel instance, enter a custom name for it and click the 'Add' button. A new instance with the given name will appear in the "Stunnel Configuration" list. To begin configuration, click the 'Edit' button next to the instance.
The figure below displays the configuration used for our example. Take note of the comments that are provided next to fields that differ from the default value:
Don't forget to click the Save button located at the bottom-right side of the page.
Open Stunnel port
The OpenVPN default port (1194) is opened by default. But you will have manually open the select Stunnel port (9999 in this example).
To do this, navigate to the Network → Firewall → Traffic Rules page and scroll down until you see the Open Ports On Router section. Fill out the configuration fields as indicated in the figure above and click the 'Add' button:
Client configuration
Configure the OpenVPN and Stunnel clients that will be connecting to the server. Unlike in the server, there is reason to configure Stunnel client before the OpenVPN client (the other way around will also work but an OpenVPN service restart may be required) so it is recommended to start with that.
The OpenVPN client will connect to TCP port 1194 of the local host and the Stunnel client will connect to the WAN IP and Stunnel port (192.168.10.1:9999 in this example) of the server router.
The logic of the entire connection can be visualized like this:
Stunnel client
Navigate to the Services → VPN → Stunnel page and enable the "Stunnel Globals" configuration:
Click Save.
To create a new Stunnel instance, enter a custom name for it and click the 'Add' button. A new instance with the given name will appear in the "Stunnel Configuration" list. To begin configuration, click the 'Edit' button next to the instance.
The figure below displays the configuration used for our example. Take note of the comments that are provided next to fields that differ from the default value:
Don't forget to click the Save button located at the bottom-right side of the page.
OpenVPN client
Navigate to the Services → VPN → OpenVPN page. Select Role: Server, enter a custom name and click the 'Add New' button. An OpenVPN client instance with the given name will appear in the "OpenVPN Configuration" list. To begin configuration, click the 'Edit' button next to the client instance.
The figure below displays the configuration used for our example. Take note of the comments that are provided next to fields that differ from the default value:
Don't forget to click the Save button located at the bottom-right side of the page.
Testing and troubleshooting
If you have completed the steps presented above, your configuration is complete. This section provides tips on how to test and troubleshoot this OpenVPN over Stunnel connection.
- Check whether remote side is reachable by sending ICMP requests. To do that, go to the Services → CLI page. Login (username: root; password: router's password) and ping the opposite instance:
ping 10.8.0.6
Is the response looks like this, then the connection was established successfully:
64 bytes from 10.8.0.6: seq=0 ttl=64 time=101.214 ms
64 bytes from 10.8.0.6: seq=1 ttl=64 time=91.018 ms
64 bytes from 10.8.0.6: seq=2 ttl=64 time=88.974 ms
64 bytes from 10.8.0.6: seq=3 ttl=64 time=502.781 ms
- If there is no response to the ping requests, check whether Stunnel and OpenVPN services are running on the device. For Stunnel use this command:
ps | grep stunnel | grep -v grep
The output should look similar to this:
16122 root 2992 S /usr/bin/stunnel /tmp/stunnel.conf
For OpenVPN use this command:
ps | grep openvpn | grep -v grep
The output should look similar to this:
13034 root 3428 S /usr/sbin/openvpn --syslog openvpn(7365727665725F41)
- To restart OpenVPN or Stunnel services, use one of these commands:
/etc/init.d/openvpn restart
/etc/init.d/stunnel restart
- Double check your configuration. Check for configuration mistakes, see if correct certificate files are uploaded onto each instance, make sure the Stunnel port is not used by another program, etc.