Linking systems via OpenVPN (No port-forwards needed on client-side)

March 17, 2010 Chilling_Silence Elastix.org Blog

Yes, this is the ultimate in remote access for your PBX systems! It’s also quite possibly the longest blog post ever!

Imagine a client of yours happens to move their PBX, perhaps they are shifting premises (Without notifying you — Their prerogative I suppose). Now, with the change of ISP’s they’ve changed router and network settings, new public IP Address etc, so until you fix the sip_nat.conf settings calls are dead quiet. What do you do?

Well, you could ring them up and get them to port-forward their router and let you in. Or, you can do everything yourself via your shiny remote-control VPN!

Not only does it not matter where your customer plugs in the box, provided DHCP gives it an IP Address and they don’t have some silly proxy in the way, it will tunnel out NAT, past their routers firewalls, and let you in! It’s a service-operators dream! Used in conjunction with the SSH Tunnelling blog article, you’ll find this gives you total control of their local endpoints as well, just as if you were right there sitting on their LAN. You can even access your clients ADSL Router WebGUI and make the required port-forward changes yourself, provided they give you the admin password of course.

Table of Contents

  1. Expected outcomes of this How-To
  2. Example final VPN layout
  3. Preperation & IP Addressing
  4. About the structure
  5. Server setup
  6. Client setup
  7. Testing
  8. Last words

1) Expected outcomes of this How-To

At the end of this How-To you should:

  • Be proficient in generating Keys for clients
  • Understand basic security, what files are private and must be kept secret
  • Understand the basics of how OpenVPN is setup and works
  • Know how the VPN is routed, what boxes are able to see each other
  • Have setup a VPS with OpenVPN
  • Have clients that initiate the connection to the server, tunneling out past NAT etc
  • Hopefully have a fully working VPN that allows total remote management of your PBX systems

2) Example final VPN layout

You can see that even though each PBX box (And the Admin Laptop) have different IP ranges, they’re all connected to the VPN Server. The PBX’s can “see” each other as well as the Admin Laptop, and vice versa. What cannot be seen is the other devices on remote LAN’s, such as Phones, Computers, and other devices. That requires SSH tunneling. Click the picture for a larger version:

In my case, I’ve used a VPS (Virtual Private Server) to host the VPN, it’s just a vanilla box running Debian. I do this because it’s then hosted in a Data Center, it’s always-on, always accessible, and ultra reliable!

3) Preperation & IP Addressing

Keep in mind that if you’re using 192.168.1.1 on your client LAN and 192.168.1.1 for your VPN “LAN”, then you’re going to run in to routing issues and it’s not going to work.

If you use 10.0.0.0 with a subnet of 255.255.255.0 then you’re also going to potentially run into issues. However if you use a subnet of 10.0.0.0 with a subnet mask of 255.255.255.0 then you’re less likely to hit issues.

With this in mind we recommend you pick something in the middle of the 10.X.X.X range (Such as 10.99.88.0/24). We’re also going to start off with a /24 which will give you approx 62 usable clients. OpenVPN uses 4 IP Addresses per-client, I’m not entirely sure what for, but I believe one is the real IP, one for broadcast traffic etc.

Starting off with a /24 just because we can, because we’ve got no immediate need to have more than 60 devices, and because it’s easier to try and preach to the masses about what the IP Addresses are that will be used.

4) About the structure

We’re going to be setting up the VPN in a One-to-Many structure, with one server and many clients.

Every client gets one Key / Certificate file. Each client (key) can only be used once at a time, trying to have two machines use the same will result in issues. You can have multiple clients with different keys connected concurrently however (That’s the main purpose of this).

Also, the way it’s setup is so that each client (The Elastix PBX) can see every other client. Same goes for any “Administration” devices, such as a Windows Laptop used to administer the PBX systems, it’ll be able to see all the devices and they will all be able to see it. If this is not desirable, I would suggest that you use something like iptables on the main VPN Server to prevent this.

Another thing to keep in mind is that this can be used for direct Elastix -> Elastix links, for secure tunneling and communications. All you need to do is replace the VPS VPN Server with an Elastix machine. It really makes little difference.

One thing to keep in mind is that the other devices on the LAN of the clients cannot see anything else on the VPN, in fact they’re generally completely unaware of the fact that the Elastix PBX is even connected to a VPN. If you want to remotely administer phones via this VPN, you’ll need to read up on the SSH Tunneling How-To, and use your imagination a little bit. It’s incredibly easy.

5) Server setup

We’re going to begin by installing the relevant RPM’s from the Dag repo’s: http://dag.wieers.com/rpm/

Depending on your distribution, you may simply need to run something like: apt-get install openvpn

Note: I’m now assuming that you have OpenVPN installed. There’s no difference between client / server, so it’s just the one “openvpn” package. I’m also assuming you’re running a Linux server. You *can* use Windows, I’ve done it twice before with great success, but this documentation is written with a Linux server in mind. You can bridge the gaps by reading here: http://www.openvpn.net/index.php/open-source/documentation/howto.html#quick

Now, we’re going to edit /etc/openvpn/server.conf using your favorite editor (I’m a nano fan) and put in the following:

port                    1194
proto                   tcp
dev                     tun8
tls-server
cipher                  BF-CBC
ca                      /etc/openvpn/server/ca.crt
cert                    /etc/openvpn/server/server.crt
key                     /etc/openvpn/server/server.key
dh                      /etc/openvpn/server/dh1024.pem
client-to-client
mssfix                  1200
comp-lzo                yes
keepalive               7 20
server                  10.99.88.0 255.255.255.0
ifconfig-pool-persist   /etc/openvpn/server/vpn.hosts
route-up                "route add -net 10.99.88.0/24 tun8"
push                    "route 10.99.88.0 255.255.255.0"

