Hi Charles,

I do not have any personal experience regarding this setup.

I have however found some documentation for you that might be helpful. For any other additional information, you could always ask OutSystems Support for help.

https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/Set_Up_a_VPN_to_your_OutSystems_Cloud

https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/AWS_Direct_Connect_on_OutSystems_Cloud

Regards,

Nordin

Hi Nordin

That is helpful for a generic VPN setup.  But I was hoping for something more specific.

Since the Outsystems PaaS is operating on the AWS cloud and our external databases are also on AWS, in addition our engineering desktops all VPN into our AWS VPC, I was hoping to be able to connect our existing VPC into the Outsystems PaaS over a VPN.

If not, I will try and document our solution and share it as it seems an obvious use case...

Hi Daniël 

I have reached out to Outsystems support (two tickets on this topic), they do not seem capable of offering anything other than the published material Nordin linked to earlier.

Which is disappointing as I am sure this is a popular use case.

Thanks for jumping in Daniël! I can ask a colleague of mine too.

Thanks Guys!  that is very helpful.

Hi Charles,

I got a reaction from the AWS specialist at the customer:

"It is indeed possible to keep traffic within AWS.
We are busy (Well, waiting for OS again) to connect the OS VPC to our Transit Gateway. That has not yet been officially supported, but they cannot do otherwise with us. This allows you to keep traffic within AWS.
Unfortunately, OS does not support VPC Endpoint (also called private link) otherwise it would have been an alternative to some DB flavors." 

Regards,

Daniel

Hi Daniël

That is really helpful.  Thank you.  

AWS Transit Gateway is the obvious solution... if it were supported by OS.

Would be interesting to hear of any other experiences with OS PaaS VPN to 'local' AWS VPC.

Well it appears I was wrong in assuming lots of people have done this and wrong to assume I could use an AWS asset of some sort to terminate a AWS VPN.

Here is what I have found so far, if anyone is interested:

AWS support say:

