Skip to Content

Creating a VPC with VPN access for running virtual appliances on AWS – the easy way

Do you want to deploy and run a virtual appliance like the ABAP on HANA developer edition on AWS in a secure way? One recommended option is using a virtual private cloud (VPC) with openVPN server for VPN access in a public subnet and running the SAP system in a private subnet (as depicted in the drawing below).


Instead of creating all these AWS resources manually as described in my previous document, you can use AWS CloudFormation to create the whole stack automatically using a CloudFormation script. The attached CloudFormation script/template makes it a lot easier to setup a secure VPC stack with VPN access for your trial or developer edition.


Remark: There are other options to set up a VPC with VPN access on AWS. This approach should serve as proposal for modest testing and evaluation purposes and the template can be modified to your needs. Moreover, the ID of the openVPN access server AMI changes frequently. Thus, if the creation of the openVPN server instance fails, please check in the AWS Marketplace whether the AMI ID in the CF template is still valid or has to be updated.




There two prerequisites to successfully use this CloudFormation script (besides a valid AWS account):

a) You need a valid EC2 key pair, which you can use to connect to your VPN server instance using SSH:

To create a dedicated key pair, navigate to the EC2 dashboard > Network & Security > Key Pairs and hit the Create Key Pair button. Download the .pem file containing your private key.

b) You have to subscribe to the openVPN access server on the AWS Marketplace (for free), in order to accept the terms and conditions of this AMI:

Navigate to the AWS Marketplace and search for the openVPN access server. Select the current release, click on Manual Launch and hit the Accept Terms button. Now you are allowed to create an openVPN server instance programmatically.

c) Download the corresponding AWS CloudFormation template from GitHub (hit the Download Gist button).


Generate your VPC stack


Now it’s time to automatically build your VPC with VPN server using AWS CloudFormation:

1. In the AWS console navigate to the CloudFormation service and ensure that you selected the desired region (e.g. US East for the AS ABAP on SAP HANA developer edition).

2. Hit the Create New Stack button and select the vpc_openvpn.json script as template using the Browse button.

3. Enter the desired template parameters, i.e. an existing EC2 key pair and (optionally) a CIDR block (IP filter) for limiting admin access to your openVPN server instance:


4. Hit the Create button and wait until your entire VPC stack has been created:


Remark: You can also delete your whole VPC stack (all AWS resources) automatically if you don’t need it anymore by selecting your CloudFormation template in the AWS console and hitting the Delete Stack button.


After the automatic creation of your VPC stack you’ll find the admin URL and the access URL of your openVPN server in the Outputs tab of the CloudFormation service:


Deploy your virtual appliance and connect to your VPC


As I already described the remaining steps (configuring the openVPN server, deploying the virtual appliance, connecting to your VPC) in my previous document, please proceed with these steps described in Section 3. I hope the option described above (using AWS CloudFormation) makes it easier and more convenient for you to build and define your own VPC stack for deploying virtual appliances in the cloud.


Final remark: Please keep in mind, that your openVPN server instance will not be managed by SAP CAL (start, stop, terminate) together with your CAL instances. Directly use the AWS EC2 dashboard to start and stop your openVPN server.

You must be Logged on to comment or reply to a post.
  • Hi Christopher,

    great post, thanks so much for this helpful information.

    I wanted to bring to your attention that the OpenVPN AS AMIs referred to by vpc_openvpn.json use OpenVPN AS version 2.0.10, which is vunerable to Shellshock. Using this version represents a security risk.

    Assuming you’re the author of this GitHub Gist, you may wish to update the OpenVPN AS AMI IDs to those of version 2.0.10* which was released yesterday (2014-10-02). You can find the AMI IDs here (select the tab “Manual Launch”). Also note the Release Note mentioned at this link (“Patched for Shellshock”).

    Best regards,


    • Hi Lambert,

      thanks a lot for the hint! I already did several updates due to Shellshock, but didn’t think of my Gist snippet yet. I updated all openVPN AMI IDs with the patched versions.

      Best regards,


  • Hello Christopher,

    Thanks for taking the time to do this.

    I had to refresh my system and (foolishly?) decided to delete my painstakingly created VPC, to give this script a go. Well I’ve run the whole setup three times and haven’t gotten it to work, I cannot ping the NetWeaver system from my OpenVPN ssh console.

    Looks like something about the subnets and routing tables isn’t right. Not being a TCP/IP internals Guru, it will take me some time to get it fixed, but the first thing I noticed is that the OpenVPN server’s eth0 is on 10.0.0.nn with netmask is, which doesn’t match the SAP system’s 10.0.35.nn or 10.0.1.nn (depending on what network I chose during the NetWeaver instance creation).

    I also don’t know what the “SAP CAL Default Network” Network choice in the instance creation does. It creates yet another 10.0… network which seems to really confuse matters as neither choice works.



    • Hello Mike,

      not sure what might be wrong with your setup, but the following is correct: The OpenVPN server should run in the public subnet ( in order to be accessible from the outside. The NetWeaver system should run in the private subnet (, so it can only be accessed from outside via VPN connection. So please ensure that you create your CAL instance within the private subnet of your VPC. Maybe you also have to update the AMI ID of the OpenVPN server in my script, in order to get the latest version (as I didn’t test it for a while). Hope this helps.

      Best regards,


      • Hi Christopher,

        Thanks for gettting back to me, that is exactly my setup. I found the AMI ID was different, so I updated it. The OpenVPN server has an address 10.0.0.nn and NW has an address 10.0.1.nn, so it’s all deploying correctly.

        I’m a little further though… in my previous setup I could reach the NW server from SSH into the OpenVPN system. Now I can’t, but I can SSH into it when the VPN session is established.

        I think there are two issues here. One is that the NetWeaver instance creation wants to create a new network by default:

        Default network.png

        This doesn’t work at all. I need to override SAP CAL to point to the 10.0.1.n subnet, I think the blog should be updated to point this out:

        Correct network.png

        Then I discovered another issue that it seems to still want to use the Amazon-default VPC on a 172.31.n.n subnet.

        $ route -n get

           route to:




          interface: utun0

        Note this is all from a complete clean install using the script.

        When I updated OpenVPN to assign 10.0.0.n to incoming connections, it worked better:

        $ route -n get

           route to:




          interface: utun0

        Now for another oddity:

        I am using a mac. If I opened the VPN connection under a Windows VM, I could SSH to the NetWeaver system and eventually managed to log in. If I open the same VPN connection from my mac, it also connects, but SapGui won’t. Initially I got a complete failure until I did the update above, now I can definitively connect, but SapGui gives me “Connection Refused”. This worked fine under my previous VPC, so no local problems that I know of….

        Thanks & regards,


        (by the way, let me know if you’d rather continue this as a forum post…)

        • OK, quick update that I got it all to work.

          To summarize:

          One issue seems to be in the way that Amazon creates a default VPC for all new accounts. Apparently you’re not supposed to delete that (I did in my earlier manual setup), and only they can recreate it – for a charge. This by default uses 172… IP addresses. OpenVPN needed an adjustment to use the 10.0.0.n range by default.

          The other issue seems to be with the default CAL network that the instance creation wants to create. I note too that the screenshots differ to what is displayed today, so probably this CloudFormation script works according to how the CAL used to create instances.

          Anyhow, got there in the end, hopefully this may help someone…