Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 1

Important

Some readers of this blog may recall that several months ago I had wished for a Simple VPN device – back then I had written:

There is another type of software that ought to be moved into its own box, and that is Virtual Private Network (VPN) client and server software. Yes, I’m aware of OpenVPN, and I tried to find setup instructions that someone like me could understand, but to no avail – it looks like you need a degree in computer networking to understand how to set up this type of software. And yet, built into hardware devices, it could be immensely useful in certain circumstances. Let’s consider the following diagram:

In this particular case we have a SIP-based VoIP adapter at a remote location. Anyone who has worked with Asterisk behind the wrong kind of firewall knows the issues involved with using SIP and not having things set up just so (one-way audio, anyone)? But also, we may for whatever reason want that “remote” VoiP adapter to appear as if it were on the local network (maybe we have an ISP playing games with SIP packets?). So we plug the VoIP adapter into our “VPN Client-Side Device” and on the other end, we have a companion “VPN Server-Side Device” which in this case makes two connections to the router – one to receive the “tunneled” data and the second to send the unencrypted data back onto the local network. The green arrows represent the “tunnel”, the orange arrows show where the data from the VoIP adapter enters and exits the tunnel. Please note this is entirely a wired connection, we aren’t using wireless anywhere here. Also note that as far as the VoIP adapter is concerned, the only network it can “see” is the one at the other end of the tunnel – under no circumstances can it access the Internet other than by going through the tunnel.

I show this using a VoIP adapter, but I’m sure that people could think of a lot of other ways this could be used, and a lot of other devices that could be connected to the client end.

Now some will probably argue that it is inefficient to have a device that does nothing but provide the tunnel. But that’s the point – almost anyone could set this up. If you send the client-side device to your grandmother, she can set it up (well, maybe that’s pushing it a bit, but you get my point). People who would never touch a Linux box or a server could use this.

I want to tell you, when I wrote that I had no idea just how difficult it would be to actually get VPN tunneling working using OpenVPN. The problem isn’t that it doesn’t work — actually, it works quite well — the problem is that it’s a real bear to set up, unless you have someone who knows what they are doing walk you through it. Unfortunately, you may not haves someone who knows what they are doing to help you, so you’re stuck with me (unless you can find a better page on the subject – if such exists, please let us know in a comment).

The real issue is that you have to learn so many new things at once to make this work. So, my attempt here is going to be to try and give you a “cookbook”, with plenty of screenshots so you can see how things actually look when everything is configured. I’m actually also going to approach this in a slightly backward manner, showing you how to configure the client first, then the server. My theory is that you will think that configuring the client is so simple that configuring the server can’t be much harder, and you’ll get sucked into the project before you realize what you’ve gotten yourself into! 🙂

By the way, what we are doing here doesn’t look exactly like the diagram above – instead it looks more like this (note that the “Primary Router” on the client side can be omitted if you don’t need any UN-tunneled connections, or if the DSL or Cable modem has a built-in router):

Diagram showing position of OpenVPN client and OpenVPN server in data flow

For our client, we need something that you can plug your desired device into. You may have a laptop, and you want to communicate securely with a home office. You may have a VoIP adapter, and you want to make secure calls to a remote Asterisk server. While you can run a software client on the Laptop, when you have a hardware device like a VoIP adapter your choices become more limited. The solution is to purchase a router that is capable of being re-flashed with custom firmware. In this case we are going to use the Tomato firmware, and in particular, a version of the firmware designed to support OpenVPN as either a client or a server. Here we’re going to use it as a client. The idea will be that ANY device plugged into the router will automatically use the VPN tunnel, and if for some reason the tunnel isn’t available then the connected device will not be able to communicate, therefore there’s little chance that an insecure communication can take place.

Some readers will already have a router capable of running Tomato firmware, and some will not. The main Tomato Firmware page shows which routers are supported. If you do not already have one of these and plan to buy one, I recommend that you consider the Asus WL-520GU. I know that the main Tomato firmware page says there’s no USB support for that model, but that’s not necessary for what we’re going to do, and it’s not even true if you use the recommended firmware build. The reason I suggest using the WL-520GU is because I’m told that although it’s not totally impossible to “brick” the router by doing a bad flash, if you do make a mistake, your chances of being able to recover (so that the router isn’t consigned to being an expensive paperweight) are far better than with some other models.

I should mention here that I inherited this project from someone else who couldn’t get it to work. I had made the mistake of casually suggesting they get the Asus router if they wanted to attempt this, only to find them on my doorstep with router in hand. So again, I’m not saying this will be easy, and the one thing I will not tell you how to do is how to get the Tomato firmware onto your router. The reason is that if I give you instructions and leave out a step and you brick your router, you will be mad at me. Better you find someone else’s instructions, and if they’ve left out a step, you can be mad at them. I will mention that, at least in the case of the Asus router I had here, it was a two-step process – I used the Asus Firmware Restoration Utility to first install DD-WRT (using these instructions) and then used DD-WRT’s web interface (Administration -> Firmware Upgrade) to install Tomato (I’m skipping a whole tale of woe and grief that transpired between those two events). Basically I followed the instructions at An Easy Guide to Installing Tomato on the Asus 520gu, but I’m not telling you to do that — it’s up to you which instructions you wish to follow.

Why Tomato instead of DD-WRT? Because Tomato works, that’s why. But if you want to try getting it working on DD-WRT, go ahead, knock yourself silly (only one tip for you, from a tweet by @pista01 on Twitter — if you keep getting TLS errors, make sure your NTP client is set up). If you succeed, great for you. If you don’t, you’re welcome to come back here and continue on.

