Introduction
In some cases you will want to keep your infrastructure in AWS completely separate from your internal network. I needed to integrate the infrastructure with the rest of our infrastructure, including connecting Windows server to our domain.There are three obvious ways to connect the networks:
If you have an MPLS WAN, you probably want to extend this to your AWS VPC (Virtual Private Cloud). For this you would use DirectConnect.
Another option is to use the Amazon Virtual Private Gateway (VPG) to set up a VPN connection to your edge device.
I opted for the third option, which is to create a server to provide the VPN connections. The main drivers behind this decision were that we are planning on changing our edge device soon, we already use OpenSWAN to connect some of our networks, and we need to connect three different networks to AWS. I'll share a template and a script that will connect to a suitably configured OpenSWAN installation on your network, or connect to another instance in a different VPC (created with the same template).
Once the network connection is in place, add DHCP options to your VPC and you're ready to add Windows servers to your domain. I added a Read Only Domain Controller to cache DNS and authentication.
Creating the VPN
This article walks you through connecting two VPCs using OpenSWAN. You can read that for a lot of the background. I have created a template that you can get here that will set up an OpenSWAN instance for you, using parameters you provide. You can use this to connect to a VPN endpoint in your internal network, or, of course, to another instance in another VPC.In my previous post, I shared a template to create a NAT instance. There I used "UserData" to simply script the whole installation. In this template I follow a different approach (although it would have been just as easy to do it the same way). Using cfn-init and "Metadata" allows a more involved configuration, e.g. where reboots are required, such as adding a Windows server to a domain, but here, on linux, it's just another way of doing the same thing.
The template shows how to install a linux package openswan, create a number of configuration files (assembled from parameters provided), set the services to run (to make it persistent in case of a reboot) and run all the commands required to start the services.
The only resource created other than the single ec2 instance is a security group that allows access from private IP addresses (both internal and in AWS) only.
An alternative is to use "sources" instead of files. This allows you to have zipped (or tarred) files downloaded from an S3 bucket and extracted to a location you specify. This is ideal if you want to set up multiple VPN connections.
This snippet, inserted before the "files" section, will retrieve and unzip files into the /etc/ipsec.d folder
"sources" : {
"/etc/ipsec.d" : { "Fn::Join" : ["", ["https://s3-eu-west-1.amazonaws.com/",
{ "Ref" : "SourceBucket" },
"/",
{ "Ref" : "SourceFilesKey" }
]]}
},
In my github account I have a "work in progress" template that uses this.
Although I'm using this blog mostly to record, for my own purposes, things I pick up, I also find it a lot of work - none of the scripts or templates I use here end up having much in common with what I actually use in anger - all part of trying to make it work with less things already there.
Scripting the creation
As in my previous post, I use a PowerShell script to actually create the VPN using the CloudFormation template above.This should be simple, shouldn't it? Actually, if you have a look at the script, you'll notice that there's 60 lines to guess the parameters if you haven't provided them, 30 lines of "help" and really only a little bit at the end that actually creates the VPN, assign the external IP and delete the previous VPN instance if there is one.
The idea of the script is to replace an existing instance, either to update settings or because something is not working as expected, with minimal disruption of the tunnel.
Preparing for extending you AD
Once you have your VPN up and running and you have created routes on your internal network to get to your VPC, you can start putting private servers in your private subnets. This includes extending your Active Directory into your Virtual Private Cloud, should you have a reason to do so.Once you know that instances in your VPC can happily access your on site resources, you can potentially add Windows instances to your domain.
Before it's possible to add an instance to your domain, you need to make one more change. In the AWS Console, go to the VPC Management Console and DHCP Option Sets. Create a new option set with a domain name and domain name servers set to your internal DNS servers (Domain Controllers).
Once this is saved, go to "Your VPCs", select your VPC, under Actions, Edit DHCP Option set and select the newly created DHCP Option set.
You probably want to create one or two read only domain controllers (RODC) in your VPC. I've found that an RODC runs quite happily on a micro instance. Once this is running, you need to create a new DHCP option set with your RODC(s) set as the first DNS server(s) (leave your internal ones later down the list).
You're ready to start building domain joined Windows servers in AWS now.
