Changes

Line 115: Line 115:  
         </pre>
 
         </pre>
 
     </li>
 
     </li>
 +
----
 
     <li>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:
 
     <li>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:
 
         <pre>ps | grep stunnel | grep -v grep</pre>The output should look similar to this:
 
         <pre>ps | grep stunnel | grep -v grep</pre>The output should look similar to this:
Line 124: Line 125:  
         <pre>13034 root      3428 S    /usr/sbin/openvpn --syslog openvpn(7365727665725F41)</pre>
 
         <pre>13034 root      3428 S    /usr/sbin/openvpn --syslog openvpn(7365727665725F41)</pre>
 
     </li>
 
     </li>
     <li></li>
+
----
 +
     <li>To restart OpenVPN or Stunnel services, use one of these commands:
 +
      <pre>/etc/init.d/openvpn restart</pre>
 +
      <pre>/etc/init.d/stunnel restart</pre>
 +
    </li>
 +
----
 +
    <li>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.</li>
 
</ul>
 
</ul>
<!--
  −
  −
  −
  −
* ''''
  −
  −
* ''''
  −
  −
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:
  −
  −
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).
  −
-->
  −
<!--
  −
==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'''.
+
[[Category:RUT955 WebUI]]
-->