Create a Dual Stack Virtual Private Cloud (VPC) in AWS

Lawrence E. Hughes 5 November 2017

This recipe assumes you already have an AWS account. If you don’t there is a lot of information online

(including at AWS) on how to create an account.

Login to AWS Website at https://aws.amazon.com/

Click Sign in to the Console

A VPC is the virtual network in which you deploy virtual subnets and virtual machines (instances).

Enter your password and click Sign In to login with your AWS account. You will see the AWS Services

menu:

Under Network & Content Delivery, click on VPC. You will see the VPC Dashboard:

I happen to have two VPCs currently. For this writeup I will be creating a new one.

Click Start VPC Wizard.

You will see the first page of the VPC Wizard:

Step 1 is to choose the type of VPC. For this writeup, we will choose the first option, VPC with a Single

Public Subnet. Other options are for more complex setups. The second option would involve a second

(internal) NAT gateway (for which there are ongoing charges).

For IPv4, we will allocate a private /16 CIDR block (e.g. 192.168.0.0/16) for the VPC. This is good for up

to 256 /24 subnets. We will also create a single /24 subnet within the VPC block (e.g. 192.168.1.0/24).

This block will be behind one level of NAT44 from the Internet, using either a Public IPv4 address (which

is dynamically assigned each time the instance is started) or an “elastic” IPv4 public address, which is

static (you get the same public IPv4 address every time the instance starts). We can deploy multiple OS

instances in the single subnet, but if we need more than one subnet we can create additional subnets

(e.g. 10.2.0.0/16, etc) behind a single Public IPv4 address.

For IPv6, we will obtain a /56 block of AWS’s allocated public (globally routable) IPv6 addresses (e.g.

2600:1f14:611:b600::/56). This is good for up to 256 subnets. In the first subnet, we will carve off one

/64 sub-block from this /56 block by choosing the last 8 bits of the 64 bit prefix, e.g. “01” for

2600:1f14:611:b601::/64. Of course there is no NAT happening here, as all of these IPv6 addresses are

public, and can make outgoing connections or accept incoming connections. We can deploy multiple OS

instances in the single subnet, but if we need more than one subnet we can create additional subnets

(e.g. 2600:1f14:611:b602::/64, etc).

Select VPC with a Single Public Subnet and click the blue Select button.

You will now select the CIDR (VPC level) blocks as well as the blocks for the first subnet.

The IPv4 CIDR block is the entire pool of private IPv4 addresses for this VPC. Enter some /16 private

block (from the RFC 1918 ranges). A /16 is the largest IPv4 CIDR block you can configure in AWS. It

informs you that there are a total of 65,531 usable IPv4 addresses in this block.

The IPv6 CIDR block will be a /56 block carved out of AWS’s total IPv6 allocation. They will chose the first

56 bits of the IPv6 addresses in this CIDR block. You have no control over those bits. There is no way to

choose a larger or smaller IPv6 VPC level CIDR block in AWS.

Choose Amazon provided IPv6 CIDR block.

Choose a name for this VPC (e.g. Demo_VPC)

Next choose the /24 block for the first IPv4 subnet (e.g. 192.168.1.0/24). The wizard informs you that

there are 251 usable IPv4 addresses in this subnet block.

To carve off a /64 IPv6 block for the first subnet, enter two hex digits (e.g. “01”) to complete the full 64

bit prefix for the subnet.

For Availability Zone you can select any of your zones, or let AWS choose for you.

You can name your first subnet (e.g. Subnet 1)

Click on the blue Create VPC button. It will then show a progress box “Creating VPC”.

When the VPC is created, the wizard will then show the following:

Click the blue OK button.

Now under Your VPCs, you can select Demo_VPC:

If we look under the Summary tab, we see:

If we look under the CIDR Blocks tab, we see:

If we select Subnets, you can view any of the currently defined subnets. Select Subnet 1 from

Demo_VPC:

Under Summary, you can see the subnet IP blocks:

Under Route Table, you can see that both IPv4 and IPv6 subnets have routes defined:

Under Network ACL, you can see the default firewall rules for Subnet 1.

This currently allows all incoming and outgoing traffic on this subnet, on both IPv4 (0.0.0.0/0) and IPv6

(::/0) on this subnet. If you want any restrictions at the subnet level, add them here. You can add firewall

rules at the instance level later. I normally leave the subnet level rules wide open.

If you are deploying servers in this subnet, the IPv6 is good already. For IPv4 it will obtain a dynamically

assigned public IPv4 each time the instance is started, but you probably want a static one that remains

the same even if you restart the instance. This requires an elastic IPv4 address. We will allocate this

later. When you do this, automatically release the dynamically assigned public IPv4 address on that

instance.

