Extending VPN Connectivity to Amazon AWS VPC using AWS VPC VPN

Gateway Service
https://docs.openvpn.net/how-to-tutorialsguides/administration/extending-vpn-connectivity-to-amazon-aws-vpc-usingaws-vpc-vpn-gateway-service/

Introduction
If you are using Amazon Web Services, you probably already know that Amazon VPC has built-in functionality that
you could utilize to connect your on-premise network to your VPC instances on the Amazon cloud. However, if you
already have an OpenVPN Access Server setup on premises and would like to extend connectivity of your OpenVPN
connection to the Amazon cloud, you can do so easily without purchasing additional hardware or expensive gear.
After completing these instructions, your on-premise VPN users should also have access to your Amazon setup
without any complicated setup or installation procedures.

Prerequisites
To begin, you will need a working OpenVPN Access Server setup and an Internet-facing IP address for this instance.
If you do not already have one installed, please follow this link for our virtual appliance. The virtual appliance will have
everything you need pre-installed so you do not have to compile and install them yourself.
If you are using a software package installation, or do not wish to use our appliance, you will need to download
Strongswan from source at www.strongswan.org and then install the package after you have compiled the
software from source. You will also need the following supplementary files to connect to Amazon's VPN service (you
will not need these files if you are using our virtual appliance):
Right click the link(s) below, and select Save link / selection as to download the file to your computer:
ipsec.sh - save to /sbin, then set as executable by issuing the chmod +x /sbin/ipsec.sh command.
ipsec.secrets - save to /etc, or the directory specified inside your Strongswan configure file.
ipsec.conf - save to /etc, or the directory specified inside your Strongswan configure file.
The steps below assume that you already have a running and up to date OpenVPN Access Server installed on your
system (preferably the virtual appliance). Before you proceed, please make sure that your Amazon subnets do not
overlap with your on-premises subnets. If overlaps do exist, you will need to renumber these subnets before you
begin the following process.

Amazon VPC VPN Setup

To setup the VPN connection, login to your AWS Management Console. From there, select the VPC service from the
list of options presented.

In your VPC dashboard, you should already have at least 1 VPC listed, similar to the image indicated below. If you do
not already have a VPC, most likely your instances are inside EC2 Classic or you may be inside the wrong active
region (check the top right hand corner and see what your active region is). If your instances are currently inside EC2
Classic, you will need to create a new VPC and migrate your instances over to that VPC (by creating image AMIs
and then redeploying them via the custom AMI process).

Afterwards, select the Customer Gateways option from the list of options presented. Click the Create Customer
Gateway to continue.
In the dialog that opens, enter the public IP address of your OpenVPN Access Server instance, with routing set to
Static (default). Unlike OpenVPN Access Server, this server must be Internet-facing and must not be using NAT.
You will not be able to use these procedures if you are using NAT, even if port forwarding is being used*. After you
have entered the IP address of your OpenVPN Access Server, click the Yes, Create button to continue (please use
your own IP address in the field below; the IP address in the screenshot is for demonstration purposes
ONLY!)

* If 1:1 NAT or NAT DMZ is used, enter the external facing IP in the field below. If your router supports forwarding of
ESP streams (IP protocol 50) and UDP port 500, do so, and enter the router's public IP address in the box below.
Some routers may support IPsec passthrough features that allow you to simply forward UDP port 500 to your internal
machine. Consult your firewall / router vendor for further assistance if you are uncertain.

After this has been completed, visit the Virtual Private Gateways section on the left and then click the Create
Virtual Private Gateway button. Click the Yes, Create button to complete the creation process. Select the virtual
private gateway that is created, and select Attach to VPC. Select the VPC you would like to connect to using the
VPN connection, and then click Yes, Attach (if you do not know what your VPC identifier is, visit the Your VPCs
section and drop down the identifier appropriate for your VPC).

Following the creation of your Virtual Private Gateway, visit the Route Tables section of the VPC Management
Console and select the routing table corresponding to your subnet(s). Afterwards, click the Route Propagation tab
and then select the vgw identifier for the virtual private gateway that was created earlier, then click the Add button.

Finally, visit the VPN Connections section on the left, and click the Create VPN Connection button.
In the dialog that results, select the virtual private gateway (vgw) and the customer gateway that you have
previously created. You can refer to the previous screens if you do not remember what these identifiers are.
Select Use static routing, and then enter all of the IP prefixes of your on-premises network, as well as the virtual
VPN networks created by OpenVPN Access Server. In order words, enter any networks here that you want to be
communicating with your Amazon VPC network. Any networks not listed here will not be able to communicate with
your Amazon cloud instances. You can always modify these selections at a later time if you would prefer.
After this is done, click the Yes, Create button. The VPN connection will take a few minutes to create.

