How to: Configure a new VNS3 Controller from a Snapshot

How to: Configure a new VNS3 Controller from a Snapshot

What is a Snapshot?

You can save your VNS3 Controllers configuration with the VNS3 Runtime Snapshot feature.

Use Snapshots to reconfigure a new Controller with the same SSL Certificates and Keyset with just one file upload. In the event of a Controller failure or re-provisioning event, you can upload the snapshot file to a new VNS3 Controller. The new Controller will retain all the configuration settings as your saved snapshot.

You can view all snapshots under Maintenance > Snapshots. Remember to also download snapshots to your local network.

Always have a VNS3 configuration snapshot on hand! In case something goes wrong with your underlying VM host, you will be able to quickly get back up to speed. Best practices are to always have a current VNS3 snapshot for all running instances. For a detailed step-by-step guide for taking a snapshot of your VNS3 configuration and uploading it to a newer 3.5+ version, see our Support guide here.

How to use a Snapshot to configure a Controller

If you haven’t already, log in to your VNS3 UI via a browser: https://<Controller IP>:8000.

If you’ve never configured this VNS3, you will see the Initialization page. 

Click the Upload Snapshot link on the left.

VNS3 import snapshot

Browse for your saved Snapshot and upload. The Controller will reboot with the updated configuration. The same Clientpacks will be available in the Controller, so redistribution to each server on the virtual network is not necessary.

A slight configuration change on each server on the virtual network is necessary if you have not assigned Elastic IPs to your Controller. The OpenVPN configuration file (vnscubed.<conf ovpn>) on each server needs the new IP of the new Controller referenced in the remote commands section.

To automate this step, you can assign an Elastic IP to the Controller and reference the Elastic IP in each server’s OpenVPN configuration file. Likewise in Azure, their version is simply called a Static IP. That way your overlay network devices will automatically connect back with the Controllers and will save you time on both Controller and client configuration.

What’s Next

Remember that after you initialize you must generate keys to create your VNS3 clientpacks and set up Controller peering to finish configurations

NOTE : all VNS3 editions must complete the peering step, even for single Controller topologies.

Watch the video

If you have trouble with the video player below, watch the video on YouTube: https://youtu.be/pjQUoIIgsW8

Bring-your-own SSL Certs with VNS3

Bring-your-own SSL Certs with VNS3

One of the (few) issues some customers have with VNS3 is the use of self-signed certificates. There are arguments to be made that self-signed certs can be as secure than those provided by third-party trusted signing certificate authorities (CAs), when implemented properly. But these arguments are often more hassle than many IT departments want, especially as most browsers have increased their scary warnings, and when an end user sees those the last thing they want is a debate on the relative security of CAs versus their own local infrastructure.

As of version 4.0 of VNS3 it is possible to upload your own SSL certs. These can be self-signed certs or those provided by a CA.

In this post we’re going to show how to create and upload a signed certificate to VNS3 by using EFF’s Certbot and certificates generated by Let’s Encrypt. Certbot is a part of EFF’s efforts to encrypt the entire Internet. It acts as a client to the Let’s Encrypt open CA, which is a service provided by the Internet Security Research Group (ISRG).

Our approach will be to create the certificates separate from the instance, then upload them using VNS3’s UI.

Creating and Installing Your Let’s Encrypt Certificates

The rest of this tutorial assumes the following:

  • You have ownership of a specific domain, example.com
  • You are naming your VNS3 instance vns3.example.com
  • You have access to the DNS records for example.com

Given the above requirements, you can run the Certbot process on a separate server and have the certs generated, ready to be uploaded to VNS3.