Now I’ll explain:

We use the default port of 1194, TCP (Not UDP), with the BF-CBC encryption (because it’s slightly lighter on the CPU than the likes of AES, though feel free to debate that with yourself).

We’re telling it that everything is gong to be in the /etc/openvpn/server directory, and a few other little “fixes” that are useful to have.

Now, we run:

cp -Rv /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn/

This copies the files needed to generate the keys into an easy location in /etc. In my case, there’s a 1.0 and a 2.0 directory. I’ll presume you’re in the 2.0 directory whenever I refer to it.

So, you should now be in /etc/openvpn/easy-rsa/2.0

Now you’re going to edit the file “vars”. Go right down to the very end and edit the last 5 lines.

Run:

source vars
./clean-all
./build-ca

This is going to clean everything up and build your Certificate Authority (VPN Server).

Where it asks for values, just press Enter to accept the defaults that you’ve entered in to the “vars” file.

Where it asks for the Common Name (e.g. server Hostname) you can press Enter and it will call it “CA”.

Now we’re going to generate the Certificate & Keyfile for the server:

./build-key-server server

It’ll ask if you want a password, for the scope of this document we’re just going to press Enter and skip the password.

When you’ve pressed Enter and gone through it all, you’ll see a confirmation right before the files are created:

Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           : PRINTABLE:'NZ'
stateOrProvinceName   : PRINTABLE:'AK'
localityName          : PRINTABLE:'Auckland'
organizationName      : PRINTABLE:'Anonymous VoIP Company'
commonName            : PRINTABLE:'server'
emailAddress          : IA5STRING:'Fake@anonymousvoipcompany.co.nz'
Certificate is to be certified until Mar 14 03:34:48 2020 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Note: I’ve put in fake values here just so that I don’t get spammed, but I recommend you use real details.

Now we’re going to generate Diffie Hellman parameters:

./build-dh

Now we put the files into the right location with:

mkdir /etc/openvpn/server
cp keys/dh1024.pem /etc/openvpn/server
cp keys/ca.crt /etc/openvpn/server
cp keys/server.crt keys/server.key /etc/openvpn/server

Everything on the server should now be all done, so you can restart the service:

/etc/init.d/openvpn restart
echo 1 > /proc/sys/net/ipv4/ip_forward

The last line is optional to enable forwarding.

Congratulations! Now we can move on to the client setup!

6) Client setup

We’re still working on the server at the moment, but we’re going to presume you’ve come back to re-generate another key.

To start with on the server run:

cd /etc/openvpn/easy-rsa/2.0/
source vars

This sets up the server to use the variables you’ve entered when you first setup the server.

Now we’re going to generate the key with:

./build-key clientcompany1

I call it “clientcompany1” as I support multiple clients and this links them. You could also call it something such as “southernoffice” or anything you like really.

Now you want to copy the following files off the server via SCP or similar:

/etc/openvpn/easy-rsa/2.0/keys/clientcompany1.crt
/etc/openvpn/easy-rsa/2.0/keys/clientcompany1.key
/etc/openvpn/easy-rsa/2.0/keys/ca.crt

You also need the ca.crt file from

There are additional files (.csr — Certificate Signing Request) that you can just leave there.

If you’re wondering about what files are private and what are not, see here: http://www.openvpn.net/index.php/open-source/documentation/howto.html

Press Ctrl + F and search the page for “Key Files” to skip straight to the relevant table.

When the files are copied off, you’ll want to install OpenVPN on the client. It doesn’t matter if it’s a windows desktop or another Elastix server.

Assuming you’re using an Elastix PBX as a client, install OpenVPN from the Dag repos, or if you’re using Windows then get the OpenVPN-GUI packages from: http://openvpn.se/

Now you’re going to SCP the clientcompany1.crt & .key file in to /etc/openvpn

port            1194
proto           tcp-client
dev             tun8
remote          vpn.servername.co.nz
tls-client
ca              ca.crt
cert            clientcompany1.crt
key             clientcompany1.key
ns-cert-type    server
comp-lzo        yes
pull

This is going to tell the client to connect to vpn.servername.co.nz which you’ll need to update with the appropriate IP Address or domain name of your VPN Server.

That’s it, you’re now all good to restart the service and connect!

7) Testing

You should now have your client connected. What you want to do is ping from the server to the client and the client to the server. Then if you connect multiple clients, try and ping between them. Provided there’s no firewall in the way, and that you’ve run this on the main VPN Server:

echo 1 > /proc/sys/net/ipv4/ip_forward

You should be able to ping from client to client.

Once you have established that pings are working, you should then be able to follow through with other traffic, such as IAX2 trunks, HTTPS access to the WebGUI, SIP traffic, anything you can shake a stick at.

If you cannot ping, make sure that you’re successfully connected and that both your clients and server have an IP Address. Many times you’ll find that during the connection process it will log its reason for failing, and that’s generally what prevents things from working is the actual connection.

Also make sure you’re using the VPN-internal IP Address to ping, not the external IP.

8 ) Last words

IP Addresses for clients start at .6 (Such as 10.99.88.6), and increase by 4 every time. So the second machine to connect will be 10.99.88.10

If you run into troubles, feel free to post in the blog comments.

If you have a success story, please also post, it’s great to know the time taken to write this has had good results.

Look forward to hearing from you

Cheers

Chill.

Elastix, OpenVPN, pptp, remote access, ssh,


Leave a Reply

Powered by WordPress. Designed by elogi.