After the VPN connection has been created, the State of the connection should switch to available. As the
connections have not been made yet to the VPN servers, it is perfectly normal for the icons to be red. Select the VPN
connection that was created, and then note the Tunnel 1 and Tunnel 2 IP addresses below. Click the Download
Configuration button when finished.

In the Download Configuration dialog, select Generic as a vendor and then click the Yes, Download button. A text
file should be generated that contains your pre-shared keys (PSKs).

Inside the generated file, note the two Pre-Shared Keys that are under the IPsec Tunnel #1 and IPsec Tunnel #2
sections. These PSKs correspond to the password you will be using to access the VPN connection for Tunnel 1 and
2, respectively.
Now, SSH into your OpenVPN Access Server on-premise instance and open the /etc/ipsec.conf file with a text
editor (like nano).
In the file that is opened, change the rightsubnet= to your VPC CIDR mask. If you do not remember what this is,
consult the Your VPCs section of the VPC Management Console.
Under the VPC-CUST-GW1 and VPC-CUST-GW2 sections respectively, change the right= IPs to the Tunnel 1 and 2
IPs you have noted above. In our case, the proper configuration would look like the following:

Afterwards, open the /etc/ipsec.secrets file, and enter the PSKs given to you in the configuration file that was
downloaded. Please use the format designated in the file for the connection to work properly.

Save the file, and return to the command prompt. To start the VPN connection, issue the ipsec start command. If the
connections were successful, you should see more than one security associations listed when you issue the ipsec
status command. If you would like the VPN to start on system startup, add the ipsec start command to
the /etc/rc.local file on your OpenVPN Access Server instance.

MENU

AWS VPC Network Structure

27 February 2016 on aws

I recently started playing around with AWS. One of the really cool things about AWS is the Virtual Private Cloud (VPC) features. By creating a VPC, you
create a private network for yourself complete with NAT gateways, custom route tables, firewalls and more.

VPC Components
A VPC is made up of several main components:

CIDR Block

When you create your VPC, you are asked to define a CIDR block, which is the range of IP addresses you want your VPC to use. For example,
10.0.0.0/16 means you can use 10.0.0.0 - 10.0.255.255 (65,534 addresses).

Subnets

A subnet is a CIDR block within your VPC that you want to group together. Instances you launch into your VPC are assigned a subnet, and the subnet
defines how network traffic is routed. For example, if a subnet has a route table that is able to route traffic through the internet gateway, then it's public
because it's connected to the internet. Otherwise it's private.

Security Groups & Network ACLs

Both Security Groups and Network ACLs are collections of firewall rules that define which ingress and egress network traffic is allowed.

There are a few differences between them:

Security Groups are applied to specific instances and can be stateful (similar to iptables). Security Groups filter
traffic to and from instances.

Network ACLs provide stateless filtering on traffic entering or leaving a subnet. Traffic that stays within the same
subnet is not filtered.
So both have their place. I usually just use Security Groups.

Route Tables

Route tables are assigned to subnets and define how traffic within the subnet is routed to various destinations. For example, a route table defines if and how
traffic is routed to the wider internet.

Internet Gateways

The Internet Gateway is how your VPC connects to the internet. You use an Internet Gateway with a route table to tell the VPC how internet traffic gets to
the internet.

An Internet Gateway appears in the VPC as just a name. Amazon manages the gateway and there's nothing you really have a say in (other than to use it or
not; remember that you might want a completely segmented subnet that cannot access the internet at all).

Elastic IPs

An Elastic IP is a static IP address you reserve and can attach to specific network interfaces.

An EIP is the only way to get a static IP within AWS.

NAT Gateways

A NAT Gateway allows you to have private instances who can connect to the greater internet (that is, it performs NAT translation) through one of your
elastic IPs.

Availability Zones

A VPC is region-specific, but covers all availability zones within the region.

Each subnet you define is assigned to a specific zone. This factors into your subnet design.

While each subnet is assigned a specific zone, you can of course communicate across the network to instances in any zone.

Subnet Design
One of the most important things to think about when creating your VPC is the design of your subnets. This matters a lot because you cannot change your
subnets (well, not without disrupting your services and configuration!).

Your goal is about designing the subnets such that you solve todays problems, but leaving yourself enough room to grow to accommodate tomorrows
problems. This basically comes down to limiting the size of your subnets (you can always add new subnets later).

Here's my advice for a "small" (relatively) VPC:

Start with two availability zones and dedicate /21 blocks to each (2048 addresses).

In each zone, define subnets for public and private traffic. For each of those subnets, dedicate a /23 block (512
addresses).
So with this means you'll define 4 subnets (2 per zone), but leave yourself loads of room for expansion if you need it.