It is interesting (given the scarcity of IPv4 public addresses) than you can’t associate an elastic address

with an entire subnet, so that all instances in that subnet share the same public address (with Cone

NAT), but AWS only supports 1:1 NAT which requires a separate IPv4 public address for each node

(instance). This makes sense – with Cone NAT you can’t accept incoming connections. 1:1 NAT allows

incoming connections on any port.

Just so you will see how to deploy an instance in this subnet, let’s create a basic instance of Windows

Server 2016 and configure it to use both the IPv4 and IPv6 addresses just configured.

Deploy Windows Server 2016 in Subnet 1 of Demo_VPC.

Go back to the Services menu and select EC2.

Click Launch Instance.

From the list of common AMI’s, select Windows Server 2016 Base.

From the instance type, select t2.micro

When ready, select the AMI and instance type by clicking the blue Select button.

Click Configure Instance Details. You should see:

Select the network as Demo_VPC

Select the subnet as Subnet 1

Enable Auto-assign (IPv4) Public Address

Enable Auto-assign IPv6 IP

Don’t join any existing domain (don’t try to create a new directory at this time)

Don’t join any IAM role (don’t try to create new IAM role at this time)

At bottom right, click Add Storage.

30GB is sufficient.

At bottom right, click Add Tags. Just skip over this part.

At bottom Right, click Configure Security Group

For now, it is allowing incoming RDP. Let’s add incoming ICMPv4 and ICMPv6.

At bottom right, click Review and Launch. You should see something like this:

Click the blue Launch button. You should see this:

If you have an existing keypair, use it.

Acknowledge you have access to the private key, then click Launch Instances

You now have a new instance running:

Name it WS2016-1.

Select it.

Notice the following:

The IPv4 Private Address is 192.128.1.89 (assigned via DHCPv4 from the “Subnet 1” /24 block).

The IPv4 Public Address is 54.213.231.197. This is a dynamically assigned IPv4 Public Address. Let’s

change that to an Elastic IPv4 address right now.

At the top, select Actions / Networking / Manage IP Addresses.

Click Allocate an Elastic IP.

Click the blue Allocate button.

You now have a new Elastic IPv4 Public address. Click the blue Close button.

View your Elastic IP Addresses:

Select the new one, and then select Actions / Associate addresses

Select WS2016-1 (it will be shown as the interface ID), then select the private IP address (192.168.1.89).

Now click the blue Associate button.

You will now see:

Congratulations, you have now switched from a dynamic Public IPv4 to a static Elastic Public IPv4

address. When you restart this instance, it will always use this public IPv4 address.

