VPNaaS Simplified on Fujitsu K5

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 subnet in the UK region and the 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.

Happy Tunneling!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s