Using OpenVPN to avoid NAT

One of the major advantages of using OpenVPN is the ability to totally avoid NAT issues to client machines. However you do need to be aware of potential latency issues when using OpenVPN.

As an example, let's assume I have an OpenVPN Server in Gladstone, QLD (Blue dot on the map below)

Open

This is an excellent place for an OpenVPN Server where the primary communications are going to be between Brisbane, Gladstone, Townsville and Longreach.  Here's an example of the latencies between those sites.

Open

When you're using an OpenVPN server, all communications goes through that OpenVPN Server, there is no peer-to-peer connection. Even though Longreach (the line going West, terminating on the 'E' in Queensland) is only 30msec away from Brisbane if 'ping'ed directly, the acual latency will be 50msec, as the traffic is being routed through Gladstone. 

But first, let's talk about Latency!

Having 50msec of latency, luckily, isn't that much of a problem. Humans don't start to notice latency until it's up at about 60msec, and it doesn't become obvious until 80 to 100msec. This network layout is perfect for a regional network.  However, lets deliberately design a BAD network!

This is an example of an 'Easy, but terrible', network. At first glance, it looks great. Everything connects back to Brisbane, and everything has a really good latency. Until Cloncurry (left) wants to call Cairns (top). 75msec latency in network alone, excluding the extra time the traffic spends getting encoded and encrypted. Don't do this! (Unless, of course, the branch offices don't talk to each other at all, which is pretty unusual).

In the situation above, you would normally have a direct link between Cloncurry and Cairns, so they don't go through the OpenVPN tunnel, which is the dotted line above. When you're designing your OpenVPN network, latency is something you should always keep at the top of your mind. However, ensure that you actually test the latency. Don't assume that physical proximity is the same as network proximity! 

OpenVPN Tunneling

Now you have your OpenVPN network designed so latencies are minimized, it's time to configure your client machines. We're going to go back to the original 4 node network. We're going to deploy our OpenVPN and Monitoring servers on a central FreePBX server, located at Gladstone. That will be (automatically) allocated the first address in your VPN range (which is randomly generated to be in the 172.16 address space. I'll be describing it here as 172.16.1, but it can be different).

• FreePBX-1 (Gladstone) – External Address 203.17.11.60, VPN Address 172.16.1.1, Extensions 900 to 999

• FreePBX-2 (Townsville) – External Address 203.4.240.10, VPN Address 172.16.1.11, Extensions 100 to 199

• FreePBX-3 (Brisbane) – External Address 203.4.241.10, VPN Address 172.16.1.12, Extensions 200 to 299

• FreePBX-4 (Longreach) – External Address 203.4.242.10, VPN Address 172.16.1.13, Extensions 300 to 399

At this point, if you've simply assigned the IP addresses inside M3, the remote machines (11,12,13) will be able to ping Gladstone (.1), but they won't be able to ping each other. This a default security option, and if you wish to enable the machines to ping each other, you will need to enable Routing in the OpenVPN Settings page.

Option 1: Each machine knows of every other machine

This is the most complex to set up, but can avoid issues if the central (Gladstone) FreePBX is down for some reason, but OpenVPN is up (e.g., Asterisk crashed and wasn't restarted automatically).  You also need to enable Routing in the OpenVPN Settings, so that each FreePBX machine can contact every other one.   On each machine you set up a Trunk to every other machine, and create outbound routes that match the extension maps.  However, instead of using their external address, use the VPN Address - 172.16.1.  This tunnels the traffic transparently, and totally avoids any NAT issues that may occur.

Option 2: Remote machines only know about Gladstone

This is a much simpler setup, and gives you the ability to scale your client sites out easily. It also doesn't require you to open up your OpenVPN network.  The downside is that it adds several single points of failure to your phone network, and should only be undertaken with careful consideration of the potential consequences of failures.  Using FreePBX-HA as the central node is highly recommended. 

With this scenario, the client machines would have a single trunk connection to 172.16.1.1, and the central Gladstone server would then have routes to 172.16.1.xx clients.  This is done by setting the context of the incoming trunk on the Gladstone machine to be 'from-internal' rather than 'from-pstn', and simply building outbound routes with the correct extension maps to the correct client.