0

We are currently running AWS Lambda functions within a VPC and for example already have a peering connection setup to MongoDB Atlas to have our AWS Lambda's within the VPC communicate to our MongoDB Atlas-hosted database.

Now a requirement has come up that a specific service within our VPC that we trigger by an AWS Lambda and that also runs within the same VPC has to access an on-premise network function / host over VPN. Furthermore that network needs to be able to respond to messages to that service so a site-to-site connection is needed I assume.

The customer has given us the IKE Phase One Parameters, IKE Phase Two Parameters (IPSEC), their local peer IP addresses, the VPN communication ports accepted and the local encryption domains.

They are now asking for our remote peer IP addresses and remote encryption domains.

Question 1: Is what we're trying to achieve feasible on AWS in a VPC (I'm reading conflicting posts about this.

Question 2: Am I correct in assuming that the tunnel initiating will have to happen from the customer's side and that we then use network monitoring polling to keep the tunnel active?

Simon
  • 113
  • 4
  • Can you confirm if is the Lambda that needs to talk back to on premises or the 'specific service'? Can you elaborate as to what that service is exactly? and what protocol it uses? – Alex Moore Sep 02 '18 at 13:59
  • Our service is a HTTP to UDP gateway that sends messages over UDP in the ISO 8583 format. The customer's service is ISO8583 host that is only accessible through a VPN. We already have the binary messaging service on our side that is able to convert http to udp and and visa versa but the question now is whether we can have this persistent VPN connection from our VPC to the customers on-premise host setup. For AWS Managed connections it seems the customer's host will need to initiate the connection and take responsibility to keep alive (if such a VPN connection is possible in the first place) – Simon Sep 02 '18 at 15:10
  • What I mean is, is it the Lambda itself or an instance in the VPC that needs to talk over the VPN? – Alex Moore Sep 02 '18 at 15:15
  • I see now where the title might be confusing. It can be an EC2 instance that runs our http to ISO8583 tool but it's the lambda within a VPC that will initiate the request to our http to ISO8583 tool within that same VPC that will need to talk to the customer's host over VPN so the setup would be site-to-site from any service within that VPC to the customer's host over VPN I assume? – Simon Sep 02 '18 at 15:25

1 Answers1

1

Regarding question 1.

Assuming you are referring to the ability to connect via an IPSec based VPN to securely connect to resources that are located outside AWS. The answer is yes. However, the native AWS implementation of this does have some restrictions. The first is that it is not possible to specify any aspects of the phase 1 or phase 2 configuration settings. Instead AWS provide you with the ability to download pre-configured settings for a range of manufacturers, but also provide some good generic examples too.

Some good resources are:

AWS Managed VPN Connections - provides details on the AWS VPN Gateway service

Your Customer Gateway - provides information on the settings required on the device outside of AWS

Regarding question 2.

This is true, if the tunnel drops for some reason, the AWS side cannot initiate it (this is a VERY annoying limitation if you ask me). However there are ways around it. Some devices support sending keep alive packets to keep the tunnel up. For example Cisco ASA's can make use of IP SLA feature to send SLA messages accorss the tunnel to keep it up. Extract from the sample ASA configuration:

In order to keep the tunnel in an active or always up state, the ASA needs to send traffic to the subnet defined in acl-amzn. SLA monitoring can be configured to send pings to a destination in the subnet and will keep the tunnel active. This traffic needs to be sent to a target that will return a response. This can be manually tested by sending a ping to the target from the ASA sourced from the outside interface. A possible destination for the ping is an instance within the VPC. For redundancy multiple SLA monitors can be configured to several instances to protect against a single point of failure.

Or you can simply arrange for a system on one side to periodically send a ping - via a cron job or scheduled task.

Another option however is to deploy your own IPSec gateway into AWS - either running on the instance itself, or on another instance, you then can update the route table on your subnet to route to the off AWS subnets via this instance. This allows you more control on the IPSec settings and behaviour - but is arguably more complex to manage compared to the native AWS service.

Alex Moore
  • 1,704
  • 5
  • 12
  • Amazing answer. We've been talking to the team and came to similar conclusions. This blogpost https://blog.theodo.fr/2018/01/setup-software-vpn-aws-platform-third-party-corporate-network/ also outlines the drawbacks of using a AWS managed VPN like you mentioned and at the same outlines some initial indicators about the complexity (but at the same time flexibility) of setting up your own. – Simon Sep 02 '18 at 16:52