But don’t just grab the first build of the Tomato firmware that you see. You need one that includes VPN support. There are two versions I would highly recommend — if you have taken my advice and acquired an Asus WL-520GU (or similar model with built-in USB port), then I recommend teddy bear’s build because it enables the “missing” USB support, and also includes the VPN support from SgtPepperKSU’s build — which is the one you should get if you DON’T have the Asus WL-520GU, but instead have some other compatible router (EDIT: Advanced users may also wish to check out thor2002ro’s build, which offers both the VPN and USB support from the aforementioned builds, plus support for SDHC, SNMP, and perhaps other additional features. I haven’t tested that one at all, and note that recent versions probably won’t work with many router models due to memory requirements, so unless you really need one of the features in that version and know that your router supports it, I’d stick with one of the other versions). Make sure you read up on the chosen build and be sure you get the correct firmware version. For the Asus I used the binary from inside the tomato-1.25-ND-USB-8632-vpn3.3.rar archive, but since then a newer version has been released (tomato-1.25-ND-USB-8634-vpn3.4.rar was released in August, 2009), or you may prefer a different version.

tomato In this series you will see several screenshots. I’m using the custom “Tomato USB” theme, so the colors and “look” may be a bit different than what you see, but other than that everything’s in the same place as with the default theme. Later (after taking the screenshots) I replaced the tomato.png file from the theme with the one you see at the right, which I happen to like a little bit better.

Two other caveats: Although this router has wireless capability, for this application we aren’t going to use it — it’s going to be used on a wired network only. That said, once you get it set up and working, feel free to experiment with the wireless capabilities if you like — just be aware that if something on the wireless side of things doesn’t work, I really can’t assist you. And also, we’re assuming that everything plugged into this router will be using the VPN tunnel full time, which implies that this router might (perhaps in a majority of cases) be plugged into another router, so that some other devices can access the local Internet connection, while the devices plugged into this router are limited to going through the tunnel. Note that if this router is plugged into another router, it would be preferable (but not absolutely essential) if it were in that router’s DMZ, so that you don’t have double NAT (Network Address Translation) taking place.

And now, a word about OpenVPN. OpenVPN supports two different modes of operation — TAP and TUN. In this case, we are using TUN. We MIGHT explore TAP at a later time, but TUN is easier to set up, and ANYTHING that can be done to simplify this process is worthwhile. The main difference, from the users point of view, is that using TUN the two ends of the tunnel occupy two different portions of the local address range. In this case, on our “home” LAN, the addresses are in the 192.168.0.x range and are assigned by the main router. At the client end of the tunnel, the router running the Tomato firmware will hand out addresses in the 192.168.5.x range. Neither router steps on the other’s toes, so to speak, when handing out addresses. And there is one other difference — although shared directories can be accessed across the network, Windows/Samba shares cannot be “seen” on opposite ends of the tunnel. If you know they are there and know the IP address and share name of the hosting device, you can still access them, but the mechanism that advertises shares doesn’t cross the tunnel.

With TAP, on the other hand, the router at the primary location hands out IP addresses in the same local address range to devices on both sides of the tunnel, and also (in theory, anyway) shares will be “advertised” across the tunnel. Sound like what you’d want, right? Except that when we tried to set it up on the server side, somehow we managed to bring down the entire network – it basically acted like a denial-of-service attack on the entire LAN, and the problem stopped the moment we went back to using TUN. After you’ve messed with this stuff long enough, something like that can leave a rather bitter taste in your mouth, so we decided to stick with what worked. In our particular application, seeing shares across the LAN would not be essential. Even if you eventually want to try using TAP, I suggest setting it up using TUN first, then when you have achieved that you can cross your fingers and try switching the mode to TUN at both ends. I doubt it will work easily for you, but experimentation is certainly welcome.

If you want to know more about TUN/TAP and other OpenVPN options, you might want to get the book Beginning OpenVPN 2.0.9 (Amazon affiliate link) by Markus Feilner and Norbert Graf — see my recent mini-review of this book (links edited February, 2010 to reflect updated and expanded edition of the book).

So with the preliminaries out of the way, let’s get to the client screenshots…

Tomato Firmware - Basic | Network page — Tomato Firmware – Basic | Network page

This first shot shows the header, sidebar, and Save/Cancel buttons. Since the settings are probably a bit hard to read, we’ll zoom in on the pertinent part:

Settings portion of Basic | Network page

The main thing to keep in mind here is that the subnet you select must not conflict with address assignments on the primary network at the server. Next, on the Router Identification page, enter a Hostname to identify the router:

One thing I have read in several places is that it’s important for the time to be set accurately at the client. For your choice of time servers there are several presets, but if you use Custom you can specify one or more of your own as the first choice(s), if you have a machine on your network that acts as an NTP server:

At this point you should probably go to the Administration | Admin Access page and set things up there to your liking. Remember that anything you make accessible on the router’s local LAN will also be accessible on the other side of your tunnel using the same security methods, so be careful.

Now to what we came for… setting up the VPN client. Click on VPN Tunneling and then on Client. I’ll say that one more time – you MUST click on Client. It’s far too easy to skip that step and accidentally be trying to configure a server! Then you should be at the Client 1, Basic tab:

Of course, the button at the bottom of the page will sat “Start Now” instead of “Stop Now” – I took these screenshots through the tunnel, so I couldn’t very well stop it to get that little detail right! After setting that up you want to click on the Advanced tab:

Note that the connection retry value is -1 (which means infinite retries) and there are two added lines in the custom configuration section:

keepalive 10 120
float