The IPv6 Address is 2600:1f14:9ff:c201:4438:94dc:aed3:4394 (assigned randomly by DHCPv6 from the

“Subnet 1” /64 block. We will change that shortly to a manually assigned address.

Change IPv6 interface identifier (last 64 bits) from randomly generated to manually assigned:

Go back to your instances, select WS2016-1, then click Actions / Networking / Manage IP Addresses

First, note that the new Public IPv4 address is our new Elastic Public IPv4 address (34.216.7.178).

Now let’s assign a new IPv6 address that’s easier to work with. Under IPv6 Addresss, click Assign new IP.

Where it says “Auto-assign”, type in the new IPv6 global address. It must have the same first 64 bits as

the existing address (in this case 2600:1f14:9ff:c201::).

Enter 2600:1f14:9ff:c201::11, or whatever you want.

Now click the blue Yes, Update button.

You now have two IPv6 global addresses. Nothing wrong with that, but’s let’s get rid of the randomly

assigned one. Click the Unassign link after it. It changes to strikeout font and the Unassign changes to

Undo.

Now click the Yes, Update button again.

Now we have both the IPv4 public address and IPv6 global address we wanted.

Under Instances, we now see:

Now let’s test it:

Select the WS2016 instance, then click Actions / Connect.

You will see:

Click on Download Remote Desktop File

When asked to Save or Open the file, select Open. You will see RDC pop up ready to connect to the

instance:

You now need to get the password that AWS created for the Administrator account.

In the Connect to Your Instance form, click on Get Password.

Find the .pem file of the generated keypair by browsing. It should appear in the box starting with “-----

BEGIN RSA PRIVATE KEY-----“. Then click Decrypt Password. The password will appear.

The password is shown after Password. Copy it into your clip board (highlight and hit Ctrl-C). Now go to

the RDP login and paste the password into the box just under Administrator and hit OK.

You should see something like this:

Ignore the certificate errors. Click Yes (connect despite certificate errors).

You are now connected to the instance:

Start a command prompt and type the command ipconfig /all

You should see something like this:

C:\Users\Administrator>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : EC2AMAZ-DGD092P

Primary Dns Suffix . . . . . . . :

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : us-west-2.ec2-utilities.amazonaws.com

us-east-1.ec2-utilities.amazonaws.com

us-west-2.compute.internal

Ethernet adapter Ethernet 2:

Connection-specific DNS Suffix . : us-west-2.compute.internal

Description . . . . . . . . . . . : AWS PV Network Device #0

Physical Address. . . . . . . . . : 0A-BD-65-06-20-68

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IPv6 Address. . . . . . . . . . . : 2600:1f14:9ff:c201::11(Preferred)

Lease Obtained. . . . . . . . . . : Sunday, November 5, 2017 7:43:08 AM

Lease Expires . . . . . . . . . . : Monday, November 6, 2017 1:50:51 AM

Link-local IPv6 Address . . . . . : fe80::9de:6fb:2bee:6c6a%3(Preferred)

IPv4 Address. . . . . . . . . . . : 192.168.1.89(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Lease Obtained. . . . . . . . . . : Sunday, November 5, 2017 7:43:06 AM

Lease Expires . . . . . . . . . . : Monday, November 6, 2017 2:43:24 AM

Default Gateway . . . . . . . . . : fe80::86e:b5ff:fef6:2d94%3

192.168.1.1

DHCP Server . . . . . . . . . . . : 192.168.1.1

DHCPv6 IAID . . . . . . . . . . . : 101592425

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-21-90-6E-87-0A-BD-65-06-20-68

DNS Servers . . . . . . . . . . . : 192.168.0.2

NetBIOS over Tcpip. . . . . . . . : Enabled

Note the following:

DHCP Enabled = Yes (DHCPv4 is being used for IPv4 autoconfiguration – that’s how AWS assigns the

configured IPv4 network configuration to your instance)

IPv4 private address: 192.168.1.89, obtained from DHCPv4

IPv4 subnet mask: 255.255.255.0 (/24), obtained from DHCPv4

IPv4 default gateway: 192.168.1.1, obtained from DHCPv4

IPv4 DNS Servers: 192.168.0.2 (probably a DNS relay provided by AWS), obtained from DHCPv4

Autoconfiguration Enabled = Yes (DHCPv6 is being used for IPv6 Autoconfiguration – that’s how AWS

assigns the configured IPv6 address to your instance)

IPv6 address: 2600:1f14:8ff:c201::11, obtained from DHCPv6

IPv6 default gateway: f80::86e:b5ff:fef6:2d94%3, obtained from ND Router Discovery

IPv6 DNS Servers: [none – could have been obtained from DHCPv6 or from RA message]

Even though we opened ICMPv4 and ICMPv6 in the instance firewall, we still need to open them in the

Windows Server host based firewall.

Bring up Start / Windows Administrative Tools / Windows Firewall with Advanced Security

Note that the firewall is currently ON (all profiles):

Click Inbound Rules, then New Rule. Select rule type as Custom.

Click Next.

For Program, accept default All programs. Click Next.

For Protocols and Ports, set Protocol type to ICMPv4. There is no need to select which ICMPv4 messages

(accept all). Click Next.

For Scope, accept default (Applies to Any local IP address, Applies to Any remote IP address). Click Next.

For Action, accept default Allow the connection, click Next.

For Profile, accept default (all three profiles), click Next.

For Name, name it “Incoming ICMPv4”, click Finish.

Now repeat for protocol ICMPv6 (Name = “Incoming ICMPv6”)

You should now have two new rules:

Now let’s try pinging the node from outside over IPv4 and IPv6:

C:\Windows\system32>ping 34.216.7.178

Pinging 34.216.7.178 with 32 bytes of data:

Reply from 34.216.7.178: bytes=32 time=190ms TTL=112

Reply from 34.216.7.178: bytes=32 time=190ms TTL=112

Reply from 34.216.7.178: bytes=32 time=190ms TTL=112

Reply from 34.216.7.178: bytes=32 time=190ms TTL=112

Ping statistics for 34.216.7.178:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 190ms, Maximum = 190ms, Average = 190ms

C:\Windows\system32>ping 2600:1f14:9ff:c201::11

Pinging 2600:1f14:9ff:c201::11 with 32 bytes of data:

Reply from 2600:1f14:9ff:c201::11: time=223ms

Reply from 2600:1f14:9ff:c201::11: time=224ms

Reply from 2600:1f14:9ff:c201::11: time=223ms

Reply from 2600:1f14:9ff:c201::11: time=223ms

Ping statistics for 2600:1f14:9ff:c201::11:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 223ms, Maximum = 224ms, Average = 223ms

These addresses can now be added into your external DNS (e.g. as ws2016a.aws.sixscape.net).

Now let’s try testing outgoing IPv6 – surf to www.ipv6-test.com from the instance:

Fully functional!