Ideally if you had a on-premise network with physical appliance you need to make your firewall configured in such a way that it forms a IPSEC tunnel with the supplier’s [Outsystem's] account, but here you do not have the on-premise with physical device in place. However, you have a AWS VPC which needs to be connected via VPN to another AWS account VPC.

So to make this possible you have following options:

>> You can create a VPN connection to your remote network by launching an Amazon EC2 instance and then deploy a third party Software appliance such as Openswan or StrongSwan.  For more details on High-Level HA Architecture for Software VPN Instances please refer link [1].

***Note : Please make sure to use the EIP you supplied for the instance because that is what is used as CGW device IP on supplier's side***

Going on, I found this article which have step by step configuration of Openswan in an EC2 instance :

https://red1ns.com/using-openswan-for-site-to-site-vpn-on-aws/

I am now looking at using this CloudFormation stack as a starting point:

https://github.com/aws-samples/vpn-gateway-strongwswan

Using AWS Transit Gateway would be a quick and secure solution which it would remove much of the overhead in achieving what should be a simple requirement.

Hi Charles,

Yes, OpenSwan is a valid option. We used it successfully ourselves at OutSystems to connect VPCs. I am not sure if we still use it, because the project I was involved with has since evolved to dismiss this requirement.

We are working to support AWS Transit Gateway, i.e. allow customers to attach the OutSystems VPC to their own Transit Gateway. Stay tuned!

For the purpose of completeness, you have yet another alternative to VPN available today with the OutSystems Cloud: an AWS Direct Connect link. I'm not sure if it applies to your use case, though.

Best,

Joao

Hi Joao

Thanks for the update, I understand Transit Gateway is on trial, can I be added as a trial user?

Do you have a configuration guide for the OpenSwan setup?

Unfortunately, Direct Connect link is really not a suitable option as it is designed to connect on premise to AWS rather than between AWS VPCs.

Hi Charles,

I am not aware of the details of the trial, please discuss with Support.

Unfortunately, I don't have any configuration guide for the OpenSwan setup.

But there isn't anything specific to OutSystems, afaik. Once you have the connectivity between the VPC where you have OpenSwan and your previous VPC on AWS running, I expect you to just proceed with the setup of a VPN connection as if it were a regular onprem VPN device. 

https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/Set_Up_a_VPN_to_your_OutSystems_Cloud

Well it has taken a month - I hope moderators don't tell me off for opening an old thread ;-) .

Thanks are due to Outsystems support for their help.  However, others do not need to experience my errors, so here is a description of my solution.  The first point to note, is that product documentation in the public realm on VPNs is very poor and makes assumptions of the reader's knowledge - it is not helped by the use of inconsistent terminology.

My requirement was for a VPN from Outsystems PaaS to an 'On Premise' VPC in our own AWS account, something like this.

First-up, VPN site-to-site tunnels are usually shown as being symmetric (ie terminated in a similar manner at both ends).  However, AWS VPN Tunnels are not symmetric, they are initiated from one end (with the Virtual Private Gateway - VGW) and terminated at the other (with something described by the Customer Gateway - CGW) known as the Customer Gateway Device.

It is not possible to terminate a AWS VPN tunnel with an AWS asset such as Client VPN Endpoint, or Customer Gateway etc - you must use a hardware or software appliance (StrongSwan is the software appliance option I chose).  It is possible to terminate an AWS VPN with a Transit Gateway, but Outsystems do not support this.  There is no doubt a Transit Gateway would be the best option, if it were available and I could stop here.

But it is not and I ended up with something like this:

Routing

The next point is the routing decision.  There are two options for routing: Dynamic or Static.  

Static Routing means you need to share the routes in the router configuration with the AWS routers. If you need to add a new route you'll need to do it manually.  

Dynamic routing uses BGP ASN to identify networks and automatically calculate routes.  A BGP ASN is supplied in the Outsystems configuration file for dynamic routing and the ASN is set as a parameter in the Cloud Configuration Template, see below.

Cloudformation Template Solution

There is a well documented Cloudformation Template written by AWS to implement StrongSwan that supports BGP dynamic routing:

https://github.com/aws-samples/vpn-gateway-strongwswan

This template is supported by AWS and is more or less plug and play - if you know which addresses to plug in where, because AWS does not support a configuration file for StrongSwan with dynamic routing, the configuration file supplied by Outsystems does not offer clear instructions on this, so refer to the notes below before attempting to launch this template.  

Make a VPN Request

Make a VPN request from PaaS Lifetime with the following parameters:

• Contact (email):
• Public IP Address (this should be an Elastic IP address):
• Internal Network Range (CIDR of your local VPC that will host the CGW Device being offered to the VPN tunnel): 
• VPN Device (The software running the CGW Device): Generic / StrongSwan v5+ (AWS currently do not offer a specific configuration file for Dynamic routing with StrongSwan)
• Routing (Dynamic is preferred, static is simpler if you do not want to use the AWS Cloudformation template): Dynamic

If your databases use different ports to 1521 make sure you raise a support ticket to explain what ports you need available.

If you specify Static Routing the Configuration file from Outsystems offers a very good guide to configure StrongSwan on Ubuntu 16.4

These two AWS guides offer a very good starting point to setting up a testbed VPN with static routing and StrongSwan:

https://www.youtube.com/watch?time_continue=23&v=AF3bGRqnKfk

https://www.youtube.com/watch?v=VWqRrMGHJQg

Cloudformation Template Parameters

For Dynamic Routing, the following parameters in the configuration file supplied by Outsystems correspond to the parameters in the Cloudformation Template:

Use the following parameters to adopt whatever naming convention you wish, they are optional:

• Organization Identifier (pOrg) 
• System Identifier (pSystem)
• Application Identifier (pApp)
• Environment Purpose (pEnvPurpose)

Parameters for the two VPN tunnels: 

Each parameter is listed below along with the template parameter name in parentheses and with the location of where to find the appropriate value in the CGW Device configuration file supplied by Outsystems (the configuration file is written for Generic devices):

Tunnels #1 & #2

• VPN Tunnel 1 Pre-Shared Key (pTunnel1Psk): IPSec Tunnel #1 | #1\: Internet Key Exchange Configuration | Pre-Shared Key
• VPN Tunnel 1 Remote External IP Address (pTunnel1RemoteExternalIpAddress): IPSec Tunnel #1 | #3\: Tunnel Interface Configuration | Outside IP Addresses | Virtual Private Gateway (ip address)
• VPN Tunnel 1 Remote Inside CIDR (pTunnel1RemoteInsideCidr): IPSec Tunnel #1 | #3\: Tunnel Interface Configuration | Inside IP Addresses | Virtual Private Gateway (cidr)
• VPN Tunnel 1 Local Inside CIDR (pTunnel1LocalInsideCidr): IPSec Tunnel #1 | #3\: Tunnel Interface Configuration | Inside IP Addresses | Customer Gateway (cidr)
• VPN Tunnel 1 BGP ASN (pTunnel1BgpAsn): IPSec Tunnel #1 | #4\: Border Gateway Protocol (BGP) Configuration | BGP Configuration Options (only supplied in a dynamic routing request)
• VPN Tunnel 1 BGP Neighbor IP Address (pTunnel1BgpNeighborIpAddress): IPSec Tunnel #1 | #4\: Border Gateway Protocol (BGP) Configuration | Neighbor IP Address

Tunnel 2 the same as above but use the Tunnel #2 options

Local Network

• VPC ID (pVpcId): VPC that will host the Customer Peer of the VPN tunnel (select from list)
• VPC CIDR Block (pVpcCidr): CIDR of VPC that will host the Customer Peer of the VPN tunnel 
• Subnet ID for VPN Gateway (pSubnetId): Subnet you want to locate the instance hosting StrongSwan ie Customer Peer of the VPN tunnel (select from list)
• Use Elastic IP Address? (true/false) (pUseElasticIp): Set to True
• Elastic IP Address Allocation ID (pEipAllocationId): The allocationId of the EIP created for the Customer Peer of the VPN tunnel (starts with eipalloc) not the AssociationId
• Local VPN Gateway's BGP ASN (pLocalBgpAsn):  IPSec Tunnel #1 | #4\: Border Gateway Protocol (BGP) Configuration | Customer Gateway ASN

Instance

• EC2 AMI ID (pAmiId): use default
• EC2 Instance Type (pInstanceType): as required

AWS VPC Adjustments

Add a route entry to the VPC default route table, Outsystems PaaS (VGW side) network CIDR should point to the network interface of the instance created in the Cloudformation Template.  When the template is changed - check the route is not blackholed and update the reference to the network interface if necessary.

Check the EC2 instance running the CGW peer has Source/Destination Check disabled in its Network Settings - the Cloudformation template does this.

Cloud Formation Template Refinements

Some optional modifications to the cloudformation template:

To allow ssh:

At Line 283, Add newline: KeyName: "keyname"

[replace <keyname> with the name of a Key Pair available from the VPC.  Spacing and tabs matter in these templates]

At Line 275 add new lines:

        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref pVpcCidr

Enable IKE v2 rather than IKEv1

At Line 456, update keyexchange=ikev1 to keyexchange=ike # this defaults to the use of IKE v2

It is worth bearing in mind the t3 instance type is the smallest instance type to offer up to 5 Gbps network performance and the micro version has 1 Mb of memory on 2 vCPUs, you may want to adjust the options available to suit your needs. See line 215 etc,

Gotchas

It is best to test the VPN from another instance (Create a security group that allows ICMP and TCP 443 and add this security group into the Security group for the Customer Gateway Device instance).

Configuring AH port 51 and ESP port 50 in AWS is a little unusual.  When set correctly, the protocol will be listed in the Security Group as AH (51) or ESP(50) - use the 'Custom Protocol' option to configure the entry - do not use 'Custom TCP'.

Troubleshooting

Install the Netchecker eSpace on your Outsystems development platform to run nslookup, telnet and ping tests - the download is available from the list of versions in the table (not obvious):

https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/Use_NetChecker_to_troubleshoot_your_connection

If you have enabled ssh on the Customer Gateway Device then run tcpdump on it to watch for traffic over the tunnel:

sudo tcpdump -eni any icmp or port 1521 or esp

This is the blurb from the end of the configuration file for a static routing option with StrongSwan, but it is worth repeating here as it is useful for troubleshooting dynamic routing as well:

Check if your updown script worked properly. You can use the following commands (ssh into the Customer Gateway Device) to test if there are entries created for each of your tunnels:

• Execute 'sudo ipsec statusall' to ensure both of your tunnels are ESTABLISHED
• Execute 'sudo ip route' to ensure route table entries were created for each of your tunnel interfaces, and the destination is the remote VPC CIDR (ie the CIDR of the Outsystems VPC)
• Execute 'sudo iptables -t mangle -L -n' to ensure entries were made for both of your tunnels in both the INPUT and FORWARD chains
• Execute 'ifconfig' to ensure the correct 169.254.x addresses were assigned to each end of your peer-to-peer virtual tunnel interfaces and packets are being processed in the tunnel
• Attempt to ping a destination in the remote VPC from a host within your local network. If there is no response, check to see if your instance's security groups are allowing traffic and verify your settings entered above are correct once again

You may find that ICMP ping packets will not traverse the tunnel as they may not be implemented in Security Groups on the Outsystems side.  When using Netchecker use Telnet on port 443 instead or to access a database the fqdn of the database and the appropriate port.

PaaS Database Access

You will also need to raise a separate support ticket to access your PasS databases from your On-Premise cloud, if that is your plan.

https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/Access_the_database_of_your_PaaS

You will need to choose either read/write or read only credentials.

I hope that is of use to someone.

There is a final addendum to add with regard to DNS settings.

Create a new Security Group giving access to CIDR of VPCs on both sides of the VPN to Port 53

In AWS Route 53 

Create Resolver Outbound and Inbound Endpoints in the CGW VPC.

Use the default setting and associate each with the VPC and a suitable subnet and use the Security Group above

Create Resolver Rules to FORWARD requests for the outsystems domain to the DNS IP addresses provided in the configuration email by Outsystems on port 53 eg acme-ltd.outsystemsenterprise.com.  Associate the rule with an appropriate list of VPCs and the Endpoint created above.

If you have requested a database connection over VPN make an additional rule to forward the database domain as well eg somethingawscrazy.eu-west-2.rds.amazonaws.com

A final, final addendum to this saga, with a big thank you to Ricardo Miranda at OS Support and the AWS Support team.

When creating the Outbound Resolver Rules on the Customer Gateway VPC, Route 53 the Resolver Rules must point to the specific db CNAME rather than the subdomain eg ec2-33-31-30-96.eu-west-2.compute.amazonaws.com.

The CNAME can be identified by 

#dig oscrazydbname.somethingawscrazy.eu-west-2.rds.amazonaws.com 

or using nslookup in Netchecker

There needs to be a rule for each database CNAME, and presumably each ec2 server in the OS PaaS you need to resolve to, although I have not tried that yet.  This is not satisfactory, as these CNAMEs are obviously likely to change as server addresses are changed, but AWS say this is the only solution at the moment until the resolver recognises wildcards in the forwarding rules.