In case the connection to the server or the Internet goes down for a time, those settings should cause the client to keep attempting to re-establish the connection to the server. The float command is useful if your client is at a location where the ISP might change the IP address without advance notice — it is supposed to allow the VPN connection to survive an IP address change. You can omit float if your client is at a fixed IP address that is not subject to change.

And then the Keys tab – just take a look now, when we move on to the server I’ll explain how these are filled in:

There is one more thing that needs to be done (besides adding the keys) for our tunnel on the client side. Go to Administration | Scripts and click on the WAN Up tab. Enter the following two lines into the text box:

route del -net 0.0.0.0
route add -host `nvram get vpn_client1_addr` gw `nvram get wan_gateway`

The second line may wrap on your display due to length. You may want to copy and paste those lines so you get them right, but if you must type them, note that the ` characters are actually backticks – the small apostrophe-like character on the key to the left of the “1” key (the number 1) near the top left corner of most keyboards (well, in my part of the world, anyway). Then click on the Save button way down at the bottom of the page. If you fail to do this and your tunnel ever goes down (server dies or is inaccessible, etc.) there is a possibility that traffic that should go through the tunnel will use the local Internet connection instead. These two lines will keep that from happening. When you are done it should look like this:

Administration | Scripts page | WAN Up tab

Just a note for future reference: You can optionally add an additional line here to allow you to get to something “upstream” of the network on the WAN side of the router. For example, let’s say you have configured the server to allow you to connect to devices on both the LAN subnet (192.168.5.x in our example here) and also devices connected to the primary router, in other words, on the WAN side of the router running the Tomato firmware (which were in the 192.168.1.x range on our example setup). But let’s suppose that upstream of that, you have a cable modem at 192.168.100.1 at the client location that you’d also like to be able to access. As long as you don’t have a conflicting address elsewhere in your network, you could add a line such as this in your WAN Up script:

route add -net 192.168.100.0 netmask 255.255.255.0 gw `nvram get wan_gateway`

… which would allow access to anything in the range of 192.168.100.0 through 192.168.100.255. If you want to be more specific, you can narrow it down to an exact address:

route add -host 192.168.100.1 gw `nvram get wan_gateway`

We’ll cover what else has to be done to enable this type of additional routing at the server end in the upcoming installments, but the above is what has to be done at the client-side router that is running the Tomato firmware. Note that you do not normally have to a a line such as this to get to devices on the same subnets as the LAN or WAN ports of the router, but just for anything upstream of the network that the WAN port of the router is connected to. If you don’t understand why you might want to add this type of additional routing now, just ignore this information for the time being, but make sure you do add the first two lines I mentioned above.

Once your tunnel is operational, you should go to the Advanced | Routing page and look at the Current Routing Table. Your addresses will differ (this was a test setup; you probably will see a wider range of addresses) but the main thing you want to make sure is that there is never an entry of default (or 0.0.0.0) in the destination column that goes to any interface other than a tunnel (tun11 in this illustration) — you should never see that whether the tunnel is enabled or disabled. If you do, then something’s likely wrong with the two lines you entered above (under the WAN Up tab):

So, that’s the basic client setup. Wasn’t too difficult, right? Ah, but just wait until we get going on the server — hopefully I can make it easy enough that you won’t have about three weeks worth of sleepless nights, when you occasionally mutter under your breath things like “Why? Why?? Why??? WHY won’t this damn thing work!”, and other things I’d rather not put on the Internet! But before I can write the next part, I REALLY need to catch some ZZZ’s, so the server will have to wait for part 2.

Review of OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner (Packt Publishing)

Important

This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog. In order to comply with Federal Trade Commission regulations, I am disclosing that he received a free product sample of the item under review prior to writing the review, and that any links to Amazon.com in this article are affiliate links, and if you make a purchase through one of those links I will receive a small commission on the sale.

Cover of OpenVPN: Building and Integrating Virtual Private Networks

Before I start, let me give you a brief description of what’s in each chapter (this is taken directly from the Packt Publishing web site):

Chapter 1 looks at what VPNs are, how they evolved during the last decade, why it is necessary to modern enterprises, how typical VPNs work. The chapter also covers some essential networking concepts.
Chapter 2 explains VPN security issues, including symmetric and asymmetric encryption, the SSL/TLS library, and SSL certificates.
Chapter 3 introduces OpenVPN. In this chapter, we learn about the history of OpenVPN, how OpenVPN works, and how OpenVPN compares to IPSec VPN applications.
Chapter 4 covers installing OpenVPN on both Windows, the Mac, Linux, and FreeBSD. It covers the installation on Linux from the source code and RPM packages. Installation on Suse and Debian is covered in detail.
In Chapter 5, an encryption key for OpenVPN is created and it is then used to setup up our first OpenVPN Tunnel between two windows systems in the same network. The key is then copied on a Linux system and this system is connected through a tunnel to the first windows machine.
Chapter 6 shows how to create x509 server and client certificates for use with OpenVPN. easy-rsa which comes with OpenVPN and is available for both Windows and Linux is used.
Chapter 7 reviews the syntax of the command line tool openvpn, which enables building tunnels quickly. The configuration options of openvpn are covered in detail with examples.
Chapter 8 shows how to make the example tunnels created earlier safer and persistent by choosing a reliable combination of configuration file parameters. It then covers how to configure firewalls on Linux and Windows to work with OpenVPN.
Chapter 9 focuses on using xca, the advanced Windows tool with which x509 certificates can be easily managed. Its Linux equivalent, Tinyca2, which can even manage multiple certificate authorities, is also covered.
Chapter 10 covers advanced OpenVPN configurations, including Tunneling through a proxy server, pushing routing commands to clients, pushing and setting the default route through a tunnel, Distributed compilation through VPN tunnels with distcc, and OpenVPN scripting.
Chapter 11 shows how to debug and monitor VPN tunnels. It covers standard networking tools that can be used for scanning and testing the connectivity of a VPN server.

Although this may seem like a strange subject for this blog, I have recently become interested in the concept of Virtual Private Networks (VPN) because of the increasing number of attacks on Asterisk-based system based on spoof SIP credentials. SIP, the most popular protocol for VoIP, is an inherently insecure protocol – it relies on password protection only, and on most Asterisk boxes and in many VoIP devices and software products, the password is stored in plain text. On many systems, the user name is the same as the extension number, so all a potential intruder has to do is start a brute-force attack guessing passwords. The use of strong passwords along with the use of software like Fail2Ban (with iptables) can help minimize the exposure, but in the end it’s still only password protection.

Therefore, my feeling is that it would be much better to restrict extensions to access from within the local network (wherever possible), using the permit/deny fields in FreePBX or some similar mechanism, and then “tunnel” remote extensions through a secure VPN, so they appear to be on the local network. The VPN could do the heavy lifting for security (even making the actual calls secure, although that wasn’t a priority in my situation). My problem was that I knew next to nothing about VPN’s, and most of the pages on the Web seemed to assume at least some prior knowledge. I needed something that would take me from zero knowledge to VPN guru. Unfortunately, at my age it’s a case of “the spirit is willing but the brain is a bit weak”, so I realized that the “guru” part might not come very quickly (just as a comparison, I’ve been playing with FreePBX since back in the Asterisk@Home days, and there’s still a lot I don’t understand, but for the first year or so I felt totally lost).

Since the folks at Packt Publishing were willing to send me a review copy of OpenVPN: Building and Integrating Virtual Private Networks, I decided to see if I could actually learn anything from the book. The first thing you need to know is that there are many types of VPN’s out there, and each will only communicate with its own kind, as it were. The problem with most other tunnels is that they are either not all that secure, or contain proprietary code, or are incredibly complicated to set up and use (or some combination of the above). OpenVPN has several advantages, perhaps the biggest being that it’s open source (so you can, if you are so inclined, examine the code and make sure there are no “backdoors” built in), that it can be as secure as you want it to be (and it’s not that difficult to make it very secure), and that it doesn’t rely on a third-party service over which you have no control (like one VPN application that touts itself as “zero-configuration”). So of all the VPN methods out there, OpenVPN seemed like a logical choice.

Now, having said that, the book covers its subject in a very logical manner. Advanced readers (those already familiar with the principles behind VPNs) might find the introductory material in the first chapters a bit tedious, but believe me, it was just what I needed to help me get a grasp on the subject. As you go further through the book, there are many actual examples, first showing how to set up a working VPN tunnel, then how to add additional security, and finally how to troubleshoot connections. If you are brand new at this, like me, you will probably find that you learn a great deal from the first chapters but find the latter chapters (especially Chapter 10) a bit beyond your comprehension at first. However, the person who has some networking or VPN experience under their belt may think the first chapters a bit elementary, but will find the real meat they are looking for in the latter parts of the book. Either way, I guarantee you will come away with a greater comprehension of the subject.

The book shows how to install OpenVPN on several platforms (Windows, Mac OS X using Tunnelblick, FreeBSD, and SuSE, Debian, and Redhat/Fedora based versions of Linux), but it seems like some platforms are better covered than others. A disproportionate number of examples and screenshots seem to be based on a Windows installation, whereas the Mac gets very little coverage. Because there are so many variations of Linux, the coverage there is mixed, although it seems like SuSE and Debian are better covered than Fedora-based versions, which was just a little bit disappointing because most Asterisk and FreePBX systems are based on CentOS, which is a Fedora-based OS. But most of the information in this book is not OS specific, so I didn’t have any real problem following along.

The biggest disappointment for me was in Chapter 8, where the book covers the use of Webmin, but primarily as an aid to administration of the Shorewall firewall. Many Asterisk/FreePBX systems don’t use Shorewall, but instead use iptables (if they have a firewall on the Asterisk server at all). But what was really disappointing was that there was no mention of, nor instructions for the use of the OpenVPN + CA module for Webmin (page is in Italian, but here is a description in English). I can only guess that because the book was first released in May, 2006 and version 1.0 of the Webmin module had only just been released in January of that same year, the author perhaps hadn’t had an opportunity to work with the module before the final draft of the book was submitted to the publisher. I hope that if this book is ever updated and republished, there will be consideration given to adding a chapter on the use of the Webmin module to set up and administer OpenVPN. In the meantime, you can find instructions for using the OpenVPN + CA module in The ‘Point and Click’ Home VPN HowTo Guide.

That said, I felt I learned a great deal from this book. I was able to set up an OpenVPN server (using the Webmin module, but the book definitely helped me understand the purpose of the various options, and when I checked the configuration file that the module generated I was able to spot a couple of things that weren’t the way they should be for my setup and was able to change them) and the Windows client. It all worked beautifully.

My project now, when I have absolutely nothing else to do, is trying to get the OpenVPN client running on an Asus WL-520gu router that has the DD-WRT firmware installed (I inherited this project from someone else who couldn’t do it). So far this has proven to be a tough nut to crack – although it should be easy because (if you get the right version of DD-WRT) there is a built-in OpenVPN client with a handy configuration page, it just doesn’t seem to work “out of the box” – and from what I’m reading on the ‘net, for every one person who says they’ve got it working, there are about twenty others who have become incredibly frustrated by the process (example here – note that the original poster says he got it working, but that’s followed by about 16 pages of comments, mostly by people who just can’t seem to get it to go). It’s a bit strange because the Windows client will work perfectly (indicating it’s not an issue with the server) but the firmware client in DD-WRT just doesn’t seem to work. If I ever get it figured out, I’ll try to post what I did in this blog, but so far I’ve had no luck. That, however, is not the fault of the book – in my opinion it’s the fault of the writers of the DD-WRT firmware, who apparently included a half-baked OpenVPN client interface in the firmware (I know, it’s free software so I can’t really complain, but one does wish that they’d taken a bit more care to make sure it worked).

After having read the book, I do feel fairly confident that if I should throw in the towel and decide to dump DD-WRT and install a different firmware on the router (I’m thinking about trying the Tomato firmware with USB support) I would be able to install an OpenVPN client from scratch and make it work. Probably the main reason I haven’t wanted to do that is because I very much prefer using a GUI to do things, and would like to try to make the OpenVPN GUI in DD-WRT work (even if it requires a little help), but so far that doesn’t seem to be panning out.

But I digress a bit – anyway, if you are wanting to learn about OpenVPN, whether or not you are a rank beginner you will benefit from this book. The numerous examples and screenshots make it almost impossible to fail to get an OpenVPN tunnel up and running (providing you’re not using a questionable firmware client). And, as I said above, the book is laid out in a very logical progression, so I really didn’t feel totally lost at any point (as so often happens when I try to read technical books). Especially in the case where your boss suddenly decides he needs VPN tunneling capability, and wants you to have one up and running in a very short timeframe, this would be the book to get!

OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner (Amazon affiliate link)

EDIT: This book has been updated and expanded under a new title — see Mini-review of Beginning OpenVPN 2.0.9 by Markus Feilner and Norbert Graf (Packt Publishing)

Review of Ring Voltage Booster II™ from Mike Sandman Enterprises

Important

This article was originally published in April, 2008.

Once in a while you run into a situation where someone wants to put a whole bunch of phones on one physical phone pair. This can often happen in a home with many rooms, where every room has been prewired with a phone jack. You start out with a phone in the kitchen or living room, then you want one in the master bedroom, then each of the kids wants one, then you want one in the workshop down in the basement, and so on. Okay, so granted that the above example would probably have been more appropriate 20 years ago (before all the family members started wanting their own cell phones) but you can still run into such situations, both in homes and in small businesses that only have one or two phone lines and a bunch of phones hanging off each line.

In the old days the phone company let you have enough current to ring five standard telephone ringers – 5 REN in telco-speak – and that was five of the old mechanical style ringers with real bells. But nowadays people have started replacing their old wireline lines with newer stuff, like VoIP, and VoIP adapters can be notoriously stingy with ring current. Sometimes when people convert to VoIP, they find that they either have to disconnect some phones (or at least, shut off or disconnect the ringers in those phones) or figure out a way to boost the ring current.

Yet another problem with both certain makes of VoIP adapters, and even with some low-cost telephone switches sold to businesses, is that they don’t produce enough ringing voltage or current to begin with. That might be particularly true if the adapter or switch was designed to standards other than those typically used in the U.S.A. and Canada. In those two countries, phones and phone equipment have always been designed to expect ringing current at approximately 90 volts AC at 20 Hertz (cycles per second), but in some other countries both the ringing voltage and frequency can be quite different, causing equipment designed for the North American standard to not ring properly. Even with a VoIP adapter set to the correct voltage and frequency (not all are; it’s left to the provider to set those parameters on some devices), most VoIP adapters are only rated at 3 REN or less.

Recently I discovered that Mike Sandman Enterprises has started offering their Ring Voltage Booster II™ – this is the successor to the original Ring Voltage Booster™ that Mike has been selling for several years now, and it looked to me as though it would be just the thing to cure those ringing problems. The Ring Voltage Booster II is used in series with a telephone wire pair entering the premises (or coming out of a VoiP adapter or similar device), and it senses ringing voltage on the line and increases it (actually regenerates it) to the North American standard 90VAC RMS at 20 cycles, and increases ringing current to 7.5 REN.

I wanted to obtain a unit and try it out. I did just that and I thought I’d share the results of my test with you folks, because I was very favorably impressed with the unit. If all you want to know is whether it works as advertised, I would say that based on my experience the answer is an unqualified yes (with one very minor caveat, which I will mention in a moment).

The way I tested it was this. I had a Sipura SPA-2000 VoIP adapter which was connected to the existing phone wiring in a home where the wireline service has recently been disconnected. There was already quite a collection of phone equipment on the line, and I hung a couple of extra items on to load it down. When we got through adding phones we had the following on the line: two modern phones with warble-type ringers, three old 2500-series touch-tone wall phones with real mechanical ringers, one old 2500-series desk set with a real mechanical ringer, and just for fun, one old Western Electric 302 desk set with original ringer and ringing capacitor.

I want everyone reading to pause for a moment and consider that, apart from the fact that this 1940’s-era phone has a rotary dial rather than a touch tone pad, it works great today with the original ringer and capacitor. I’ve had several computer power supplies fail on me in recent years, usually within a year or two of purchase, due to bad capacitors (in a couple cases, exploding capacitors!). For all the bad things about the old Bell System, they sure knew how to build a telephone that would survive just about anything, except the elimination of switching equipment that accepts rotary dial pulses.

Anyway, I had the aforementioned relatively huge load (well above 3 REN, no matter how you count it) hooked up to the Sipura SPA-2000, and I placed a call to it.

And darned if the phones didn’t ring!

I stood there open-mouthed for a moment. Granted the ringing was a bit weak, but all the phones were ringing. I really hadn’t expected that. I could tell I was putting a significant load on the SPA-2000, but not enough to make a very noticeable difference in the quality of ringing. Then it dawned on me – I remember reading somewhere that early Sipura adapters were conservatively rated, but such was not necessarily the case with their successor, the PAP-2 from Linksys. Well, I have one of those, too.

So I disconnected the SPA-2000 and hooked up the newer PAP-2, and placed a call to the PAP-2, and did that make a difference! With the same load as described above, the phones were still ringing, but they were really struggling. The W.E. 302 and one of the new warblers were having the most trouble, both giving only partial rings. The others were ringing very anemically.

I then inserted the Ring Voltage Booster II™ and placed several test calls. The ringing was clear and strong, in fact, each phone rang as if it were the only phone on the line, and the ringing seemed loud and crisp on all phones. Granted this is a bit of a subjective observation since I was, after all, listening to mechanical telephone bells ring, but I grew up with those and I know what they sound like when they are ringing as they should, and these were.

There were two other things I wanted to observe. One was whether the unit interfered in any way with Caller ID. Only one of the phones in this test had a Caller ID display, but it got the correct Caller ID information every time. The other thing was whether it would have any problem with a distinctive ringing signal, and again, I can report that it did not. I happen to have that adapter programmed so that when a particular friend calls it rings with a distinctive ring, since this particular friend seems to have a peculiar form of psychic ability – he always seems to call when I am indisposed (usually in the bathroom or some such thing). So if it rings with his ring, I know I can wait until I’m through with whatever I’m doing, then call him back and share a laugh over yet another occurrence of his weird form of E.S.P. So, in order to test distinctive ringing, I called him and asked him to call me back and let it ring, and once the ringing commenced I checked several phones and all were ringing with the correct distinctive ring cadence (two approximately one-half second rings followed by a one second ring, or at least that’s what it sounds like). Also, I could hear a relay inside the Ring Voltage Booster II™ clicking on and off in time with the distinctive ring patterns.

In fact, the unit worked perfectly, save for one very minor nit: Sometimes, if I picked up a phone during a ring, it would continue to apply ringing voltage for the duration of that ring – in other words, it didn’t seem to always sense that the phone had been picked up and stop the ringing until that ring had ended. In all fairness, I’ve seen this happen before with other types of equipment, including real phone switches (particularly on long loops in rural areas, etc.). What this means is that if you pick up the phone at the very start of a ring and press it to your ear immediately, you could get a pretty loud buzz in the ear for a second or so. I don’t think this will be a major issue for most users, particularly since the unit solves a much greater problem (phones not ringing at all, or ringing very weakly). But for a few people, it might be an annoyance (Edit: One way to reduce this would be to always use a ring pattern that has rings that are one second long or less. Some VoIP providers will let you set a “distinctive ringing” pattern for each line or each incoming number – if you pick one that has a two or more short rings instead of a single long one, you greatly reduce your chance of hearing the loud buzz when you pick up the phone. Now that I think of that, I’ll bet that explains why many independent telephone companies used one-second long rings, instead of the two-second rings common in the Bell System). I don’t know if this was an issue with just the unit I was using, or with all of the units of this model, but it was the only thing I noticed about the unit that wasn’t “perfect” – in every other way, it delivered all you’d expect from such a device.

There are a couple of other pleasant surprises about this unit. Neither the unit itself nor its power supply seem to generate excessive heat in normal standby mode (I did not test an extended ringing cycle lasting several minutes or more, because that would have required shutting off voicemail) – in fact the small “wall wart” was very cool to the touch a couple hours after being plugged in. That’s more than I can say about many of the “wall wart” power supplies i normally use, and as you know, heat is wasted energy, so I’m very happy that Mike is including what appears to be a quality power supply. But what really shocked me was the small size of the unit. Perhaps it’s because I’m an “olde pharte” that equates a ringing generator with, at the very least, a large steel box hanging on the wall in a basement or phone closet, but this thing blew me away because it’s even smaller than any of my VoIP adapters! The longest dimension on it is only about three and a half inches. You’re almost certainly not going to have any problem finding a place to put it.

Hookup couldn’t be simpler, but you must observe that you get the connections right to avoid damaging the unit – in other words, don’t connect the side that’s supposed to be connected to the phones to the incoming phone line, or you will damage the unit. There are only three connections, one for power, one for the incoming line (labeled “line in” – this is the side you’d connect to a VoIP adapter), and one to go to the phones. If you are connecting it to a VoIP adapter you can probably do it in under a minute, once you have it out of the packaging.

In summary, if for any reason you don’t have enough ringing voltage or current on your phone line (or coming out of a VoIP adapter) and you need to boost it, this is the unit that will do it, at least up to 7.5 REN. And if you have a ridiculous number of phones on one line, remember that you can connect some of them before the Ring Voltage Booster II™ (using the original ringing voltage and current from the line or adapter) and the rest after (using the regenerated ringing current from the Ring Voltage Booster II™).

One caveat, this unit does not increase the gain (circuit loss), talk battery, or loop current of a line – if you need to boost loop current then Mike sells a separate Loop Current Booster™ that will do that. But the Ring Voltage Booster II™ basically gets out of the way when the phone isn’t ringing, and should not have any effect whatsoever on transmit or receive volume levels.

Mike Sandman has been selling quality phone equipment for many years now, so I expected this to be a quality unit. Even so, I was very favorably impressed with it. If you have problems related to low ringing voltage or current, get this device. If you have problems related to wrong-frequency ringing current (something that’s putting out ringing current at a frequency other than 20 Hertz), I’m pretty sure this will solve that problem as well, though I did not test that personally. Here is one more link to the page that describes this unit (and some others) and please note this is a plain-vanilla link – I’m not making any commission or anything if you buy one. I hope this review helps someone that’s having a problem getting their phones to ring!

Disclosure: I have not been and will not be paid anything for writing this article, and I do not receive any commission or other compensation from sales of this item, and the links in this article are not affiliate links. I did, however, request and receive a complementary Ring Voltage Booster II™ for review purposes (which I was allowed to keep after writing the review, and for that I am most grateful).

BETA Perl script for Caller ID popups when using Linksys/Sipura devices

Important

photo credit: bcostin

PLEASE NOTE: This article has been updated as of December 30, 2008. This now works with a Mac or Win32 computer (and Linux computers with libnotify installed or readily available, such as those running Ubuntu) and has been updated to reflect that fact. Also, please note that previous versions may have failed on devices/phones with more than two lines – this is (hopefully) fixed as of version 0.7.

If all of the following are true:

You have a Macintosh computer with OS X installed, or a PC with any 32-bit version of Windows installed (basically Windows ’98 through XP), or any version of Linux with libnotify installed

You have Growl (if you have a Mac) or Snarl (if you have a PC) notifications installed (EDIT: There is now a version of Growl for Windows but at the moment I only have an experimental version of the script for that – see bottom of this page for more information. It MIGHT work with 32-bit OR 64-bit Windows 7 – feel free to test it).

You have a Linksys or Sipura VoIP adapter on your local subnet or home network and receive calls over it

You would like to see Growl, Snarl or libnotify popups on your computer when a call comes in, showing the caller’s name and number, along with the line that the call came in on and the time and date the call arrived (in case you are out when the call comes in)

You have previously run Perl scripts on your computer, OR are reasonably good at following instructions and problem-solving

AND you are willing to run a script that comes with NO WARRANTY whatsoever (if it breaks, you can keep all the pieces)

Then download this file (now at version 0.92), unzip it and read the Instructions.txt file in the folder appropriate to your computer.

This script is being offered under the GNU General Public License, so if you want to modify it to work on other platforms, you can do that under certain conditions (see the Instructions.txt file for details). Mainly, I’d hope that you’d contribute the modifications back (and please leave a comment on this article if you do that).

I don’t have any kind of regular web page up for this yet, for one thing it’s very rough (very little error-checking) and for another I’m very tired, having spent way too many late nights trying to get this to work. So this post will be more terse than most of my posts, but I think most everything you need to know is in Instructions.txt (and for Mac users, the “How to run at login.rtfd” file) inside the .zip file. Feel free to repost this information to other forums if you think anyone else might be interested.

For those Mac users that wish this were an app: I understand that there is an app called Platypus that allows Perl scripts (and any other types of scripts) to be converted to OS X app bundles. However, what it does not seem to include is any way to specify the command line options, or to load any missing Perl modules. So for now, this script will probably only be usable by those with sufficient knowledge to run a Perl script on their Mac. If I were a bit more knowledgeable, I’d build a preference pane to go in System Preferences, and then have the script read that for its configuration options. But I still have no idea how to make an app install missing Perl modules, particularly when OS X does not come with “make” installed until and unless the Developer Tools are installed (adding something like 3 GB of stuff that is mostly useless to non-developers to your hard drive!).

EDIT: I read somewhere that you can install make without installing the bloated Developer Tools package if you instead install Fink. Then, from a terminal prompt, you can type fink -b install make and supposedly that will do the trick. However, I am told that Fink has not been updated for Snow Leopard, but there is a make package in Rudix that should work with Snow Leopard (mind your paths – Rudix installs make in the /usr/local/bin directory and by default CPAN expects it in /usr/bin, so you may want to adjust the path during CPAN setup, or make a symbolic link in /usr/bin). Since I have not personally tried either of these I have not updated the instructions in the download to reflect this, but if it works you can skip the whole process involved in installing the Developer Tools.

Because this is a Perl script, it lends itself to custom modifications. For example, let’s suppose you have this script running on a Mac, and you are sending Growl notifications to the Mac, but you also have a home theater PC that runs XBMC and/or Boxee, and you’d like to send Caller ID notifications to it as well. Assuming that Boxee and/or XBMC is configured to allow control via a Web interface, at a fixed IP address and port (192.168.0.150 port 8080 in this example), you could add a line such as this to the script (this is all one line; select and copy to get it all if it gets truncated on your display):

eval {get "http://192.168.0.150:8080/xbmcCmds/xbmcHttp?command=ExecBuiltIn&parameter=XBMC.Notification(Call%20from%20%22$displayname%22%2C$phonenum%20calling%20$lineid[$count]%2C15000%2C%2Fhome%2Fusername%2Fphone.png)"};

The above assumes that you have placed the icon file phone.png (shown at right — right click on the icon and save it) in the user home directory on the destination system (the one running XBMC or Boxee), and that you change ‘username’ to the actual name of the user’s home directory. Note that the icon path requires %2F in place of forward slashes (therefore %2Fhome%2Fusername%2Fphone.png really means /home/username/phone.png) and this refers to the icon directory and filename — if you choose not to use an icon then leave that part out, along with the %2C that comes just before it. If you are running XBMC or Boxee on the same system that’s running the script then you should be able to replace 192.168.0.150 with localhost or 127.0.0.1. The above line should be inserted just above the comment line “# Make output string in chosen format” near the end of the Perl script. Keep in mind that this won’t work if you don’t enable control via Web server in XBMC or Boxee, and make sure the port number matches the port in your added line. Depending on the skin you use, this is generally accomplished by going to Settings, then Network (and in Boxee, then Servers). Then check “Allow control of XBMC via HTTP” (in XBMC) or enable the Web server (in Boxee) and verify the port number is correct.

Starting in Version 0.7 there is a minimal logging function, allowing all detected incoming calls (whether answered or not) to be saved to a text file and/or a comma-quote delimited file. I probably could support other simple formats, but don’t even think about asking for anything more complex (like a rather humorous friend of mine who asked for MySQL integration – considering that he knows how little knowledge I have about Perl programming, and that I have even less knowledge about databases, I’m sure he thought it extremely amusing to make that request). The one thing I really don’t like about offering these scripts in Perl is that it requires the user to know how to install modules from CPAN (or an alternative source if using Win32), but I barely know how to do this stuff in Perl and don’t know any other languages (well, except for QBASIC under MSDOS, but that’s even less compatible across platforms than Perl!).

Starting in Version 0.9 you can use a plain-text file of number-name substitutions, so (for example) if calls from a particular number always display a cryptic Caller ID name, you can change them to say “Uncle Bob” (or some other name if Bob’s not your Uncle, or it’s someone else’s number!). Read the sample config file to see the file formats. Note that the plain text file of number-name substitutions is a separate file, not a section of the optional configuration file, and also note that you must enter the numbers exactly as your VoIP provider sends them (in other words, if they send 8005551234 and you use 18005551234 or 800-555-1234 it will NOT match!).

Starting in Version 0.91 you can use a plain-text file of number-path/file substitutions, so (for example) if calls from a particular number are always from Uncle Bob, you can display Uncle Bob’s picture as the icon whenever a call arrives from that number. Read the sample config file for more information. Note that the plain text file of number-path/file substitutions is a separate file, not a section of the optional configuration file, and also note once again that you must enter the numbers exactly as your VoIP provider sends them.

Version 0.92 sets a rather short timeout on page fetches (still much longer than should be necessary to get the data), in an attempt to resolve a problem where very occasionally the script would just go into a coma, not exiting cleanly but still using memory and CPU cycles, without doing anything useful. I have been running this version for over six months now and have yet to see the script go into a coma, as it often seemed to do in previous versions.

(EDIT added September, 2010:) NOTE regarding EXPERIMENTAL version to work with Growl for Windows. You should still download the main archive to get the instructions and such, but if you’d prefer to use Growl for Windows rather than Snarl, you can try this experimental version of the script. If you do try it, please let me know if it works as expected (and thanks to Andy Singh for his help with getting this working under Windows 7). Please read the Perl source code to find the module requirements (mentioned on or near line 15 of the script) as they differ slightly from the Snarl version.

Linksys and Sipura adapter users – check your RTP Packet Size and Network Jitter Level

Important

Edit: Reader Christopher Woods notes in a comment that the following is also applicable to at least some models of Linksys phones, e.g. SPA942 and SPA962.

Do you use a Linksys or Sipura VoIP adapter? Do the people you are talking to ever complain about your voice breaking up, or missing or dropped syllables, or unexplained clicks or noise?

There is an obscure setting in Linksys/Sipura VoIP adapters that is usually set incorrectly for most applications, at least on a factory-fresh adapter. Go to the SIP tab and check the RTP Packet Size – for most users, it should be set to 0.020 rather than the factory preset of 0.030. If you are running a connection where latency is critical (say you have a cable or satellite box that requires a phone connection to “phone home”, or you are trying to use a FAX machine) then you may even wish to set this to 0.010, which further reduces latency, at the expense of using a bit more bandwidth. In any case, the default 0.030 is not the correct setting when using the most commonly-used codecs. For more discussion of this issue, see this thread at DSLreports.com, which discusses how the RTP Packet Size and Network Jitter Level settings can be tweaked to achieve lower latency, along with the tradeoffs.

Be aware that the RTP Packet Size setting is found under the SIP tab, and that setting is applied to all lines served through that adapter. However, the Network Jitter Level can be set individually for each line, under the Line tabs. One interesting comment in the above-mentioned thread is that if a provider forces you to use a low-bandwidth codec, decreasing the RTP Packet Size may increase the quality of your calls, but again at the expense of increasing bandwidth used.

Changing the RTP Packet Size on one VoIP adapter resolved a few strange issues with audio quality. In this case the adapter was being used to connect to an Asterisk box on the same local network, so bandwidth usage wasn’t an issue. We set the RTP Packet Size to 0.020 and the Network Jitter Level to low, and it made a noticeable difference in the reduction of strange noises and breakups heard by the party on the other end of the conversation. However, changing the Network Jitter Level isn’t as critical as changing the RTP Packet Size, and in fact, changing the Network Jitter Level may be entirely the wrong thing to do on certain types of connections (probably not a good idea if your adapter is connected through a Wireless ISP, for example).

I must thank Paul Timmins for being the first to point out that the Linksys PAP2 has a default packet size of 0.030, which is incompatible with the uLaw (G711u) codec (or at least in violation of the standard). With that lead, I then discovered other articles (including the discussion thread linked above) that said essentially the same thing. So check those adapter settings, folks!

(And by the way, this advice probably does apply to some other makes of VoIP adapters, and even some IP telephones, but since I don’t have any readily available to look at, I can’t say for sure. If you know of any others that need to have a similar setting tweaked, please feel free to add a comment to this post).

TechNotes

My Personal Notes You Might Find Useful

Category: VoIP

Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 1

Like this:

Review of OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner (Packt Publishing)

Like this:

Review of Ring Voltage Booster II™ from Mike Sandman Enterprises

Like this:

BETA Perl script for Caller ID popups when using Linksys/Sipura devices

Like this:

Linksys and Sipura adapter users – check your RTP Packet Size and Network Jitter Level

Like this:

Recent Posts

Recent Comments

Archives

Categories

Meta