Saturday, 8 November 2014

Configuring Openswan as our VPN

Configuring Openswan as our VPN

This document outlines how we configure openswan as our VPN.

We got a some tips from this blog - but its not complete:

http://michaelwasham.com/2013/09/03/connecting-clouds-site-to-site-aws-azure/

1. Create a VPC in AWS (i gave it 10.0.0.0/16 as the VPC CIDR)

2. Launch an ubuntu instance into the new VPC.

3. Make sure theres a public ip address available. ours is xxx.xxx.xxx.xxx (your public ip)

4. Head to Azure and create a Local Network (Local Network in this case means the network on your local site.) So its Networks - Local Networks - New - Give it the CIDR from the VPC in AWS, and put in the VPN ip address (our public ip address of our ubuntu server)

5. Now to create a new Virtual Network (this is the Azure side of the network). Networks - Virtual Networks - New - Network Services - Virtual Network - Custom Create. Give it a name (mine is AzureNetwork), Hit Configure a Site to Site VPN and select the Local Network you've just created in step 4. You'll need to add a gateway network as well.

6. After thats built go into your vpn and click add gateway. It will give the public ip address of the gateway in azure. This takes a little while to complete. (its create gateway - static route)

7. Now head back to your ubuntu server in aws. Its time to configure this. Heres the command to install it:

sudo apt-get install openswan

Just press enter to accept all the defaults for all the questions it asks.

8. Edit ipsec.conf:

cd /etc
sudo vi ipsec.conf

change the config file to be this:

config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.0.0.0/16
      oe=off

