Connect two AWS regions with StrongSwan


Posted by Peter Nijssen

Connect two AWS VPCs with StrongSwan

If you want to connect two VPCs within the same region in AWS, you can use VPC peering. AWS unfortunately has no option yet to connect two VPCs in different region with each other.

Within this article we will be connecting two regions through two StrongSwan instances. This article is inspired by the following two blogs, which might help you when getting stuck.

Preparing your VPCs

It's important that both your VPCs are on a different CIDR block. You can read my previous article to set up a VPC with your own CIDR block.

For this article I created a VPC in Ireland with CIDR block 10.0.0.0 and a VPC in Frankfurt with CIDR block 10.10.0.0.

Creating two EC2 instances

In each region you can create an EC2 instance. I decided to go with CentOS 7 machines on a t2.micro instance. When you are going to deal with high traffic between both regions, you might want to pick a bigger instance.

I named the server in Ireland "Callisto" and the server in Frankfurt "Ganymede". Both names are moons of Jupiter.

After you created both machines, make sure to disable source / destination check from the action menu on both.

Disable Source/Destination Check

Before continuing, please make sure that for both machines;

  • You have SSH access
  • Source/Destination checks are disabled
  • Have a public accessible IP

Collect information

Now we should gather some information from both machines. You should get the public and private IPs of both machines as well as the VPC CIDR block.

In my case, this is the configuration.

Callisto

  • public IP: 52.213.124.101
  • private IP: 10.0.1.198
  • VPC CIDR Block: 10.0.0.0/16

Ganymede

  • public IP: 35.156.123.101
  • private IP: 10.10.1.126
  • VPC CIDR Block: 10.10.0.0/16

Installing and configuring StrongSwan

Connect with both your machines through SSH and run the following commands to install StrongSwan.

yum install epel-release
yum install strongswan

Now we need to edit the StrongSwan configuration on both machines.

vi /etc/strongswan/ipsec.conf

Callisto

config setup
  strictcrlpolicy=no
  charondebug=all
conn %default
  ikelifetime=60m
  keylife=20m
  rekeymargin=3m
  keyingtries=1
  keyexchange=ikev2
conn Ganymede
  authby=secret
  auto=start
  type=tunnel
  left=10.0.1.198
  leftid=52.213.124.101
  leftsubnet=10.0.0.0/16
  leftauth=psk
  right=35.156.123.101
  rightsubnet=10.10.0.0/16
  rightauth=psk
  ike=aes128-sha1-modp1024
  esp=aes128-sha1-modp1024

Ganymede

config setup
  strictcrlpolicy=no
  charondebug=all
conn %default
  ikelifetime=60m
  keylife=20m
  rekeymargin=3m
  keyingtries=1
  keyexchange=ikev2
conn Callisto
  authby=secret
  auto=start
  type=tunnel
  left=10.10.1.126
  leftid=35.156.123.101
  leftsubnet=10.10.0.0/16
  leftauth=psk
  right=52.213.124.101
  rightsubnet=10.0.0.0/16
  rightauth=psk
  ike=aes128-sha1-modp1024
  esp=aes128-sha1-modp1024

The only differences between both, are the settings named left and right. (L)eft means (L)ocal and (R)ight means (R)emote. The IP addresses and CIDR blocks we have collected earlier, have been filled in here.

We secure the connection between both machines with PSK. Therefor we have to set the PSK for both machines.

vi /etc/strongswan/ipsec.secrets
52.213.124.101 : PSK "Dl8EDinVF8L0Y2Ot7GbSWlby9D1vDkVB3d4nxV1dQmGeM137xgF3KhQ4CQC8hXGu"
35.156.123.101 : PSK "tLWF8SOmOR6auWakESBe1GHQAYC8PB9Uvb2rfqUbJywamLEcGkYUG8F7s21X1le0"

Finally we have to configure port forwarding on both machines. Add the following line to /etc/sysctl.conf.

net.ipv4.ip_forward=1

Run the following command.

sysctl -p

We are done installing and preparing StrongSwan. All that is left to do, is to configure some security groups and routing with AWS.

Setting routing and security groups

Head back to the VPC settings within AWS. Head down to the route tables and add a new one and give it any name or change an existing one.

Now edit the routes for this route table. Add a new route from the foreign CIDR block to your StrongSwan instance. We will make sure that any requests to the foreign subnet are being redirected to our StrongSwan instance.

Ireland

Route Ireland to StrongSwan

Frankfurt

Route Frankfurt to StrongSwan

Finally we have to set a security group in both VPCs and assign it to our StrongSwan instances. You should allow port 4500 and 500 on UDP from the foreign public IP.

Ireland

Security Group Ireland

Frankfurt

Security Group Frankfurt

Start the connection

We can now start StrongSwan on both machines.

strongswan start

When you run strongswan status you will notice both machines have a connection established.