The approach is:

  • Add vns3.example.com as an A or CNAME record to your DNS records for example.com
  • If it’s not already installed, install Certbot on your separate server ( https://certbot.eff.org/docs/install.html ). It’s even possible to use Docker ( https://certbot.eff.org/docs/install.html#running-with-docker ).
  • Run the Certbot client (if this is the first time you’ve run the client you will be asked for an email address for renewal/security notices and you will be asked to agree to the Terms of Service.) :

Running Certbot looks similar to the following:

$ sudo certbot certonly –manual –preferred-challenges dns

Please enter in your domain name(s) (comma and/or space separated) (Enter ‘c’ to cancel): vns3.example.com

Yuo’ll step through the certbot prompts to create your certificates. At this point you will have to wait for your DNS records to push the TXT record out. This should be fairly quick. To see if your TXT record has appeared you can use the “dig” command (in a separate tab/window), which should return the contents of the TXT record. For example:

$ dig txt _acme-challenge.vns3.example.com

For VNS3 we need the following files:

/etc/letsencrypt/live/vns3.example.com/privkey.pem

/etc/letsencrypt/live/vns3.example.com/cert.pem

To update via the UI, connect to your instance and navigate to the “HTTPS Certs” option in the Admin section of the menu.

The file, cert.pem , is your SSL certificate, and privkey.pem is your SSL key file. Upon clicking the “Upload and Install” button you will receive the message, “HTTPS certs validated and installed”. (If you receive “Error validating key/cert files” it’s possible the order of the files was reversed, with the private key as the cert and vice versa). Once installed the system will restart the web server and your new certificates should be protecting your VNS3 instance.

Automating Certificate Renewal

An SSL certificate from Let’s Encrypt CA expires in 3 months. This is actually a very good thing as it means that in the event of another Heartbleed-type bug, the maximum amount of time that the weakened certs will remain active is 90 days. The problem is that it means that someone will need to rerun Certbot and update the certs on the VNS3 instances every 90 days. A better way is to automate the process.

A detailed analysis of the certificate renewal process is beyond this post. Instead we’ll just touch on some details. Certbot supports a way of running non-interactively but a plugin is required when combining with manual use. It is also possible to run semi-interactively, like so:

$ sudo bash -c “yes | certbot certonly –manual –cert-name vns3.example.com ”

To automate the uploading of the new certs to the VNS3 instance requires use of the API. Here is an example of some basic, hastily written Ruby code that can be used to upload and install the certs:

require ‘rest_client’
require ‘json’

@user = ‘api’
@password = ‘vnscubed’

base_path = ‘ https://vns3.example.com:8000/api/system/ssl ’
cert = File.read(‘cert.pem’)
key = File.read(‘cert.key’)
def put(url, payload = {})
rc = RestClient::Resource.new(url, user: @user, password: @password, verify_ssl: OpenSSL::SSL::VERIFY_NONE)
JSON.parse(rc.put(payload.to_json, content_type: ‘application/json’))
end
def get(url)
rc = RestClient::Resource.new(url, user: @user, password: @password, verify_ssl: OpenSSL::SSL::VERIFY_NONE)
JSON.parse(rc.get(content_type: ‘application/json’))
end
begin
response = put(“#{base_path}/keypair”, { cert: cert, key: key })
response = put(“#{base_path}/install”)
uuid = response[‘response’][‘uuid’]response = get(“#{base_path}/install/#{uuid}”)
while response[‘response’][‘state’] == ‘pending’
puts “Job #{uuid} : status #{response[‘response’][‘status’]}”
sleep 3
response = get(“#{base_path}/install/#{uuid}”)
end
puts “Job #{uuid} : status #{response[‘response’][‘status’]}”
rescue => e
puts “Error: #{e.message}”
end

The above Ruby code should not be used in production. It doesn’t test well for errors, it has global variables, it loops in an unchecked way and it’s not verifying the existing SSL certs. But on the positive side, it does demonstrate how easy it can be to upload newly generated certs to a VNS3 instance.

Taking the two separate steps and wrapping them in a script is trivial and having either a Jenkins task or a cron job run the process every month or two should be easy to ensure that the certificates on your VNS3 instances are up-to-date.

Conclusion

In this post we’ve shown you how to create and upload an SSL certificate for your VNS3 instance using Let’s Encrypt and Certbot. We’ve also given a quick overview on how to begin to automate the certificate update process. Hopefully another item on the ever-lengthening IT security to-do list can now be checked off.