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):

vpn-scenario-image

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.step1

 

step-1-2

2. Attach Elastic IP addresses to your instances.

step2

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

step3

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:

step4

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

step5

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

step67. 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

step7

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

step8

 

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

step9

 

10. Do the same on the East OpenSwan instance.

step10

step8-2

 

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

step11

12. Check your VPN status.

step12

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!

For over 12 years now you’ve trusted us for all the phones, adapters, switches, and gateways that you need for your VoIP network.

We want to help you even more.

So we built our very own VoIP services offering from the ground up with future proof, scalable, and flexible features that we know you need from your communication platform.

Introducing CloudSpan by VoIP Supply – our first ever cloud-based VoIP service that include:

  • CloudSpan SIP Trunks
  • CloudSpan Hosted IP PBX
  • CloudSpan Hosted Fax

About CloudSpan SIP Trunks

If you manage your own VoIP system, CloudSpan SIP Trunking offers business class SIP trunks with standard features such as unlimited inbound calling, e911 Emergency Service, caller ID with location, HD voice, and fraud protection.

CloudSpan SIP Trunking service does not require a contract and there are no setup fees and no termination fees.

About CloudSpan Hosted IP PBX

For businesses that don’t want to worry about managing a communications platform, CloudSpan Hosted IP PBX professionally maintains the entire phone system in the cloud, removing the customer’s burden of purchasing and maintaining IP PBX hardware and software.

CloudSpan Hosted PBX has the flexibility to scale up or down as your calling needs change with features geared towards today’s mobile workforce including unlimited extensions, cloud extensions, find-me / follow-me call routing, e911 Emergency Service, call recording, voicemail to email, remote and mobile access, and 24/7 system monitoring and management.

About CloudSpan Hosted Fax

Like it or not, you probably still have to send and receive faxes to and from your customers and clients.

CloudSpan Hosted Fax simplifies this paper-based technology into a digital, cloud-based solution by allowing you to send an receive faxes via email, web broswer, or even a smartphone app.

Save money by getting rid of your dedicated phone line for faxing and never worry about fax machine maintenance again.

Brand Promise

Love is free. So is your service if we let you down.

– Ben Sayers, VoIP Supply CEO

We want you to be completely satisfied with CloudSpan.

If we let you down, we’ll refund your last payment and help you switch to a new service provider.

Plus there are never any contracts, setup fees, or termination fees.

Need More CloudSpan Info?

Whether you’re new to cloud services or just need more information about CloudSpan, check out these links: