If you need Amazon VPC but you don’t have any piece of hardware equipment that will satisfy requirements (as described here), don’t panic! There is a solution – you can use Linux to route your traffic to Amazon VPC!
This scenario has been successfully tested and is working on following configuration:
Debian 6 with one ethernet card with public IP (no NAT), Amazon VPC network 10.0.0.0/16 with 2 subnets (10.0.0.0/24 public and 10.0.1.0/24 private), ipsec-tools 1:0.8.0-9, racoon 1:0.8.0-9, quagga 0.99.20-3
VPC components on Amazon side can be created by using Scenario number 3 (http://docs.amazonwebservices.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html) and configuration can be obtained from AWS Management console by right click on VPN configuration -> download). Also, you need to setup security groups for SSH which is also explained in Scenario3.
Example configuration files are following (change your parameters, in this example public IP is 1.1.1.1 and Virtual Private Gateways are 2.2.2.2 and 3.3.3.3, change them and other parameters accordingly):
Tunnel 1:
Pre-Shared Key : AAAAOutside IP Addresses:
|
Tunnel 2:
Pre-Shared Key : BBBBOutside IP Addresses:
|
On Debian server, we need to install following packages (as root):
$ apt-get install ipsec-tools racoon quagga
After installing packages, we need to setup following configuration files:
/etc/racoon/psk.txt:
(change secret keys to your own)
2.2.2.2 AAAA
|
/etc/racoon/racoon.conf:
(change needed addresses):
| remote 2.2.2.2 { exchange_mode main; lifetime time 28800 seconds; proposal { encryption_algorithm aes128; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } generate_policy off; } remote 3.3.3.3 { exchange_mode main; lifetime time 28800 seconds; proposal { encryption_algorithm aes128; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } generate_policy off; } sainfo address 169.254.248.10/30 any address 169.254.248.9/30 any { pfs_group 2; lifetime time 3600 seconds; encryption_algorithm aes128; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 169.254.248.14/30 any address 169.254.248.13/30 any { pfs_group 2; lifetime time 3600 seconds; encryption_algorithm aes128; authentication_algorithm hmac_sha1; compression_algorithm deflate; } |
/etc/ipsec-tools.conf
(change needed addresses):
| flush; spdflush; spdadd 169.254.248.10/30 169.254.248.9/30 any -P out ipsec esp/tunnel/1.1.1.1-2.2.2.2/require; spdadd 169.254.248.9/30 169.254.248.10/30 any -P in ipsec esp/tunnel/2.2.2.2-1.1.1.1/require; spdadd 169.254.248.14/30 169.254.248.13/30 any -P out ipsec esp/tunnel/1.1.1.1-3.3.3.3/require; spdadd 169.254.248.13/30 169.254.248.14/30 any -P in ipsec esp/tunnel/3.3.3.3-1.1.1.1/require; spdadd 169.254.248.10/30 10.0.0.0/16 any -P out ipsec esp/tunnel/1.1.1.1-2.2.2.2/require; spdadd 10.0.0.0/16 169.254.248.10/30 any -P in ipsec esp/tunnel/2.2.2.2-1.1.1.1/require; spdadd 169.254.248.14/30 10.0.0.0/16 any -P out ipsec esp/tunnel/1.1.1.1-3.3.3.3/require; spdadd 10.0.0.0/16 169.254.248.14/30 any -P in ipsec esp/tunnel/3.3.3.3-1.1.1.1/require; |
/etc/quagga/bgpd.conf:
(here you can choose your own password, and change needed addresses)
| hostname ec2-vpn password passWord enable password passWord ! log file /var/log/quagga/bgpd !debug bgp events !debug bgp zebra debug bgp updates ! router bgp 65000 bgp router-id 1.1.1.1 network 169.254.248.10/30 network 169.254.248.14/30 network 0.0.0.0/0 ! ! aws tunnel #1 neighbour neighbor 169.254.248.9 remote-as 7224 ! ! aws tunnel #2 neighbour neighbor 169.254.248.13 remote-as 7224 ! line vty |
/etc/quagga/zebra.conf:
(put password you have choosen in bgpd.conf):
| hostname ec2-vpn password passWord enable password passWord ! ! list interfaces interface eth0 interface lo ! line vty |
/etc/quagga/daemons:
| zebra=yes bgpd=yes |
After setting up configuration files, some changes needs to be done on files permissions / ownership:
| $ chmod 640 /etc/quagga/bgpd.conf $ chmod 640 /etc/quagga/zebra.conf $ chmod 640 /etc/quagga/debian.conf $ chown quagga.quaggavty /etc/quagga/*.onf $ chown quagga.quaggavty /etc/quagga/*.conf |
Also, inside IP addresses needs to be setup on interface:
| $ ip a a 169.254.248.10/30 dev eth0 $ ip a a 169.254.248.14/30 dev eth0 |
Starting services and checking:
(following is useful for racoon debugging):
| $ racoon -d -v -F -f /etc/racoon/racoon.conf |
or via init script:
| $ /etc/init.d/racoon start $ /etc/init.d/setkey start $/etc/init.d/quagga start |
Checking bgp and logs:
$ ip address $ nc localhost 2605 $ show ip bgp $ tail -f /var/log/syslog $ route -v $ ip routeBasically, after this setup, you should be able to login to your VPC instances via SSH which are in private subnet and which have routing tables towards VirtualGateway.
David, nice job we setup a debian box, hooked it all up, but our vpc instance is ip address 10.0.0.4 when we try to use the web browser in the instance the ip address 10.0.0.4 makes the DNS queries etc after it comes down the tunnel to our datacenter. How can we change the routing so when 10.0.0.4 hits our vpn router box (debian), we can MASQUERADE that IP to the ip address of said vpn router box? And of course back again?
Many Thanks,
Larry Hughes
Hello Larry,
Thank you.
With this setup, you can reach your VPC private instances from your home network and vice-verse.
But for routing further and using MASQUERADE, I am not sure if this will work since in this setup I have used only one Ethernet interface, and what I saw on the Internet regarding using one interface & masquerade, the situation is not promising:
However, I see some successful stories, too, such as:
(this is my ex-colleague btw
):
http://www.miljan.org/main/2006/12/26/linux-nat-with-one-network-interface/
I’ll try to setup this, also if you will have any success feel free to comment.
Thanks,
Using two (2) NICs is not a problem, but how would I set it up to NAT or MASUERADE 10.0.0.4 from the VPN only to the realworld?
Thanks,
Larry
David,
We can’t seem to MASQUERADE or NAT that IP Address (10.0.0.4) from the VPC instance via the vpn.
It looks like to me that bgpd and or zebra are routing directly to the Kernel and that is why I can’t NAT that address. Is there anyway to make bgpd or zebra NAT? If there is, then that would solve my issue and still only using one (1) nic?
Thanks,
Larry
Hello Larry,
Did you had any success with this?
–
Igor