include /etc/ipsec.d/*.conf

This sets the default protocol to be netkey. it should default to this anyway.
the virtual_private is the CIDR in AWS (the local part of the vpn as set in step 1)

save that.

9. create a new vpn conf file

cd ipsec.d
sudo vi amazonazurevpn.conf

change the config file to this:

conn amazonazurevpn                      
   authby=secret
   auto=start
   type=tunnel
   left=10.0.0.238                        (this is the private ip address of the openswan server)
   leftsubnet=10.0.0.0/16            (this is the CIDR of the network in AWS-left is local, right is public)
   leftnexthop=%defaultroute
   right=xxx.xxx.xxx.xxx                  (this is the ip address of the gateway which was created in azure)
   rightsubnet=10.1.0.0/16           (this is the CIDR of the virtual network created in azure)
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no

Save that.

10. We need to use the key in the ipsec.secrets file:

cd /etc
sudo vi ipsec.secrets

Add the following line:

10.0.0.238 xxx.xxx.xxx.xxx : PSK "Azure Gateway Key"

(10.0.0.238 is the private address of the openswan server)
(xxx.xxx.xxx.xxx is the gateway address in azure)
"Azure Gateway Key" is the key from the gateway in azure. You can get this by clicking on manage key. Put it in quotes.

Save that.

11. Need to enable ip forwarding now.

sudo vi /etc/sysctl.conf

uncomment this line:

net.ipv4.ip_forward=1

save that

apply the saved config:

sudo sysctl -p /etc/sysctl.conf

12. Disable source and destination checking on the openswan server (right click on it in aws, select "Change source/dest check" and click 'Yes - Disable"

13. In the Amazon Management console, in AWS, edit the security group and add in 2 inbound udp rules, one for 500 and one for 4500, from a specific ip address - the azure gateway - with /32 at the end:xxx.xxx.xxx.xxx/32

14. Restart ipsec on the openswan server:

sudo service ipsec restart

15. Thats it. The VPN should now be configured. You can do some troubleshooting on the openswan config by looking here:

http://codeidol.com/unix/linux-fix/Configuring-Linux-VPNs/Troubleshooting-Openswan/

16. We need to add a route to AWS to point to the network in Azure:

Go to VPC in AWS, select Route Tables and add in the subnet of the virtual network in azure (10.1.0.0/16). Select the id of the openswan server as the target.

17. Now we just need to launch instances in each of azure and aws, onto the networks that we've created in each.

And guess what - they dont ping. 

At this point i've rebuilt and restarted and reconfigured and tried different things to get this vpn up and running for three weeks. Today, i got them to ping. so the final action:

18. Open up icmp traffic on the inbound rule on the security group in AWS. Then they'll ping. You can see the openswan passing the icmp traffic by running a tcpdump on there:

sudo tcpdump -n -i eth0 icmp

So thats it. Now we have our VPN (although i'm going to rebuild it again - and assign an elastic ip to the openswan server - as that absolutely needs a static ip)

Making good progress this week.

Next - scripts to Check what capacity we're using.

Richie

Deleting an Azure VM

Deleting an Azure VM

Add the creds:

Add-AzureAccount

Need to stop the one we created yesterday first:


Stop-AzureVM -ServiceName richiescloud -Name richiesubuntu -Force

Successful. Now to delete it and its disks as well:

Remove-AzureVM -ServiceName richiescloud -Name richiesubuntu -DeleteVHD

Successful as well. Sweet.

Thats how to delete an azure vm.

Now we have scripted deploying and deleting vms in both azure and aws. Now need to figure out how to find out what capacity our clouds are using, so we can script automatic deployments based on how much capacity is available in our private cloud.

Richie



Friday, 7 November 2014

Deploying in Azure using Powershell

Deploying in Azure using powershell

This is going to outline how to deploy in Azure using powershell.

Load up Powershell ISE.
Get-AzureAccount to see do i still have my creds there. I do of course. Sweet.

Lets see what images they have to deploy.

Get-AzureVMImage

Whoops - asking me for creds again Add-AzureAccount - enter my creds and we're in again.

Get-AzureVMImage again


I'll be deploying an ubuntu image. I want the newest one (14.04). Lets see what ubuntu ones are there:

Get-AzureVMImage | Where ImageName -Match "Ubuntu" | sort PublishedDate

Theres still loads of results.

Get-AzureVMImage | Where ImageName -Match "Ubuntu-14.04" | sort PublishedDate | Select ImageName -First 1

This brings back one. The latest one. Nice one. So i'll set that as a variable:

$image = Get-AzureVMImage | Where ImageName -Match "Ubuntu-14.04" | sort PublishedDate | Select ImageName -First 1

I'm creating an affinity group. I can script that:

New-AzureAffinityGroup -Name Dublin -Location "North Europe"

And a storage account. I can script that too (make sure the storage account name is all lowercase chars):

New-AzureStorageAccount -StorageAccountName richiesstorageaccount -AffinityGroup Dublin

Need to associate our subscription:

Set-AzureSubscription -SubscriptionName (Get-AzureSubscription).SubscriptionName -CurrentStorageAccountName (Get-AzureStorageAccount -StorageAccountName richiesstorageaccount)

And a new Cloud Service:

New-AzureService -ServiceName richiescloud -AffinityGroup Dublin

I'm creating a variable for some vm options like the size, the user id and password i set on the ubuntu server, and the subnet:

$vm = New-AzureVMConfig -Name richiesubuntu -InstanceSize small | Add-AzureProvisioningConfig -Linux -LinuxUser richie -Password testvm | Set-AzureSubnet -SubnetNames VMNetwork



So i had a couple of issues with the syntax - sorted now though. Successful deployment. Heres the script:

Set-AzureSubscription -SubscriptionName (Get-AzureSubscription).SubscriptionName ` -CurrentStorageAccountName (Get-AzureStorageAccount).Label -PassThru
$image = Get-AzureVMImage | Where ImageName -Match "Ubuntu-14.04" | sort PublishedDate | Select ImageName -First 1
$vm = New-AzureVMConfig -Name richiesubuntu -ImageName $image.ImageName -InstanceSize Small | Add-AzureProvisioningConfig -Linux -LinuxUser richie -Password Testvm01 | Set-AzureSubnet -SubnetNames VMSubnet
New-AzureVM -VMs $vm -ServiceName richiescloud -VNetName RichieNetwork -WaitForBoot



Line 1 = Set the subscription
Line 2 = the image details
Line 3 = the image configuration
Line 4 = the deployment.

Thats me done for tonight.

Tomorrow i'll be scripting a termination, and a bit of capacity reports or something like that from aws. See if i can throw a couple of these scripts together and let the script decide where we need to deploy the servers.

Richie




Thursday, 6 November 2014

Deploying in AWS using powershell

Deploy in AWS

This blog post is going to outline the trials and tribulations of getting a script working to deploy an AWS server. Fun and Games.

1. Set the region. We're currently using oregon which has our openswan server. So - Get-EC2Image -Region us-west-1

access denied. Into IAM - set up 'Richie' as a power user.

Access is working, but the script had returned 62000 lines before i cancelled it.

So we know we can connect. Make it the default region:

 Set-DefaultAWSRegion us-west-1

If we want to change to ireland as our default, then:

Clear-DefaultAWSRegion will get rid of the default.

2. Deploy an instance. The command is New-EC2Instance. Lets do it:

New-EC2Instance

here are the variables:

-ImageId is the image id. Windows 2008 server ami-e5f7bbd5

-MinCount and -MaxCount are the minimum and maximum no of instances to run (1 in each case)

-InstanceType t2.micro (we want the free one)

Heres the command:

New-EC2Instance -ImageId ami-e5f7bbd5 -MinCount 1 -MaxCount 1 -InstanceType t2.micro

but wait - i'll add in a variable because using that image id is a pain. I can get the actual name of it.

$ami = Get-EC2ImageByName Windows_2008_Base
New-EC2Instance -ImageId $ami.ImageId -MinCount 1 -MaxCount 1 -InstanceType t2.micro

lets see what happens. Into powershell ise and run the script.

Oops - turns out us-west-1 is California - not Oregon.  It deployed though.

PS C:\Users\Richie> $ami = Get-EC2ImageByName Windows_2008_Base
New-EC2Instance -ImageId $ami.ImageId -MinCount 1 -MaxCount 1 -InstanceType t2.micro


GroupNames    : {}
Groups        : {}
Instances     : {}
OwnerId       : 227910012278
RequesterId   : 
ReservationId : r-7e0d7020

Now to terminate it.

Stop-EC2Instance -Instance i-031762c9 -Terminate -Force

-instance was the instance name it created.
-Terminate means we're terminating it.
-Force means it doesnt come back with 'are you sure'

Sweet - its terminated.

Happy days - successful deployment and termination. I'll leave that now for today. Tomorrow - Azure deployments and terminations, and then maybe a bit more automation and detection.

Richie.





Setting up powershell for Azure and AWS

Setting up AWS and Azure powershell modules to automatically load:


1. Add the modules to powershell:

Add:

Import-Module "C:\Program Files (x86)\AWS Tools\PowerShell\AWSPowerShell\AWSPowerShell.psd1"
Import-Module "C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1"

into the powershell profile.

2. Add AWS credentials - outlined here:
 http://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html

I set the key. looks like we should come up with a process for changing this periodically and document it. process should be:

       1. Go into users - manage access keys
       2. Download the new secret key
       3. Run

Set-AWSCredentials -AccessKey myaccesskey -SecretKey mysecretkey -StoreAs default

replace myaccesskey and mysecretkey with the keys downloaded from IAM.

Also it might be a good idea to separate the roles. One role for deploying servers, but you cannot 'remote control' the server, and the 'remote control' user cant deploy. (separation of duties)


AWS Credentials added.

3. Add Azure credentials - outlined here:
http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/#Install

Run Add-AzureAccount - and it brings up an azure logon screen. Enter your credentials and then powershell is now holding your azure account information.

the Azure credentials is easier - but its using an AD account, and the scripts contain your password in free text (although you can set them to trasmit encrypted). might be worth doing the certificate method instead.

1. Run Get-AzurePublishSettingsFile
2. Run Import-AzurePublishSettingsFile
3. Delete the publishsettingsfile you had downloaded (recommended as a security precaution by microsoft)

Now - Get-Azure Account will confirm you're ready to go.



Credentials for connecting to both our private and public cloud are ready to go.

4. Add it into Powershell ISE profile as well (a different profile). PowershellISE though - Get-ExecutionPolicy is restricted of course - because its a security risk to run untrusted scripts. Set it to RemoteSigned (Set-ExecutionPolicy RemoteSigned)
(you dont need powershell ISE - i use it because its easier to script with)



Next step - Scripting deployments.

Wednesday, 5 November 2014

Docs for cloud scripting

Looking at configuring our Azure scripts and AWS scripts.

Getting our credentials setup on each of the scripting tools:

http://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingCredentials.html

http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/

powershell for aws:

http://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html

Tuesday, 4 November 2014

VPNs

So we spent the last week trying to get different flavours of VPN setup. not so easy when we are getting access denied on everything in AWS, which is scuppering a lot of work.

I was attempting to get Openstack running with openswan on ubuntu, and windows 2008 r2 RRAS, and then windows 2012 RRAS in an attempt to open a vpn between envs.

Struggled to do it from openstack as I couldnt configure an internet-facing ip to allow the vpn to run.

However, i learned a lot about the different configs and options for vpns over the last week.


So heres what happened yesterday (3rd November)

We finally decided that our hybrid cloud would be AWS as our primary cloud and Azure as our secondary.

We did up a project plan outlining the tasks required to get us to our goal.

Then we went about setting up our vpn (openswan) from AWS VPC (virtual private Cloud) to Azure.

We threw the openswan environment together quickly (must have done it about 20 times now at this stage), but we never recreated the azure site-to-site connection on the virtual networks (it takes a while to create the gateway), so never got the vpn up and running last night.

Jeff recreated the azure virtual network this morning, and lo and behold, our clouds are connected!

So openswan is working for us. We'll leave it at that and maybe research some other options for the VPN, such as openvpn or Windows RRAS. However, we're going to document our work so far.

We have our document structure as well so we're going to update that now as we go.

We have a couple more tasks now to get through, like provisioning, monitoring and orchestration in both AWS and Azure, but its good to have our clouds connected.

Lets see what tomorrows tasks brings.


Richie