Often on our Cloud surgery calls I’ll have requests on how to go about configuring Virtual Private Networks (IPSec VPNs) between the various public clouds and customer sites.
The purpose of this blog is to demonstrate the process of establishing such a secure tunnel using the VPNaaS feature available on Fujitsu’s Cloud Service K5.
The biggest key to success here is preparation – most issues are encountered when the customer’s VPN configuration and K5’s VPN configurations are not programmed with the same prerequisites. In order to try and simplify this process for you, here at CNETS we’ve put together a simple VPNaaS template that can be downloaded by clicking on the image below and shared with the customer. Please ensure that this is document is understood, agreed, and completed before trying to build your service – sounds sensible I hope – you’d be surprised at how often people skip this step.
Another prerequisite on your cloud environment is that you have already created the virtual network, subnet, router and added a Global IP (public ip address) to the virtual router.
Once you’ve completed these prerequisites it’s time to start building your VPN.
OpenStack IPSec VPNaaS Tool
Again CNETS come to the rescue, unless you enjoy manually building all the necessary API calls, we’ve built an Angular based User Interface to simplify all the necessary API calls to build and configure your VPNaaS. The tool is located here – https://cnets-vpnaas.uk-1.cf-app.net/ and needs a valid Fujitsu Cloud Service K5 administrative contract account to login.
I’ve also created the following diagram to illustrate what will be configured in a soon to be published video … as soon as I can get my OBS recording software to start playing nicely again. I will join two subnets across two K5 regions – one subnet is located in our US region and the other subnet is in our UK region. The exact same process is used if configuring K5’s VPNaaS when connecting to VPNaaS offerings in other public/private clouds or customer VPN appliances.
Note: One fundamental concept that needs to be understood is that you are linking one layer 3 subnet to another layer 3 subnet only. What I mean by this is that in the following example I’ll add the 192.168.10.0/24 subnet in the UK region and the 192.168.0.0/24 subnet in the US region to the IPSec VPN (these subnet CIDRS should not be over-lapping). Once the VPN tunnel is established and the correct security groups applied Server A will be able to communicate with Server C and vice-versa. However, Server B and Server D will NOT be able to communicate. An additional proxy service would be needed on each of the VPN peer subnets to facilitate routing traffic from Server B and Server D through the VPN tunnel.
As it’s near Christmas and we’re full of festive spirit here in CNETS this week (at least I am), I’ve got one final treat – for those of you who like to follow along – below I’ve also included the two heat templates that I’ve used for the demo to build the infrastructure in the diagram above. Don’t forget to change the input parameters and DNS setting to match your target AZ if using them on Fujitsu’s Cloud Service K5. These templates should also work with other OpenStack clouds.
Heat Template Project A
Heat Template Project B
Video demo to follow shortly.