Connecting to the Amazon VPC using Vyatta Community Edition
This article tries to explain how to set up VPN connectivity from your network to the Amazon VPC (Virtual Private Cloud). The Amazon Web Services cloud offering is really quite sophisticated, and it enables businesses to extend their traditional IT services to an environment with little to no financial commitment. So like most IT departments, I decided to get my feet wet in this new boom town, and I quickly realized that it would be so much nicer to manage the virtual servers and services much like I do today with all our other physical gear. The first time I tried this was almost a year ago and it really just wasn’t ready for prime time, and the options for connectivity were limited. They are still slim, but now there is a serious low cost method for extending your network into the cloud. Initially I wanted to extend connectivity to the AWS cloud using our Cisco ASA, however Amazon requires that when using that style of connectivity, that you need to exchange routes using BGP, which unfortunately wasn’t available as an option on our Cisco ASA5520. Digging around the net like usual pointed to many people that had some sort of solution working, but yet not enough information to get it working. I spent some time researching the options available, and landed on using a low cost solution using the community version of Vyatta.
What I used:
I’m going to make the assumption here, that you have your Amazon AWS account created and enabled and you also have a working VMware ESXi environment.
Amazon Virtual Private Cloud (Amazon VPC)
Amazon Virtual Private Cloud (Amazon VPC) lets you provision a private, isolated section of the Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that you define. With Amazon VPC, you can define a virtual network topology that closely resembles a traditional network that you might operate in your own datacenter. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.
You can easily customize the network configuration for your Amazon VPC. For example, you can create a public-facing subnet for your webservers that has access to the Internet, and place your backend systems such as databases or application servers in a private-facing subnet with no Internet access. You can leverage multiple layers of security, including security groups and network access control lists, to help control access to Amazon EC2 instances in each subnet.
Additionally, you can create a Hardware Virtual Private Network (VPN) connection between your corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate datacenter.
Amazon VPC Functionality
With Amazon VPC, you can:
- Create an Amazon Virtual Private Cloud on AWS’s scalable infrastructure, and specify its private IP address range from any range you choose.
- Divide your VPC’s private IP address range into one or more public or private subnets to facilitate running applications and services in your VPC.
- Control inbound and outbound access to and from individual subnets using network access control lists.
- Store data in Amazon S3 and set permissions such that the data can only be accessed from within your Amazon VPC.
- Attach an Amazon Elastic IP address to any instance in your VPC so it can be reached directly from the Internet.
- Bridge your VPC and your onsite IT infrastructure with an encrypted VPN connection, extending your existing security and management policies to your VPC instances as if they were running within your infrastructure.
Vyatta’s open, software-based approach to networking has created a complete network OS that can connect and secure physical networks as well as virtual and cloud computing infrastructures. Vyatta software and appliances offer users a flexible, affordable alternative to proprietary, hardware-based routers, firewalls, VPN concentrators and intrusion prevention devices.
Vyatta can help you:
- Affordably scale large BGP implementations
- Keep your network safe with a stateful-inspection firewall
- Securely connect remote offices with VPN
- Scale from DSL to 10-Gbps with a single software package
- Avoid costly proprietary networking upgrades
- Run virtualized networking environments in Xen and VMware
- Add networking and security to blade servers in your data center
- Offer network-based managed security services
- Add network redundancy regardless of vendor equipment
- Build your own best-of-breed Branch office solution
Get Vyatta Up and Running
You need to download the Vyatta Community edition of the software, at the time of this writing Vyatta Core 6.3 was the most recent version. It comes in ISO format, just download it and save it to your local hard disk. From there you’ll want to upload it into your VMware ESXi hosts local disk store using the Datastore Browser .
From here, you’ll want to create a simple VM of type Other 2.6 Linux (32 bit), which has 512MB RAM, 2 network interface cards, and a 4GB hard disk. One network card should be on your outside or Internet VLAN, and the inside interface card should be on your internal network. Mount the ISO that you recently uploaded to your ESXi host’s datastore and then boot up the VM. The setup should look like this:
Once the ISO boots, it becomes ready, but is in the “live CD” mode and isn’t installed on the local disk. Log in with the userid vyatta and password vyatta.
Once logged in, type the following:
For the most part, all you need to do is accept the default answers and it will install it to the local hard disk you created.
Shut down the VM, unmount the ISO from the the vSphere Client and boot it back up.
Now you’ll want to configure the most basic network configuration so that you will be able to SSH into it and manage it outside of the vSphere Client.
Log in again using vyatta/vyatta, in my case eth0 is my external interface on the Internet, and eth1 is my internal interface. The following will be different for your situation, but here is what you need to do to get basic connectivity going:
configure set interfaces ethernet eth0 address 184.108.40.206/27 set interfaces ethernet eth1 address 10.1.12.200/24 set protocols static route 0.0.0.0/0 next-hop 220.127.116.11 set protocols static route 10.1.0.0/16 next-hop 10.1.12.1 set service ssh commit save exit
What I’ve done here is assigned the IP addresses to both the internal and external interfaces, set the default route to be our Internet router, and then routed our internal private address space at our internal router. I’ve also enabled the SSH service so you can now access it from something like a Putty SSH client.
Ok, so now SSH into it, your route table should look something like:
# ssh firstname.lastname@example.org Welcome to Vyatta email@example.com's password: Linux vyatta 2.6.37-1-586-vyatta-virt #1 SMP Thu Jul 7 22:30:24 PDT 2011 i686 Welcome to Vyatta. This system is open-source software. The exact distribution terms for each module comprising the full system are described in the individual files in /usr/share/doc/*/copyright. Last login: Tue Jan 17 22:23:18 2012 from 10.1.12.30 vyatta@vyatta:~$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 18.104.22.168 0.0.0.0 UG 0 0 0 eth0 10.1.0.0 10.1.12.1 255.255.0.0 UG 0 0 0 eth1 10.1.12.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 22.214.171.124 0.0.0.0 255.255.255.224 U 0 0 0 eth0 vyatta@vyatta:~$
So at this point, the basics are there, and we can move onto the Amazon AWS VPC side of things.
Get VPC Up and Running
Before we start, here is a very simple network diagram to help explain things a little:
The next step is to get the Amazon side of things going. Log into your AWS Management Console and select the VPC tab. I’m going to keep things super simple here, I’ll be creating a VPC with Private Subnet Only and Hardware VPN Access.
I used these values:
Customer gateway, use the Internet or public IP address that you assigned to eth0, in my case 126.96.36.199
One VPC section I am using: 10.20.0.0/16
One Subnet section I am using 10.20.1.0/24
It should look like this:
Hit the Create VPC button.
When completed, it will prompt you to Download Configuration, click the button.
For the Vendor, select Generic
This should save a text file to your computer using a filename something like vpn-0f90c14a.txt. You will need this to convert it to Vyatta configuration format. To do the conversion, I found a great little website on the net, and it was just awesome for doing all the heavy lifting, here is the URL you need to navigate to:
Once there, for the IPSEC interface value, use eth0.
For Your Private network, use the network you chose for your internal network on eth1, in my case it was 10.1.12.0/24
For the VPC IP CIDR block, you use the /16 that was defined when you created the VPC in the AWS Management Console. In my case 10.20.0.0/16
Open up the text file you saved, and cut and paste all the text into the section that asks for the Configuration of Generic Customer Gateway, and hit the Generate button.
You will then need to save the Configuration for Vyatta information. I just copied it into my clipboard, and created a file using vi in the Vyatta SSH session.
I saved my file as /home/vyatta/vpc_config.txt and you can get it here: vpc_config.txt.
Now from the SSH prompt type the following:
configure merge /home/vyatta/vpc_config.txt commit save exit
Hopefully at this point, the Vyatta VPN subsystem will start up the connection to the Amazon VPC. You can validate PHASE_1 or IKE on the Vyatta system, by doing the following:
show vpn ike sa
This should show you if you have IKE security associations:
vyatta@vyatta:~$ show vpn ike sa Peer ID / IP Local ID / IP ------------ ------------- 188.8.131.52 184.108.40.206 State Encrypt Hash D-H Grp NAT-T A-Time L-Time ----- ------- ---- ------- ----- ------ ------ up aes128 sha1 2 no 1015 28800 up aes128 sha1 2 no 284 28800 Peer ID / IP Local ID / IP ------------ ------------- 220.127.116.11 18.104.22.168 State Encrypt Hash D-H Grp NAT-T A-Time L-Time ----- ------- ---- ------- ----- ------ ------ up aes128 sha1 2 no 992 28800 up aes128 sha1 2 no 283 28800 vyatta@vyatta:~$
So now we have our PHASE_1 IKE SA’s, lets check for the IPSEC SA’s now
show vpn ipsec sa
It should look something like:
vyatta@vyatta:~$ show vpn ipsec sa Peer ID / IP Local ID / IP ------------ ------------- 22.214.171.124 126.96.36.199 Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto ------ ----- ------------- ------- ---- ----- ------ ------ ----- 1 up 1.9K/1.9K aes128 sha1 no 1059 3600 all 2 up 0.0/0.0 aes128 sha1 no 849 3600 all Peer ID / IP Local ID / IP ------------ ------------- 188.8.131.52 184.108.40.206 Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto ------ ----- ------------- ------- ---- ----- ------ ------ ----- 1 up 1.7K/1.6K aes128 sha1 no 1129 3600 all 2 down n/a n/a n/a no 0 3600 all vyatta@vyatta:~$
Notice that the second tunnel on peer 2 is down, this is ok and expected, Amazon has you create two VPN connections to them for when they do their system maintenace.
Ok, lets make sure our BGP peer is also established:
show ip bgp summary
It should look something like:
vyatta@vyatta:~$ show ip bgp summary BGP router identifier 220.127.116.11, local AS number 65000 RIB entries 1, using 64 bytes of memory Peers 2, using 5048 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 169.254.253.17 4 7224 143 144 0 0 0 00:02:23 0 169.254.253.21 4 7224 142 143 0 0 0 00:02:20 0 Total number of neighbors 2
Fix the Gotcha
Before you go and spin up a server instance in your newly configured VPC, you will have to resolve a small little gotcha. It took me a while, as when I first did this, I could NOT talk to the other side. The Amazon VPC is configured for tunnel mode and will only encrypt packets for networks that it learns from the BGP route exchange. In this above default case, your internal network subnet of 10.1.0.0/16 is not allowed to speak to 10.20.0/16 yet because you haven’t announced that route via BGP. You can see this by typing the following:
show ip bgp neighbors 169.254.253.17
It returns the following information:
vyatta@vyatta:~$ show ip bgp neighbors 169.254.253.17 advertised-routes BGP table version is 0, local router ID is 18.104.22.168 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0 169.254.253.18 0 32768 i Total number of prefixes 1 vyatta@vyatta:~$
You will notice that we are only announcing a default route, which in our case won’t allow any VPC instance to talk back to us on the internal network of 10.1.0.0/16 and in our very specific case 10.1.12.0/24. To correct this, you will need to do the following:
configure set protocols bgp 65000 network 10.1.0.0/16 commit save exit
Now when we have a look at the advertised routes, we should see our internal network being advertised to the Amazon VPC VPN.
show ip bgp neighbors 169.254.253.17 advertised-routes
It returns the following information:
vyatta@vyatta:~$ show ip bgp neighbors 169.254.253.17 advertised-routes BGP table version is 0, local router ID is 22.214.171.124 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0 169.254.253.18 0 32768 i *> 10.1.0.0/16 169.254.253.18 0 32768 i Total number of prefixes 2 vyatta@vyatta:~$
From the Amazon Management Console, if you select the VPC tab an then click the VPN Connections link on the left it should look something like:
Spin up your first instance in your VPC
Now it’s time to get something running on the other side, this blog posting assumes you already know how to do this, so I’ll show you what to expect. Select the EC2 tab in your AWS Management Console and click the Launch Instance button:
I’m just going to pick something simple to demonstrate connectivity:
We’ll just use a 32bit basic Amazon Linux instance:
Amazon makes a “small” instance the minimum for launching in a VPC, so you’ll need to use at least that size, also you will need to select the VPC radio button and choose the subnet to be used for the instance.
The defaults are fine for the next screen as we are just using this for demonstration purposes. If you leave the IP address blank, Amazon provides the instance with an IP from that subnet via DHCP.
Just click continue on the next screen:
And finally choose your Key Pair and click continue:
For this example, the Security Group defaults are fine as well, so click continue:
Ok, you should be ready to Launch:
Once the instance has spun up, you should be able to see that it is inside your new VPC and has been assigned an IP address out of the VPC subnet you previously defined.
Now you should be able to connect to it via SSH:
vyatta@vyatta:~$ ssh -i vantagemedia-west.pem firstname.lastname@example.org __| __|_ ) _| ( / Amazon Linux AMI ___|\___|___| See /usr/share/doc/system-release/ for latest release notes. [ec2-user@ip-10-20-1-244 ~]$
Adjusting the Security Group
One thing you may choose to do, is enable PING to work, and to do so, you would need to modify the Security Group. Go to your EC2 tab, select Security Groups on the left, and highlight the quick-start-1 security group that you created above. Down below, you should select the Inbound tab, and add a Custom ICMP rule, where the Type is Echo Request and the Source is 10.1.0.0/16. Click Add Rule, and click Apply Rule Changes:
You should now be able to ping the instance.
vyatta@vyatta:~$ ping 10.20.1.244 PING 10.20.1.244 (10.20.1.244) 56(84) bytes of data. 64 bytes from 10.20.1.244: icmp_req=1 ttl=62 time=10.7 ms 64 bytes from 10.20.1.244: icmp_req=2 ttl=62 time=10.7 ms 64 bytes from 10.20.1.244: icmp_req=3 ttl=62 time=10.7 ms ^C --- 10.20.1.244 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 10.710/10.743/10.783/0.123 ms vyatta@vyatta:~$