Security Associations (2 up, 0 connecting):
    Ganymede[2]: ESTABLISHED 0 seconds ago, 10.0.1.198[52.213.124.101]...35.156.123.101[35.156.123.101]
    Ganymede{2}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: ccf10c8c_i c09f3c5a_o
    Ganymede{2}:   10.0.0.0/16 === 10.10.0.0/16
    Ganymede[1]: ESTABLISHED 2 seconds ago, 10.0.1.198[52.213.124.101]...35.156.123.101[35.156.123.101]
    Ganymede{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cd2ec7d9_i c0861342_o
    Ganymede{1}:   10.0.0.0/16 === 10.10.0.0/16

Note: If you want more detailed information, run strongswan statusall

Before going into production

Before you plan to bring this in production, please note that it is advised to use an Elastic IP. Since both are connecting through their public IP, you don't want this to changed during a reboot.

Additionally you want to make sure that StrongSwan starts on boot and it keeps running.

Within this article we connected two AWS regions with two StrongSwan instances. You should now be able to connect from any instance in your Ireland region to the Frankfurt region and the other way around.

Troubleshooting

If you have issues establishing the connection, there are a couple of things you can check;

  • Did you disable source/destination checking?
  • Did you change the route tables to run traffic to the foreign subnet to your StrongSwan instance?
  • Did you configure the StrongSwan instances correctly? Check the IP configurations.
  • Did you create and assign the security groups to the right instances?
  • Did you configure the keys on both sides? You can reload the keys with strongswan rereadsecrets

7 Comments

avatar
Hi Peter Nijssen,
It helped lot thanks for sharing.
I have a question about i able to communicate with public ips but if i communicate with private ips how can i do that.
suppose like Frankfurt region vpc(10.0.0.0/16) should talk ireland region VPC(192.168.0.0/16)
avatar
Hi Pawan,

The 2 strongswan instances can only communicate through public ips with each other. Afterwards they can just continue the traffic across private ips in their own network. Hope that helps, else drop me an email.
avatar
Thanks for sharing this. Following these steps, I managed to connect both strongswan instances in two separate VPC, but I couldn't get pinging from the same instances to the other one. What could be wrong?

I had to use a vti tunnel to do it
avatar
Hello Miguel,

I had the same problem with the only difference I actually had one connection established showing on each side. See the following output:

openvpnas@IrelandVPN:~$ sudo ipsec status
------
openvpnas@VirginiaVPN:~$ sudo ipsec status
Security Associations (1 up, 0 connecting):
Security Associations (1 up, 0 connecting):

In the logs I get - amongst others - a what it seems to be a problem:

Oct 5 14:11:34 localhost charon: 03[KNL] querying policy failed: No such file or directory (2)
Oct 5 14:11:34 localhost charon: message repeated 3 times: [ 03[KNL] querying policy failed: No such file or directory (2)]
Oct 5 14:11:34 localhost charon: 03[IKE] sending DPD request
Oct 5 14:11:34 localhost charon: 03[ENC] generating INFORMATIONAL_V1 request 4259345804 [ HASH N(DPD) ]
Oct 5 14:11:34 localhost charon: 03[NET] sending packet: from 10.3.1.41[4500] to <EIP>[4500] (92 bytes)
Oct 5 14:11:34 localhost charon: 04[NET] received packet: from <EIP>[4500] to 10.3.1.41[4500] (92 bytes)
Oct 5 14:11:34 localhost charon: 04[ENC] parsed INFORMATIONAL_V1 request 2298990019 [ HASH N(DPD) ]

I've configured the security groups and the routes, but still there's no connectivity. I cannot even ping. I tried to get a tcpdump and it seems that the ICMP packet never reaches the other end.
How did you go about it? What do you mean by 'use a vti tunnel'? Why isn't the solution outlined above enough? I'd appreciate it if you could elaborate on it.
avatar
Hi,

It's hard to really say what your issue is. I tried the above article a month ago and it still worked all fine. Did you disable the source/destination check? I am using strongswan status (see the article) btw to figure out what the status is. What version of strongswan are you using anyway? I am on 5.5.x or higher.
avatar
Hello Peter,

Thanks for the quick reply. Much appreciated

It appears I'm using 5.3.5. See below. Do you believe that could be an issue?

openvpnas@IrelandVPN:~$ sudo ipsec version
Linux strongSwan U5.3.5/K4.4.0-96-generic
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.
openvpnas@IrelandVPN:~$

So you didn't use any VTI tunnel. Ok, that's good to know. I play around with the config once more.
One further question (in case i figure out what the issue is). Do you consider it as a stable and reliable solution? I mean can a business rely on this approach to connect servers used to run its business on a daily basis?
Is there any known limitation (eg bandwidth or data transferred over the tunnel etc)? I had a look at the logs and they are really hard to demistify which makes me a bit concerned in the event of troubleshooting if anything goes wrong
Thanks again for your prompt response

BRs
avatar
I didn't no. I just followed the article. did you see the 2 articles mentioned at the top? Maybe it helps out.

I am using this in business, connecting 3 locations together. I am using t2.micro instances I believe. Every minute a monitoring tool is going through the connection to see if everything is still up and running, commands are being pushed through, etc. I even threw database dumps over the lines without problems. I think it can depend on the instance type etc that you choose. Some do some network throttling I believe.

I know that AWS has also some VPC peering I believe. I am not sure, but perhaps these days you can connect two regions with AWS itself, rather then setting up your own servers.

I am not sure if the version could be the issue. I just never tried with that version. But StrongSwan is definitely hard to understand.

Feel free to also drop me a line through the contact page over here.