The VoIP Addict’s Guide – Redundancy in the Cloud: OpenSwan VPN

A few weeks ago, I wrote about redundancy in the cloud, mainly using AWS (Amazon Web Services) as an example.

Today, we’ll talk about how to connect multiple regions together through a VPN so that systems can synchronize local IP address to local IP address. Some systems will allow you to send backups and perform a restore over the Internet to public IP addresses, but in the event, you are using one that doesn’t, a VPN will be required. Connecting different regions together is important because sometimes entire regions on a cloud platform can suffer from catastrophic failures as recent events will prove. Placing all of your eggs in one basket, as they say, is a bad idea. Unfortunately, when it comes to AWS, there is no mechanism to route traffic to a geographically separated region over AWS alone. I have no idea why, but that’s just the rules the AWS gods have directed us to follow. So, to fix that, we need to create a VPN.

Fortunately, there all sorts of canned VPN solutions. The downside is: they generally cost quite a bit of money. You’ll find that you will need to pay a subscription fee on top of AWS usage charges for a Palo Alto, Brocade, or Fortinet virtual appliance. While these are great to have, they might be cost or operationally prohibitive for your environment.

Thankfully, there is another solution, and it’s called OpenSwan. OpenSwan is a quick and easy way to turn a Linux machine into a VPN server using IPSec. The major benefits are that it’s free to use and install, and it can run on a cheap instance on AWS (free tier). Meaning, you’ll essentially just pay for storage, which can be small at 8 Gigs per machine. You’ll, of course, need two of these Linux instances, one per region. Let’s create a hypothetical scenario, configure a VPN between two AWS regions, and route traffic appropriately.

Imagine an East and West region with non-overlapping IP addresses in their respective VPCs (virtual private cloud). If you’re not familiar with AWS, the VPC is the top hierarchical unit which contains subnets. Within the subnets are your instances. In our example, the West VPC uses 10.0.0.0/16, with a single 10.0.0.0/24 subnet configured, giving you 254 hosts minus a few that AWS uses for the Internet gateway and DNS. The East region uses 172.16.0.0/16, with 172.16.0.0/24 carved out of it, which also allows 254 hosts minus a handful. In each region, there will be an IP PBX, and OpenSwan server. The West is designated as the primary site for phones to register to, and the East as the warm spare as described in my last post. In the specific case of FreePBX, the warm IP PBX will perform a backup of the primary via the VPN,  save the configuration locally, and restore it so it becomes an identical copy with the exception of network settings. In the case of Wazo, the VPN would be used for more frequent synchronizations along with a ping probe to monitor availability. The figure below depicts our scenario (please excuse the Visio drawing):

Let’s build our VPN (IPSec with PSK).

Somme AWS and Linux experience required.

1. Launch two new instances of Amazon Linux in the FreeTier (t2.micro). The VPN is meant for synchronization only, so it doesn’t need a lot of horsepower or network performance.

2. Attach Elastic IP addresses to your instances.

3. Route traffic for the opposite region to your new instances.

4. In the security groups for each OpenSwan server, allow the Elastic IP address of the opposite server. You will also need to allow the opposite subnets in the security groups of the IP PBXs. Below are catch-all rules:

5. Log into your instance update, and install OpenSwan on each.

6. Uncomment (remove the’#’) the last line in /etc/ipsec.conf to include *.conf files in /etc/ipsec.d

7. In /etc/sysctl.conf, modify net.ipv4.ip_forward to equal 1, and add:

net.ipv4.conf.all.accept_redirects=0

net.ipv4.conf.all.send_redirects=0

8. Create the configuration for the West region OpenSwan instance.

9. Create a .secrets file for the West region OpenSwan instance.

10. Do the same on the East OpenSwan instance.

11. Restart the network service on each server and start the VPN.

12. Check your VPN status.

Verify connectivity by pinging each opposing OpenSwan’s internal IP address and also the IP addresses of the IP PBXs. You’ll also want to make sure each IP PBX can communicate across the VPN as well. If you are modifying these configurations to fit your own specific setup and the VPN fails, check to make sure all of your IP addresses are correct and that your security groups are allowing the traffic. After any corrections are made, be sure to restart ipsec by using ‘service ipsec restart.’

If all went well, you now have the ability to synchronize or replicate your IP PBX configuration. I’d like to add and make clear that the scenario and configuration above should strictly be considered a proof of concept and shouldn’t be used for production. If you are thinking of employing a similar setup, make sure you are more specific with your security groups (mostly with allow protocols, and outbound connections). You should also consider narrowing your subnets to something significantly smaller if you won’t be needing so many IP addresses. There are also several ways to configure OpenSwan. I chose PSK in this example because it is the most simple to configure, but check out the OpenSwan wiki for more options.

Thanks for reading and Happy VoIPing!