Zone A - 10.0.0.0/21 (10.0.0.0 - 10.0.7.255)

Subnet A Public - 10.0.0.0/23 (10.0.0.0 - 10.0.1.255)

Subnet A Private - 10.0.2.0/23 (10.0.2.0 - 10.0.3.255)

The rest of the block is unused, so could be used for something else later.

Zone B - 10.0.8.0/21 (10.0.8.0 - 10.0.15.255)

Subnet B Public - 10.0.8.0/23 (10.0.8.0 - 10.0.9.255)

Subnet B Private - 10.0.10.0/23 (10.0.10.0 - 10.0.11.255)

The rest of the block is unused, so could be used for something later.

The rest of the VPC block is unused, so you have lots of room for expansion later.
Remember that some of this is just logical grouping of IP addresses (i.e. deciding that 10.0.0.0/21 is all "Zone A"), some of it is practical (subnets have
ACLs, route tables, etc) and some of it is just leaving yourself space to grow.

What you DON'T want to do is go crazy and use the entire VPC block of addresses in a single subnet. Leave yourself plenty of free space, you never know
when you might need to create a new subnet.

Public vs Private and NAT Gateways

A public subnet means a subnet that has internet traffic routed through AWS's Internet Gateway. Any instance within a public subnet can have a public IP
assigned to it (e.g. an EC2 instance with "associate public ip address" enabled).

A private subnet means the instances are not publicly accessible from the internet. They do NOT have a public IP address. For example, you cannot access
them directly via SSH. Instances on private subnets may still access the internet themselves though (i.e. by using a NAT Gateway).

A NAT Gateway is comprised of:

The NAT Gateway itself. This is a highly available instance managed by AWS. You could create an EC2 instance
and manage it yourself, but the NAT Gateway is usually the simpler option.

An Elastic IP. This is the public IP that your gateway uses to communicate with the outside world.
To use a NAT Gateway:

1.

Create an Elastic IP

2.

Create a NAT Gateway

Assign the Elastic IP you just created

Set the Subnet to your public subnet. (It must be on the public subnet or else it won't be routable).

3.
o
4.

Create a new Route Table

Add a new route with destination 0.0.0.0/0 and target being your new NAT Gateway.
Assign this route table to your private subnet.

Accessing Private Instances via a Bastion Host

Instances that exist on a private subnet are inaccessible directly from the internet. Instances can use the internet via the gateway, but there's no way for you
to access the instance from the internet. For example, you can't SSH into it, you can't serve a website from it, etc.

If you are running a web service like a web server, SMTP server, etc, then this is usually fine because you typically use a proxy or node balancer that has a
public interface and then passes traffic through to your private subnet.

However, you still often need access to the server for sysadmin type work or debugging. This is done by spinning up a bastion host.

A bastion host is the name for a public instance whose purpose is specifically about providing access to services on an internal network. Since this host is
public, it is often security-hardened and expected to withstand attack.

In our VPC scenario, we typically only need a bastion host so we can SSH into the servers in the private subnet. For this purpose, the bastion doesn't need
to be big; a t2.micro instance is likely enough for most workloads. All you need it for is to act as a middle-man for SSH:

You > SSH into bastion > SSH into server

A t2.micro is usually enough to support a dozen connections.

SSH and Bastion Hosts

EC2 instances by default use key files to authenticate SSH sessions. Obviously you want to keep this as it's the most secure method.

But this presents a problem. You can connect to your bastion server with a key -- that's fine. But then your bastion server needs to have the keys to connect
to every other server on your VPC private network. In other words, your bastion server has the keys to everything. That's not so good.

The best way I've found to square this problem is to use SSH proxying. I've got another article about that here: SSH with a bastion host.

AWS - VPC Networking for Beginners

Build fast, scale big with MongoDB Atlas, a hosted service for the leading NoSQL database on AWS.
Try it now! Brought to you in partnership with MongoDB.
I have worked very little in networking. I have seen L2/L3 hardwares, but I never got an opportunity
to configure, deploy or automate them. As we experience the "cloudification" of traditional IT, some of

the core IT services are already mature enough for production uses, or large-scale deployments.
Storage (s3 , openstack-swift), block storage (EBS) or compute (ec2, openstack nova) are a few.
What always excited me is understanding how much network automation is possible in public or
private clouds. It is important for broader cloud adoption.
I know there are significant innovations happening in that space, too. OpenFlow might be the
openstack equivalent in that space. Together they give you openfabrics. A cloud that accommodates
your networking devices along with SAN and rack servers.
I have done some preliminary work on AWS-VPC, and I am jotting down my learnings from it. I
always read about these concepts, but never understood what they meant. So remember, if you are
on AWS-VPC, and you do not have prior experience with networking, this might be helpful to you:

VPC
A "Virtual Private Cloud" is a sub-cloud inside the AWS public cloud. Sub-cloud means it is inside an
isolated logical network. Other servers can't see instances that are inside a VPC. It is like a vlan
AWS infrastructure inside a vlan.
In non-VPC AWS cloud, the normal one all servers get a public ip. This is used to access the
instance from outside. But if you run `ip addr show` you'll see it has a private ip. The instance itself is
not aware of its public ip (its probably NAT-ed with the public ip in their switch). The information about
private ip is also important as communications using private and public ip's incur different cost
schemes (public ip based communications incur some cost). But the point is every single instance is
visible, their names are and ips are reused. These things have significant impact on how you design
and implement your network security as well. Security groups, which selectively allow individual
types of ingress or incoming traffic, becomes more important.
A VPC is denoted by a subnet mask. For example, when one says VPC-x is 10.123.0.0/16 , that
means any instances inside this VPC will have an ip 10.123.X.Y where X and Y can be anything
between 2 to 254. A VPC can have following global components:

A DHCP option set (server that assigns dynamic ips )

Internet gateway (will come to this shortly)

One or more subnets

One or more routing tables

One or more network ACLs

Subnets: A subnet is a sub-network inside a VPC. An example of a subnet inside a VPC

(10.123.X.Y) is 10.123.1.A/24. This means any instance that belongs to this subnet will have an ip
10.123.1.A where A can be anything between 2 and 254. These are also known as CIDR notations.
An instance always belongs to a subnet. You cannot have an instance inside a VPC that does not
belong to any subnets. While spawning instances inside AWS-VPC, one must specify which subnet
the instance should belong to.
Routing tables: Network traffic of any instance inside a subnet is dictated by a routing table. An
example routing table is:
CIDR --- target
10.123.0.0/16 --- local
0.0.0.0/0 - igw (internet gateway)
This table means that any traffic destined for 10.123.X.Y ip (where X and Y can be anything from 2
to 254) will be sent directly. The rest of the traffic will be directed to igw.
Now, it's important to understand that a subnet is always attached to one and only one routing table.
So, if we spawn an instance inside a subnet that has the above-mentioned routing table attached to
it, the instance still won't be accessible from outside VPC because it does not have a public ip. One
can attach an elastic ip (which is a reusable public ip) to this instance and then access it. The
instance in turn can access the internet. Remember, for an instance to be directly available from the
internet it has to have an elastic ip and it must be within a subnet that has a routing table where nonlocal traffic is routed via an internet gateway. So, an elastic ip and an igw in the routing table are two
criterion for an instance to be available directly from the internet. Subnets with such routing tables
attached to them are also known as public subnets (non-local traffic routed to internet gateway), as
any instance with an elastic ip can be publicly available from this subnet.
On the other hand, you can specify a NAT (a gateway) instance as a target for non-local traffic inside
a routing table. You can keep the NAT box in a public subnet with an elastic ip attached to it. Now
any subnet that has this type of routing table attached becomes a private subnet because they
cannot be exposed publicly. Even if you assign an elastic ip, it won't be publicly available (recall, for
instance, to be publicly available means you need both an elastic ip as well as a routing table that
directs non-local traffic to the internet gateway). Here's an example of a private subnet:
CIDR --- target

10.123.0.0/16 --- local

0.0.0.0/0 - i-abcdef (instance ip of the NAT box)
Network ACLs, or network access control lists: Apart from routing tables, each subnet also assigned
a network ACL. Network ACLs specify what type of traffic is allowed inside the subnet. By default it
might have the following rules:
rule number --- port --- protocol --- source
100 ---- ALL --- ALL

-- action

--- 0.0.0/0 -- allow

This means that all traffic is allowed within this network. You can think of Network ACLs as subnetwide security groups. They are effective while isolating subnets from each other, reducing the
collision of domains, etc.
Entities such as RDS's and ELB's can be provisioned within VPC as well. The same rule applies for
them as other ec2 instances. If they belong to public a subnet, they can be accessed from the
internet.
In a typical web application example, you will be spawning the ELB and a NAT box inside the public
subnet and your db servers (or RDS instances) and web servers in the private subnet. Since you
have a NAT gateway (and a routing table attached to the private subnet that routes traffic via this
NAT gateway), instances from private subnets can access the internet. But the reverse is not
possible. If you do not want the instances from private subnets to access the internet, you can
remove the NAT box from the private subnet's routing table. Since all this can be done dynamically
via the web browser based console, command line tools, or AWS webservices api, you can
temporarily allow the instances from private subnets to access the internet (like while provisioning)
and then revoke it later (before joining the elb).
I'll be writing another post on how you can set up cross-availability zones highly available services
using AWS VPC from a network standpoint. This will serve the foundation of that post.