Part 3 :: Establishing site-to-site VPN between OpenSwan And VyOS

Hello Guys

Welcome to the final part of our series on establishing a VPN between Azure and AWS using Openswan and VyOS. This is where the real thing happens. I know if you were like me , you would already be itching to dive into the subject ASAP. Your prayers have been answered. Below is what’s about to go down 😀

• Fill the site-to-site Form
• Firewall Rules
• Route Table Rules
• configure Openswan
• configure VyOS
• Test Connectivity

Fill the site-to-site Form

Here is a mere formalization that you see more and more in the corporate world where a Company A will send to Company Z a form to be filled where all the specifications about the VPN is captured. Let’s simulate one ourselves. Our Company A is AWS and Company Z is Azure. Here is a VPN form of our project.

Basically we will have:

Azure endpoint: 52.168.163.62
Aws endpoint: 34.204.104.232

Phase 1

encryption algorithm: aes-256
hashing algorithm: sha1
main mode: yes
DH: group 2
ikelifetime: 3600s

Phase 2

encryption algorithm: aes-256
hashing algorithm: sha1
Perfect Forward Secrecy : yes
salifetime: 1800s

VPN Access

Azure encryption domain: 10.10.0.5:8888
AWS encryption domain: 172.20.0.10:80/172.20.10.5:8080

Let’s set up firewall Rules

Azure

OpenSwan Firewall

To allow ipsec connection (ISAKMP) we need to open UDP port 500 and to allow ipsec NAT traversal we need to open UDP and TCP 4500 for VyOS endpoint :34.204.104.232

Application Box Firewall

As per VPN form , we need to allow traffic from 172.20.0.10 and 172.20.10.5 to the application box with IP 10.10.0.5 on port 8888

Allowing traffic between the openswan box and its side kick application box is important here. Fortunately for us, we won’t need to write any rule there as Azure default “hidden” rule already allow inbound vnet any to any traffic. To view default rules, click on Default rules beside the “+Add” button

AWS

VyOS Firewall

Similarly to azure, we needed to allow ipsec connection and nat traversal on UDP 500 and TCP/UDP 4500 for openswan IP 52.168.163.62

Codingpains application 1 and 2 Firewall

Here as well we needed to allow access on ports 80 and 8080 to our azure app box 10.10.0.5

It’s also important here to allow traffic from the vyos box to flow to the app box and vice versa. Generally I allow all traffic and in aws, we are allowing any box with the same Security groups as the VyOS one to send any traffic to the app box.

We are doing the reverse as well allowing any box with the application sec group to send to the VyOS.

Route Table Rules

This part is more of showing the way to our packets. Since our azure vnet is 10.10.0.0/16, packets to anything within that ip range know very well how to go about but not when they are asked to to go IPs falling under 172.20.0.0/16(AWS subnet). So we need to show the way on how to get there. Same way for amazon 172.20.0.0/16, we need to show the way to 10.10.0.0/16. We could do that on each boxes involved here but that will become very quickly a bad idea when a lot more boxes are involved. So we will do this at a networking or subnet level.

Azure

Let’s create a route table and add the rules to it. Like in part 2 we can just do a search for route and create the route table like shown below. I gave it the name road-to-aws

Let’s create a route to both aws public and private subnets. You can use either an IP or a full subnet, since this is the only VPN we will be creating I just use the networks instead. I will show how to create the rule for aws public subnet only then the rest would be self explanatory.

When done the route table should look the like the table below

Before the routes become effective, we need to assign it to our azure subnet. If we have had a node inside the private subnet we would have used the same rules. But let’s assign it to the public subnet (default) only. To do that, locate your vnet, look for the subnets, choose the actual subnet and choose the route table like shown below

AWS

In AWS we have already created the route tables, let’s go ahead and edit them with new routes. Basically the same rule for both public and private route table

configure Openswan

Let’s start the configuration by making sure the /etc/ipsec.conf file has the lines shown below

Now let’s configure our connection in /etc/ipsec.conf let’s make sure we have our connection similar to what’s below using your own IPs etc of course. Usually left side is where we are and the right side is the other side of the VPN. For example since we are connecting to openswan on azure. Left is openswan or azure and right it vyos or aws.

Once that’s done let’s put in our secret /etc/ipsec.secrets and restart openswan .

Type sudo service ipsec restart to restart openswan, you will notice that it will throw an error like:

“/var/lib/openswan/ipsec.secrets.inc” line 1: error loading RSA private key file

I can’t remember what the issue it but have done some search about it and here was the cure. Rewrite the private key to be of the pem format

configure VyOS

Let’s start VyOS configuration, those using Juniper should feel at home

Checking what’s happening at the log level. I smiled at the sight of “MR3, ISAKMP SA established:

Let’s do further check

Now let’s do application checks

Connection from aws to azure

Connection from azure to aws

That’s all folks, I hope this has been meaningful to any of you.