Archive for June, 2009

Lost channels in the DTV transition? Look up — there’s free TV out there!

For those in the television backwaters — the places that have lost one or more network TV signals due to the switch to digital television — there are alternatives, in a little known form of satellite television.

It’s kind of like one of those “good news, bad news” jokes.

The good news is that there are dozens, even hundreds of television signals available absolutely free, and the reception is almost always crystal clear. As long as you have a clear view of the southern sky, and aren’t prohibited from setting up a satellite dish (if someone — landlord, homeowner’s association, zoning authority, anyone — tries to tell you that you are prohibited from having a dish, that prohibition may be illegal under federal law), all that television is yours for the viewing.

The bad news: There are many “catches”.

First of all, don’t expect to get the equivalent of cable or commercial satellite TV.  While there are a handful of cable channels that will occasionally become available for short periods of time, most of the stations are the sort you’d find on low-power local television stations, or on the secondary channels of local HDTV stations (those channel-02 and channel-03 channels, for example). Many are in Spanish, or some other foreign language.  If you are really lucky, you might pick up a major network feed, but if you do, you probably don’t want to tell anybody, because if too many people find out, that channel will almost certainly disappear.

And that’s the biggest rub with this service — unless you’re really good at scrounging used equipment and figuring out what needs to be done to make it usable with the free signals, you’ll spend at a minimum two to three hundred dollars to get a working system going, and even more if you want to receive signals from multiple satellites or if you want to receive true HDTV signals (note that almost all satellite television is digital these days, but not all of it is in high definition). And once you have spent all that money, the stations you enjoy today could be gone tomorrow.

There is an apocryphal story that went around in the satellite forums — a cable television company in Alaska fed several of the Anchorage TV stations to one of the satellites in the clear, presumably for the purpose of feeding this signals to remote cable systems in cities and villages around Alaska. Those “in the know” enjoyed these stations, particularly viewers in the Eastern half of the U.S., because they provided the west coast feeds of all the major networks. That much I know to be fact, everything else is just rumor that was floating around the satellite forums a while back.

One day, as the story goes, some bigmouth in a bar was bragging about how he could watch the Saturday baseball feeds from both coasts.  What he did not know was that the president of the cable company was there, and was unaware (to that point) that his technicians were uplinking the signals in a totally unencrypted format that anyone with the right kind of receiver and satellite dish could view, no subscription required.  He overheard the bigmouth, and ordered his technicians to scramble the signal, but that wasn’t the end of it.

As the story goes, FOX got wind of the incident and realized that by feeding games to the East and West coasts separately, some folks could watch TWO MLB games on Saturday, just by changing feeds.  I’m not sure if this violated some contractual agreement with Major League Baseball or what, but all anyone knows for sure is that in subsequent seasons, they started doing all Saturday baseball feeds starting at 4:00 PM Eastern nationwide – no more 1:00 PM games for the Eastern and Central time zones.

So the lesson is, you could spend considerable $$$ on receiving equipment, but that doesn’t guarantee there will be anything you want to watch. Here today, maybe gone tomorrow, and loose lips sink channels.

What about the legality?  Well, I am not a lawyer, and I’m definitely not going to give you legal advice.  But to the best of my knowledge, no one in the United States has ever been prosecuted for watching unscrambled signals.  The thinking in the U.S. seems to be that anyone with a signal they want to protect has some duty to mitigate losses, by employing some form of encryption. I’m sure that certain content owners would disagree about the legality of watching just any unscrambled signal you happen to find, but I don’t think any court would be too sympathetic — and besides, are you really going to run around telling everyone just what you’re watching?  Assuming you’re not drunk and shooting your mouth off in a bar somewhere, that is.

However, in the past there have been unscrupulous people who have sold “hacked” receivers that pick up signals they are not supposed to be able to receive without paying.  If you buy one of those, you are an idiot.  Why?  Because those receivers will not continue to pick up those signals indefinitely, because companies change their encryption methods from time to time. So, after a while you’ll have to go back to the guy you bought it from and see if he can unlock it again, assuming you can even find him.  But chances are, the FBI or some other government agency will find him first, and will obtain his customer list, and next thing you know they’ll be at your door and you’ll be charged with theft of service, a federal felony. There is a HUGE difference between watching the unencrypted signals that are freely available, and using “hacked” equipment to try and receive signals that are encrypted. Try the latter and you may be doing most of your TV viewing on a communal TV in an inmate recreation area.

Most people who watch the free, unencrypted satellite TV realize that the hackers are a menace to the hobby. The last thing they need to to be labeled “pirates” and lumped in with those who just want to steal signals. So on many of the online satellite forums, any request for information on hacking a receiver will likely get you banned for life. That’s no small thing, considering that there are very few good sources of online information on the subject.

One of the best sources of information is the Free To Air (FTA) Discussion forum at SatelliteGuys.US.  And make no mistake, if you really want to explore this, there’s a learning curve.  For one thing, satellite dishes have to be aimed fairly precisely – getting just “sort of close” DOES NOT count.  For another thing, satellite signals don’t pass through solid objects of any kind, particularly trees with leaves or needles on them.  Even a small branch with four or five leaves can cast a shadow across a dish that will reduce the received signal to a point where it’s unusable.  And, for the most part, you can’t just take an old Dish Network or DirecTV dish and reuse it (although if you have an old PrimeStar dish, that will work, and the larger sizes of those dishes are much valued by those who view these free signals). You will need to learn about setting up a dish (best to use a pole in the ground set in concrete — with a satellite dish, additionl height does not get you more signal, but makes it a lot harder to clear accumulated snow off the dish in the winter, something else that can interfere with the signal), grounding the dish, aiming it at the desired satellite, and getting the signal to the receiver.

Still, for those who are into technical things, there’s nothing quite like the thrill of getting your first free TV signal from the sky! And unlike the shortwave radio signals that excited our fathers and grandfathers, these signals rarely fade out, so once you’ve “peaked” the signal you can watch the stations on that satellite until you get sick of them or they go away, whichever comes first. And with many people losing free “over the air” television due to the DTV transition, now might be the time to explore the world of Free To Air television, if you are so inclined (and are not adverse to the risk of spending money on equipment that may not be usable after some period of time).

Just one thing, DON’T call your local TV antenna installer and ask him to come out an install one of these systems – unless he’s also into this, he’s probably not going to know what the heck you are talking about. This is definitely a Do-It-Yourself project for most folks. Commercial installers know about commercial systems, like Dish Network and DirecTV, and they would be happy to install one of those systems for you.  My only advice with regard to those services is, seriously, make them put the dish on a pole in your yard, unless you like leaks in your roof, unsightly cable runs, and no TV after a wet, heavy snow (unless you climb up on a wet, slippery roof to clean the snow off the dish). Installers hate pole mounts because they have to make two trips (one to mix and pour the cement, then a day or two later to finish the install) so you may have to put your foot down and say “no yard pole, go away and I’ll get someone else, because you’re not putting a dish on my roof!!” But just remember, even if your roof doesn’t leak immediately after an install, that just means it’s going to take a while for the leaks to form — but once they do, what do you think your chances will be of getting that installer to come back and fix the damage?

Anyway, I’m not trying to talk you into this.  Most people who read this article won’t pursue Free To Air satellite any further, and that’s fine – too many users might hasten the departure of the remaining free (unscrambled) feeds. But on the other hand, too few users and it’s not worth it to the equipment manufacturers to build and market the receivers. So if you are truly interested, check out the forum mentioned above, and the sponsors on that site (and also the Global Communications site, run by an enthusiast and equipment dealer in Wisconsin).

Leave a Comment

Comment on Michael Jackson’s death

As if you haven’t read enough already, right?

Normally I’m not a person impressed by celebrities. I remember one time, when I was much younger, helping a friend out with a show that was essentially an opening act for a private birthday party for someone who was very big in the motion picture business (people today might not recognize the name, but let’s just say he was a huge name in the 30’s and 40’s, and this was like his 80th birthday party, if I recall correctly).  It was held in the Palmer House in Chicago, another institution that had once been huge, but was already past its prime. There were some big name celebrities there (one big TV star in particular) and everyone was going ga-ga over the fact that all these big shots were around.  And I remember being totally unimpressed – I was so tired from the setup work we’d done that I wouldn’t even go out to see the show. Everyone looked at me kind of funny, but I just explained that those people didn’t impress me, and I meant it.

But I would have gone to see Michael Jackson.  I liked his music.  Unlike most folks, I think I liked him better when he was with the Jackson Five (I didn’t care for “Thriller” much, although the song “Billie Jean” definitely got stuck in my head for a while).

The reason I bring this up is that I remember when I first saw the Jacksons on TV, probably when I was in my late teens, and upon learning that Michael was only eight years old, I remember thinking “this kid has already done more with his life than I will probably ever do with mine.”  And I think it was the first, and maybe one of the only times that I was ever genuinely envious of any celebrity.  Of course, I had no way of knowing that he’d been raised in an allegedly abusive home (I can’t believe that his father is being allowed to take care of his kids, even temporarily!), nor how much he envied “normal” kids. And I certainly had no idea of the paths his life would take, nor how it would end. I suspect that when the dust clears, there’s going to be plenty of blame to go around for who caused his death (see this article from the U.K. Daily Mail for some additional insight), but probably not enough to pin on any specific individual.

I’ve always said that groups of individuals will do evil that no one of them would do if solely responsible (hence my dislike of large corporations, which are almost always evil to some degree). That was probably the case here. No one person killed Michael, but many people – primarily greedy people – took their toll. It may have been a case of “death by a thousand cuts”, some much deeper than others.

In any case, looking back, it’s obvious how foolish I was to in any way be envious of Michael Jackson. And nowadays, I always wonder why celebrities seems to have so much “clout” with the public. Why can they get elected to public office, even if barely qualified for the job? Why can they address legislative bodies on social matters, delivering their opinions as if they were some type of authority on any subject? Why do people look up to them at all?

If there’s any lesson to be learned from Michael Jackson’s life and death, I think it is this: Although we can appreciate the talent a particular person may have, we should not wish to be them, nor to emulate them. Sometimes it seems as though the bigger they are, the more troubles they have, and the more likely they are to fall into a destructive lifestyle and (sometimes) early death. Not only that, but if they have kids, those kids will always be in their shadow. No matter what Michael Jackson’s kids do, they will always be known as his children, for whatever that is worth. Would you really want that sort of life? I wouldn’t, and most people wouldn’t. Michael was sort of forced into it by the choices his parents made, and by the time he was old enough to make his own decisions, much of the direction of his life had already been set. Would you want that sort of life for one of your kids?

I’m not big on organized religion (to put it mildly), but one thing most major religions teach is that envy is a destructive force. And it really is, but the kicker is that most of the people we envy (celebrities in particular) we probably would not envy at all if we really knew what they were going through. Is envy driving your life, or your aspirations for your children’s lives? Just something to think about.

Thank you, Michael, for all the great music.

Comments (3)

Mac OS X: Lean on Lingon to launch scripts and applications

This is a post that was recovered from another, very short-lived blog.  Since the original seems to have vanished into thin air, I thought I’d repost it here, since it’s still relevant, and links to another article in this blog. Also, it seems that readers like this type of article — whenever I look at my blog stats, articles like this always tend to be among the top posts.

——————————

Lingon is one of those tools that at first blush may seem to be something only a true geek would love, but it’s actually fairly practical. What it does is to allow you to launch scripts or programs according to certain criteria. If you have previous experience with Linux or Unix, you can think of it as a way to set up something similar to a cron job, except that you have more flexibility.

One thing you can do is set up scripts or applications to launch at startup. Now, you may already know how you can launch applications at startup — you go into System Preferences, click on Accounts, and then (while your account is selected) click on Login Items. Once there, you can add or remove applications you want to launch at startup by using the + and/or – buttons. And, that’s the preferred way to launch an application at startup for the logged-in user.

But what if you want to launch an application based on some other criteria, or you want to launch a script of some kind? What if you need an application to start no matter which user is logging in? Or, what if you want to tweak an existing startup item that’s run by the system (as an agent or a daemon) and not by a particular user? That’s where Lingon comes in. Lingon lets you edit and create configuration files for launchd (and maybe you are asking, what is launchd? Well, according to Wikipedia, “launchd is a unified, open source service management framework for starting, stopping and managing daemons, programs and scripts.” Aren’t you sorry you asked?).

To give you an example of how Lingon can be used, we set it up to start the CallerIDpop perl script from the Michigan Telephone, VoIP and Broadband blog. This is a script used with Linksys/Sipura VoIP adapters (and some phones) that, when there is an incoming call, provides a Growl popup showing caller details and the time the call was received (it can also write this information to a log file). Previously we had been using their suggested method of running an AppleScript (saved as an application) at startup, the AppleScript containing the line that actually starts the Perl script. Although this works, it’s a fairly convoluted way to do it and it seems to eat up a lot of system resources. So, we set out to find another way to invoke the script at startup. Here’s how we did it using Lingon (which, by the way, seems to get the script running a lot quicker, and the script itself seems to be running in a more stable environment):

When you first fire up Lingon, you get this screen:

Lingon opening screen

Lingon opening screen

Click the small button labeled “New” (with the + on the button) in the upper left-hand corner, and you get a dropdown as shown here:

Lingon dropdown

Lingon dropdown

We selected “My Agents” because we only have one user account on that system, and didn’t really want the script to have root privileges. You should think long and hard about running anything as a daemon, because if anything goes wrong (whether due to programming error or malicious intent) the script will be running as root and can do just about anything to your system. Having selected that, we got this window:

Lingon main options window

Lingon main options window

As you can see, everything is fairly straightforward. In section 1 you give the agent a name, in section 2 you insert the command just as you would enter it if you ran it directly from a terminal window (or you choose the application to run, if you are running an application), and in section 3 you pick the options you want to use to trigger running the script or application. If you’re not sure about any of the options, click on Help (in the top menu bar) and then “Lingon Help” and it will bring up a PDF file in Preview that explains how to use Lingon. The Help menu also gives you access to the man pages for launchd.plist, launchctl, and launchd, in case you are making changes in any of those files.

Note the “Expert Mode” button in the lower right-hand corner – this shows you the actual XML code, and allows you to write keys and values directly if you are comfortable doing that.

Don’t forget to click the “Save” button at the top when you are finished – we forgot to do that and had to start all over! We sort of wish that the “Save” button were underneath the other three sections, maybe in a section 4!

Unfortunately, to make everything work properly you’ll have to log out and login again, or reboot your Mac, as Lingon will remind you:

Lingon restart warning

Lingon restart warning

Not only can Lingon be used to make your own script or application launchers, but it can also be used to edit existing system agents and daemons. While you normally shouldn’t do this, if you know what you are doing it can sometimes improve system performance. On the other hand, if you don’t know what you are doing, you could render your system totally inoperable! As an example of why you might want to do this, we recommend you see the article, “The Case of the Slow Mac (and how to fix it)” at Maciverse. If you think that your Mac is running a bit sluggish, or if you’re seeing the “spinning beachball of death” a bit too often, this article explains one possible reason, and a suggested fix that’s much easier to make if you use Lingon.

Edit: According to this article, the developer of Lingon is not releasing any more new versions.  But you can still download the most recent version here.

Leave a Comment

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

Continued from Part 3

If you have set up an OpenVPN server on your system and are using it regularly, eventually you are going to want to trim the log file. Webmin actually makes that easy. Simply click on System, then Log File Rotation. You should see a bunch of existing log file rotation rules. Up near the top of the page there’s a line that reads:

Select all. | Invert selection. | Add a new log file to rotate.

Click on Add a new log file to rotate. You should get a page that looks like this:

Webmin Log File Rotation - Add New File page

Webmin Log File Rotation - Add New File page

The main thing here is to get the correct log file path into the topmost text area. The path will be something like:

/etc/openvpn/servers/servername/logs/openvpn.log

I generally keep all the default settings except for these two:

Rotate even if log file is empty? (I set to No)
Ignore log file if missing? (I set to Yes)

But you can do as you wish. The important thing is to make sure that the log isn’t simply allowed to grow forever Set it up as you like, click Create, and you’re through.

And now a note for FreePBX and Asterisk users.  When setting up an extension, if you use the permit and deny fields to enhance security, the correct way to fill these out may not be intuitive. For example, if you do sip show peers from the CLI, an extension at the client end of the tunnel may show up with an address in the range of addresses assigned by the client router (such as 192.168.5.x) and yet when you fill out the permit field, using that address may not work.  Asterisk’s log file will generally tell you the address it wants to see, and in our case that was 10.8.0.10! No, I don’t know why, but just wanted to give you a “heads up” on that one.

Deny and Permit fields from FreePBX extension page

Deny and Permit fields from FreePBX extension page

If you have followed this series thus far, I should point out that these articles are not static – if I find a mistake, or a better way to do things, they may get changed. On the other hand, since this particular router probably won’t be in my possession much longer, it may be something that I don’t do much more work on.

One thing I had said I would do in this last article is to give you a list of links that I found useful, or at least interesting, while working on this project. I didn’t actually utilize the information in all of these, and some are even a bit off-topic for the subject at hand, but this is just a small fraction of the pages I went through while trying to get this to work:

OpenVPN HOWTO

OpenVPN FAQ

OpenVPN 2.1 man page

The ‘Point and Click’ Home VPN HowTo Guide (this was one of my primary sources)

OpenVPN: Building and Integrating Virtual Private Networks (book)

Tomato’s Frequently Asked Questions & Tips

Tomato (firmware) page at Wikibooks

An Easy Guide to Installing Tomato on the Asus 520gu

Teddy_bear’s Tomato 1.25 ND USB + FTP/Samba Mod (In my opinion the best firmware mod for Asus WL-520GU – be sure to get the VPN version)

Keith Moyer/SgtPepperKSU’s VPN build with Web GUI (also a great version, particularly if your router isn’t supported by the above version)
His blog

thor2002ro’s SDHC | SNMP | VPN | USB Mod (includes features from both of the above versions plus some additional features, but note that latest versions won’t run on routers with insufficient memory).

Summary of OpenVPN settings in Tomato Firmware

Tomato Firmware forum

Setting Up A Low Cost NAS Using Tomato

Using Tomato QOS

Did I configure QoS VoIP correctly? (message thread)

QOS for SOHO VOIP Solved, Tomato Firmware

Optware installation instructions (supposed to also work with Tomato firmware, potentially allows use of numerous software packages originally written or converted for Linksys NSLU2)

Linux 2.4 NAT HOWTO

OpenVPN IPv6 Tunnel Broker Guide

OpenVPN client configuration for Windows, Linux, Mac OS X and Windows Mobile for Pocket PC

Installing a Virtual Private Network with OpenVPN

USB disc partitioning utilities available.

“A set of disk utilities that will execute on a Tomato router. With these utilities you can now create ext2 partitions on a USB drive on the router itself, so you don’t have to use a Linux desktop machine to do it anymore.”

“A brief help file is included.”

Download link (filename is “tomato_dskutils.tgz”)
Direct link

And there’s probably plenty of other great links that I’ve missed.

Finally, one more word about the TAP/TUN issue. I would sort have liked to have gotten this working in TAP mode. However when I tried to set it up, OpenVPN (on the server) complained about a missing brctl file. Well, it turned out that the way to get that file was to do yum install bridge-utils – sounds easy, right? I assure you, absolutely nothing about this project was easy, at least not for me.

The problem was that after I had installed the software and switched both sides from TUN to TAP, and then restarted the OpenVPN server, it brought down the entire local network! I mean to tell you, I couldn’t connect to any web pages or do anything else until I physically killed the power to the server box! When I brought it back up and disabled OpenVPN, everything connected to the LAN worked fine again. When I uninstalled bridge-utils and went back to using TUN, the tunnel started working again. I had been up all night, it was coming up on 7:00 AM, and I was just so doggone frustrated by that point that I never even tried to get TAP working again. Besides, I just don’t like doing things that can bring down the entire network. I suspect it was doing some kind of packet flood thing, sort of a denial-of-service attack on my local network – pardon me if I’m not thrilled about the prospect of trying that again!

After some additional online research, I suspect that part of the problem is that after installing bridge-utils, you need to create and/or modify certain files, such as /etc/sysconfig/network-scripts/ifcfg-br0, /etc/sysconfig/network-scripts/ifcfg-eth0, and possibly /etc/sysconfig/network-scripts/ifcfg-eth1 (though I’m not at all sure about that last one). For example, one site I went to (which, for some reason, I could only read by using Google’s cached copy, which is why I’m not giving a link) said, “Configure this server’s network configuration to use a bridge as its primary interface. You do this by bridging the physical ethX and virtual tapX interfaces into one logical br0 interface. The br0 interface will be assigned an IP address, and not the physical or virtual interfaces.” That site also suggests that those files should read as follows (note that I do not recommend following this advice verbatim, see my comments below):

/etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
IPADDR=192.168.0.50 <— local IP of the server
NETMASK=255.255.255.0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=tap0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes

Please note the above is totally untested at this point, and I’m afraid that the advice to modify the existing files (particularly /etc/sysconfig/network-scripts/ifcfg-eth0) may (or may not) be ill-advised. What concerns me is that the /etc/sysconfig/network-scripts/ifcfg-eth0 file seems to contain a lot of essential information that is in effect being thrown out – for example, on our system, it reads as follows:

DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:xx:xx:xx:xx:xx
ONBOOT=yes
TYPE=Ethernet <— NOTE!! 'Ethernet', not 'ETHER'
IPADDR=192.168.0.50
NETMASK=255.255.255.0
BROADCAST=192.168.0.255
NETWORK=192.168.0.0
NOZEROCONF=yes

I’m just not sure what is the proper thing to do here — maybe just add the BRIDGE=br0 line to the existing file? But, if you do decide to try a full replacement of any file, be sure to copy the existing file to a safe location so that if things go badly you can recover your original file!

Some of the comments I have read suggest that TAP mode is not as efficient in transferring data, and/or not as secure (unless you add even more configuration options), so I’m thinking maybe we should leave well enough alone. But, if you have a truly burning desire to get it going, I suggest using the following Google search string for additional information – it may be strange, but it actually produced the most relevant results of all the searches I’ve tried over the last few days:

“/etc/sysconfig/network-scripts/ifcfg-br0″ OpenVPN

Hopefully this page won’t show up as the first result! :)

If you have any ideas about what went wrong, or in particular, if you manage to get this working in TAP mode, I’d be most interested to hear about it (and how you did it, if you got it working) – the comments are open.

Here’s another bit of information that may be useful for those of you that don’t know much about Linux — here is a very small list of Linux commands that may be useful in diagnosing any problems with your VPN tunnel:

  • ifconfig – shows the current list of  network interfaces.  On both ends of your tunnel you should see a tunx interface when the tunnel is operational. On Windows-based systems a similar command is ipconfig.
  • ip route show – shows current routing information for the system (see also route). ip route list gives a slightly different view.
  • iptables -L – lists the current iptables rules. Add the -v option to get a more verbose display.
  • netstat -r – similar to route but with a slightly different view.
  • ping address - tries to get a response from another connected machine or device.  Note that not all systems or devices will respond to pings.
  • route - shows the current routing tables on the system (see also ip route show).
  • tcpdump -n – this shows a running display of all activity on the network interfaces.  Be careful because this can produce a LOT of output very quickly.  Use Control-C to interrupt, then be prepared to wait until the buffer empties (may take a few seconds.
  • traceroute address – If you run a traceroute to a network address (either on the LAN or on the Internet) it will attempt to show each system the packets pass through on the way to their destination. This can be useful for determining if traffic to a particular destination is actually going through your tunnel. On Windows-based systems use tracert (a holdover from MS-DOS days when filenames were limited to eight characters!).
  • which program-name – not a network command per se, but if you get an error message about a missing program, you can use which program-name to try to determine if the program exists on your system, and the correct path to that program.

Note that there are additional options for most or all of the above commands – read the man page for that command (e.g. man tcpdump) if you are interested, or use a search engine to find more information (yeah, I think most man pages are painful, too). man is short for manual, by the way, not a reference to gender.

Anyway, I’m still trying to catch up on lost sleep, but if I think of anything else pertinent I’ll probably add it to this article, rather than making this series any longer. I hope if you attempt this, it’s not nearly as painful for you as it was for me!

Leave a Comment

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

Continued from Part 2

Okay, time for the hard part… well, at least it was for me.  Please understand, the instructions at The ‘Point and Click’ Home VPN HowTo Guide, combined with the knowledge I acquired from the book OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner, enabled me to get a tunnel going using a software client with no sweat. But getting it to work with the Tomato VPN client, and in particular, to get it to work the way we needed it to, was a whole other thing. It turned out, as so often happens that some simple configuration changes were all that was needed – but finding the correct configuration changes to make were pure grief.

I want to digress just a moment to speak about those elitists that seem to frequent certain forums and IRC channels, and just love to tell newbies (often in not so polite terms) that all the answers can be found by using Google. I’ve pretty much figured out that most of the time, the person saying that doesn’t know the answer either, but they are like the schoolyard bully that gets their kicks by picking on others. In this case, Google may have had the answers somewhere, but they sure weren’t showing up in the first few pages of results. Instead, what was showing up was many others who were having the same problems and asking the same questions, but not getting answers! And usually after the first four or five pages of results, the results became even less relevant, if that were possible. Finally, after taking a more or less scattershot approach to seeking help, I came up with a “recipe” that works in this situation. Of course I cannot guarantee it will work for you… heck, I can’t guarantee it will work for me next week… but at least it’s working as I write this. But the next time someone suggests that you should just Google it (or something like that), I suggest you ask them what search terms they would suggest using that will bring you the answer to your question. When whatever they suggest doesn’t work, let them know and ask for more suggestions, and just keep repeating until you find the answer or they get sick of talking to you. If we all did that, I suspect some of the online bullies would discover that maybe they should keep quiet if they don’t know the answer.

Okay, so to begin, let’s make sure we are all on the same page. I assume you’ve installed the Webmin OpenVPN + CA module (again, following the instructions at The ‘Point and Click’ Home VPN HowTo Guide) but if you had difficulty locating the module, try here — as I write this, it appears that the newest version of the module is the OpenVPNadmin WebMin pre-release 2.5 version. And when you try to download it, if you get “Unauthorized access to downloads!”, try a different browser, or make sure JavaScript and cookies are enabled.  You will probably need to download it to your computer first, then upload it to Webmin, if your experience is anything like mine was.

When you go into the module, you’ll initially see a page like this:

OpenVPN administration page

OpenVPN administration page

This is “home base” for this module, so when I say “return to the admin page”, this is the page I mean. It’s also the page you use to create a new Certification Authority (normally you only need to do that once, but if you really want to you can make more). In the upper left corner there is a link labeled “Module Config” – click on it and make sure all the paths are correct:

OpenVPN + CA configuration page

OpenVPN + CA configuration page

A couple notes on this page:  First, although it indicates that “Server Hint for Clients” is a required field, there is no indication of what actually goes there, nor any default value.  Second, the information under “If you use bridge device” is only applicable if you use TAP mode (remember, we’re using TUN), but I do know the defaults are not correct.  Just in case you ever want to try to get TAP mode working, here is what these paths should be (at least on our installation):

Command to start Bridge:
/usr/libexec/webmin/openvpn/br_scripts/bridge_start

Command to stop Bridge:
/usr/libexec/webmin/openvpn/br_scripts/bridge_end

Path to DOWN-ROOT-PLUGIN:
/usr/share/openvpn/plugin/lib/openvpn-down-root.so

Do check the paths on this page, because the defaults aren’t totally correct.  Now let’s return to the admin page.  I probably should have mentioned that you don’t really need to change any of the defaults for making a certificate for just your own use – those values are probably only important if you are creating a certificate that will be used by the public.  Once you have made a certificate, you can click on the Certification Authority List, where you’ll see this page:

OpenVPN Certification Authority page

OpenVPN Certification Authority page

I really don’t know why you can create a new Certification Authority on both this page and the main admin page, but oh well… once you have created one it will show up in the list at the top of the page.  You can click on it to view what you created, but there’s nothing you can change there. The main thing of importance is the “Keys List” link, where you can actually create new keys and view existing ones:

OpenVPN key list and key creation page

OpenVPN key list and key creation page

Okay, now here’s the important thing to remember about key creation: You need one key for your server, and one key for each client.  You will note we have a server key, and client key for the software client (used for testing) and one more for the OpenVPN client on the Asus router.

As you may have surmised, except for the key name field, you can leave everything else at the defaults. However, there is one thing on this page that will lead you astray.  It says, “Server key doesn’t need password!“, which might lead you to think that a client key does need one, but that’s not true.  And if you use a password with your Tomato-based client key, you will never make a successful connection.  The keys are far stronger protection than passwords anyway, so the only reason you might even consider using one is for a software client where you want to keep anyone other than an authorized user from connecting to the VPN tunnel.  Anyway, don’t use a password for your server key or your Tomato OpenVPN client key!!!

Okay, now it’s time to navigate back to the admin page, then click on “VPN list”. Once you have created a server key, you can create your actual server. So click on the New VPN Server button and a page will come up that permits you to create a server configuration.  This is where things get really tricky.  Here is how ours is filled out:

OpenVPN Server page

OpenVPN Server page

Now the above is actually the edit page you get once the server is created and you have returned to edit it.  Note that some values cannot be changed after the initial entry, so be sure you get them right the first time.  In particular, make sure to select tun and not tap. If you do make a mistake, you can always delete the entire server configuration and start over, but that’s a bit of a pain. There are some differences in our configuration and the one at The ‘Point and Click’ Home VPN HowTo Guide, and generally speaking there are good reasons for the differences. But that said, nobody is claiming our configuration is perfect, just that it works! If you see something here you think should be changed, feel free to leave a comment.

Note in particular the text fields at the bottom of the page. Getting those right is the key to making this thing work! So, here’s what’s in each of those:

Additional Configurations:

push “route 192.168.0.0 255.255.255.0″
push redirect-gateway
push “dhcp-option WINS 192.168.0.50″
script-security 2 system

up (script execute after VPN up):

route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.8.0.2 tun0
echo 1 > /proc/sys/net/ipv4/conf/tun0/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

down-pre (script execute before VPN down):

route delete -net 192.168.5.0 netmask 255.255.255.0 gw 10.8.0.2 tun0

Of course, in the Additional Configurations section you want the line push “dhcp-option WINS 192.168.0.50″ to point to a WINS server on your network, if you have one (if you don’t, just leave that line out).

In the up and down-pre scripts, if you want to be able to reach the local network behind the WAN port of the router on the client side, you should add additional route add and route delete lines in a format similar to those above, but substituting that network’s address range.

Now, once again, I’m NOT saying this is a perfect configuration, just that it works for us. However, if you notice something that just doesn’t look right, feel free to leave a comment. Much of the added configuration was put in so that traffic from the primary LAN to addresses in the 192.168.5.x address space would actually go through the tunnel – that was the hardest part. It was (relatively) easy to create a tunnel in the first place, but getting packets to and from their intended destinations was another matter entirely.

When you have configured your server and clicked “Save”, it should show up in your server list:

OpenVPN Server List page

OpenVPN Server List page

Now click on “Clients List” – there will be a button labeled “New VPN Client” (no screenshot, it’s just a button to click at this point).  Click that button and you will be presented with a client configuration page.  Here’s the one we created for our Tomato OpenVPN client running on the Asus router (again, this is actually the edit page, since the client is already created on our system):

OpenVPN Client Configuration page

OpenVPN Client Configuration page

Most of the settings here will be the defaults but there are two things to pay particular attention to:  First, the “Remote IP” must be the external address of your server – remember that this is the configuration that goes to the client. And second, notice the ccd file content box at the bottom – it is crucial that this be filled in correctly. In our case, we used this line:

iroute 192.168.5.0 255.255.255.0

If you miss this – and I speak from experience on this one – the packets from the Internet or your local LAN just aren’t going to get back to the client end of the tunnel! And remember to add an additional, similar line if you also want to be able to reach the network connected to the WAN port at the client router, substituting the base address of that network for the 192.168.5.0.

Once you have saved this, it should appear in the VPN client list:

OpenVPN Client List page

OpenVPN Client List page

Once you have configured a client, the next step is to export its configuration, particularly the certificate and key files, to your computer using the “Export” link – all the necessary files will be packed up in a ZIP file.  The instructions at The ‘Point and Click’ Home VPN HowTo Guide tell you how to use this file with a software client, but with your Tomato firmware you will have to unzip the file and then open each of the three files (ca.crt, plus the client certificate and key files), in a text editor or viewer. Only those three files are used with the Tomato OpenVPN client; the others in the ZIP archive are not. Then you will need to cut and paste the contents of those files into the three fields that appear under VPN Tunneling | Client | Keys tab in the Tomato firmware (see the screenshot of that page in Part 1 if you’re not sure what file’s contents goes where). With regard to the Client Certificate, there is some extra information at the top of the file that does not need to be pasted into the text field – you only need the two lines —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– plus all the lines in between those two tags. On an Asus WL-520GU router it doesn’t matter much, but there have been cases with some other makes of router where leaving that excess information in was just enough excess data to “brick” the router! So if in doubt, leave the data above the —–BEGIN CERTIFICATE—– line out.

Once you have everything ready, you can go to the OpenVPN admin page in Webmin and start the server, then in your Tomato firmware start the client.  HOPEFULLY the client and server will connect and start communicating.  You can check from the server’s  admin page by clicking on “Active Connection” – hopefully you will see something like this:

OpenVPN Active Connections page

OpenVPN Active Connections page

If you do, congratulations! If not, you have some troubleshooting to do. On the server, take a look at the log file: /etc/openvpn/servers/servername/logs/openvpn.log. On the client, click on Logs (under Status in the left-hand menu) and look at the last several lines. OpenVPN usually doesn’t suffer in silence — when something isn’t working, chances are one or both logs will be filled with messages that may or may not be helpful. You can always try going to Google and using OpenVPN plus the actual error message text (enclosed in quotation marks); once in a while that will actually bring up something useful.

Still stuck? My plan is to add a Part 4 to this series, that will provide links to some of the most useful resources I’ve collected along this journey.  But you can certainly help — if I’ve made any errors in these instructions (not at all unlikely given the sleep I’ve missed during this project), and you find them and can figure out what was incorrect, PLEASE leave a comment. I will warn you that writing to me with your error message will probably get you nowhere – I can definitely play the part of the blind leading the blind, so to speak, but first I have to heal from all the bruises encountered on this journey! :)

I sincerely hope these posts have been useful to you! In Part 4 I’ll wrap this up with brief instructions for rotating the log file so it doesn’t grow forever, provide the aforementioned list of links, and give you a bit more insight into why I set this up using TUN mode even though I’d probably have preferred to use TAP.

Leave a Comment

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

Continued from Part 1

Before you can begin to set up the OpenVPN server, there is some preparation work that needs to be done. But first, let’s talk about the prerequisites and assumptions we are making here. In the case of the tunnel I was helping to set up, the OpenVPN server was located on a box that runs the Elastix PBX distribution, which includes the CentOS operating system, plus FreePBX and Asterisk and a few other things. It doesn’t really matter whether the box has other servers on it (of course, if it’s a really old/slow box there may be performance issues), but for the purposes of our instructions here, the most important thing is that you have Webmin installed.  Let me repeat that loud and clear:

You MUST have Webmin installed to use these instructions!

You don’t have Webmin installed and you don’t want to install it? Fine, shoo, away with you then. There are hundreds of other installation guides on the Internet, go find one you like.  You have to keep in mind that with me, whenever there’s a choice between using the Linux command line or manually editing a configuration file, and using a nice GUI, I’ll pick the GUI every time.  Some people (usually long time Linux users) seem to have some philosophical objection to using Webmin – if that’s you then you’re obviously much too smart to need these instructions, so what are you doing here?

I’m going to assume you already have Webmin installed, but if you don’t, try doing yum install webmin — it might already be in a CentOS repository.  If that doesn’t work, you should be able to do this:

wget download.webmin.com/devel/rpm/webmin-current.rpm
rpm -ivh webmin-current.rpm

Once you get Webmin installed (or if you are using a Debian-based distribution such as Ubuntu) go to The ‘Point and Click’ Home VPN HowTo Guide — we’re going to refer to that document several times, so you may want to keep it open in another browser tab. But for now, just follow the instructions related to installing Webmin, starting (for CentOS users) with the subheading “Access Webmin”.  For now, just follow the instructions in the two paragraphs in that section.  On a Debian-based system, I’d try following the entire document, but I can tell you there are parts missing for a CentOS-based system, so stick with us for a bit.

Another assumption we are making is that your primary network (the one the server in on) has addresses in the 192.168.0.1 through 192.168.0.255 range.  It’s okay if the “0″ in the third octet is some other number (hopefully it’s not 5, because that what we used at the client end) but the main point is that we’re assuming it’s a small network.  If you’re using more than 255 addresses on the primary network it’s not an insurmountable problem, as long as the client end has its own unique address space.

Open the file /etc/hosts.allow at the server – you should see something like this:

ALL : 192.168.0.0/255.255.255.0

If you do, you could change it to the following two lines (note the change in the netmask in the first line):

ALL : 192.168.0.0/255.255.0.0
ALL : 10.8.0.0/255.255.255.0

However,  if there are any addresses in the range 192.168.0.0 through 192.168.255.255 that are normally reachable but not in your LAN — a primary example is a cable modem status page on 192.168.100.1 — you may not want to extend the scope of your local network quite that much. You could use a more restrictive netmask — for example, you could use these two lines, which is what I’d recommend for this project:

ALL : 192.168.0.0/255.255.240.0
ALL : 10.8.0.0/255.255.255.0

That would specify that anything in the range 192.168.0.0 through 192.168.15.255 is on your local network (including subnets on the other side of your tunnel).  Alternately, if you wish to be a bit more precise and/or secure, you could specify the network(s) at the distant ends of the tunnel individually (using a more restrictive netmask), e.g.:

ALL : 192.168.0.0/255.255.255.0
ALL : 192.168.5.0/255.255.255.0
ALL : 10.8.0.0/255.255.255.0

(If you do the latter, you may also want to add a line for the network on the WAN side of the client router, e.g. ALL : 192.168.1.0/255.255.255.0 to be able to reach devices in that subnet from the server side of the tunnel — assuming that won’t conflict with any addresses on your own local network).

You also need to go into your router (the one between the OpenVPN server and the Internet, that controls the LAN at the server end – not the client router running the Tomato firmware) and expand the scope of your local network.  I can’t give you specific instructions for your router, but generally the principle is the same as in the hosts.allow file – in most cases you need to expand the scope of the local netmask to 255.255.something.0, where something is less restrictive than 255 and includes all local nets on both sides of the tunnel, but not your cable or DSL modem’s status page (don’t worry about the 10.8.0.x addresses, your router won’t see those).  I suggest using 255.255.240.0 and then making sure that your local networks on both ends of the tunnel fall within the range 192.168.0.x through 192.168.15.x. The reason you need to change the netmask is so that when something on your primary LAN tries to connect to an address in the 192.168.5.x range (on the other side of the tunnel), your router will send out an ARP probe to find out which device on the network has that address (getting the OpenVPN server to respond is another issue that we’ll cover later). But if you are trying to get to something on the backside of your router (the modem status page being the prime example), you don’t want your router thinking it’s on your LAN – hence the need for care when changing the netmask.

If for some reason you can’t follow my suggestions about local network range, you’ll still need to figure out an appropriate netmask, both for the etc/hosts.allow file and your server-side router configuration.  Fortunately, there are many pages on the Web that will help you – Google the phrase “netmask calculator” (include the quotes) and you’ll find several sites that will help you calculate an appropriate netmask.  Of course, there are limits on this – you’re going to have a much harder time making this all work if all the local networks on both sides of the tunnel aren’t in the 192.168.x.x range (or, more specifically, don’t have at least the first two octets of the LAN IP address in common).

While you are in the router on the server side of your connection, you need to open UDP port 1194 for incoming traffic and point it at your OpenVPN server – otherwise outside connection attempts will never be received by the server. Don’t open the corresponding TCP port – it’s really not a good idea to use TCP for OpenVPN unless you are forced to do so (by an overly restrictive ISP, for example).

You also need to open up the file /etc/sysctl.conf and make sure that the following line is NOT commented out (add it if it doesn’t already exist):

net.ipv4.ip_forward=1

Also, at a terminal prompt, execute the following:

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

While in the terminal, you SHOULD upgrade OpenVPN to the most current version (or install it if it’s not already installed).  Here is how I did that (of course, the release version may change by the time you read this):

sudo rpm -ihv http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-2.noarch.rpm
yum install openvpn

Note that you must use compatible versions of OpenVPN at both the client and server ends, so once you have an OpenVPN tunnel working, it might not be a good idea to just go upgrading the software at one end or the other unless you know the newer version is still compatible with what you’re using on the other end (minor version upgrades are probably okay, but I am not guaranteeing that!).

Now return to The ‘Point and Click’ Home VPN HowTo Guide — you want to find the section headed “Setting Firewall rule(s) to allow VPN web traffic to redirect out eth0″ — now I will just say that you need to follow those instructions, but when setting up the actual rules, I found that only two were really important.  So if I were rewriting their instructions, here is how I’d say it:

First we’ll assume that the firewall is not set up yet so click Reset Firewall. Now we need to add some rules. From the Showing IPTable: dropdown select Packet filtering  (filter) where we’ll create the following rule:

Forwarded Packets (FORWARD)

Accept If input interface is tun0
Incoming interface Equals tun0

Then, from the Showing IPTable: dropdown select Network address translation (nat) where we’ll create the following rule — this is the rule that goes along with the VPN “push redirect-gateway”. This allows the VPN web traffic to be routed out through your connection:

Packets after routing (POSTROUTING)

Masquerade If source is 10.8.0.0/24 and output interface is eth0
Source address or network Equals 10.8.0.0/24
Outgoing interface Equals eth0

Why not add the rest of the rules? Well, if you Reset Firewall as instructed, you don’t need them, because they are specifying default conditions. But if you didn’t want to reset the firewall because you already have some preexisting rules, or if you ever actually decide to go in and configure some more restrictive firewall rules, then you may need some of the other rules listed. There’s certainly no harm in adding the other rules, but I’d rather emphasize the two that are absolutely necessary to get this working, assuming you started with a clean slate.

When you are finished, the two rules pages should look like this:

Firewall rule: Accept If input interface is tun0

Firewall rule: Accept If input interface is tun0

Firewall rule: Masquerade If source is 10.8.0.0/24 and output interface is eth0

Firewall rule: Masquerade If source is 10.8.0.0/24 and output interface is eth0

(I know that at this point, some Elastix and FreePBX users may be wondering if the above would interfere with the operation of fail2ban, in the event they have installed it. As far as I can tell, the answer is no… fail2ban communicates with the firewall in a different way, and unless you add rules that explicitly contradict what fail2ban does, I don’t think there will be any issues. However, I do recommend that you temporarily disable fail2ban, possibly from Webmin’s System | Bootup and Shutdown page, prior to connecting a new VoIP adapter or similar device on the client end of a tunnel for the first time. The reason is that if the device fails to register for any reason, such as a mis-typed password, fail2ban might refuse connections even after you fix the issue, and it might even clamp down on other connections from the client end of your tunnel. So get your devices registered and working, then restart fail2ban. Alternately, if turning off fail2ban makes you nervous, you could open /etc/fail2ban/jail.conf in a text editor, then edit the ignoreip option under the [DEFAULT] section to include the IP addresses or network on the client side of your tunnel — for example, you could add 10.8.0.0/24 and 192.168.5.0/24 as address ranges you don’t ever want to ban.)

Once again, return to The ‘Point and Click’ Home VPN HowTo Guide — now you want to start at the section, “Install OpenVPN-admin module” and continue through to the part entitled “Testing the VPN Server using the OpenVPN client GUI from Windows.” What I suggest you do here is setup TWO clients, one for a soft client you can use for testing purposes, and one that you will use with the OpenVPN client in the Tomato firmware. While you might be able to get a Windows-based client to work using the instructions shown, I can assure you that the Tomato client isn’t going to work until you add a few additional tweaks, which we’ll cover in Part 3. But you can certainly set up and test the Windows-based client if you like, just to assure yourself that the server is actually working.

Just so you don’t spend a couple hours beating yourself up wondering why the server won’t start, I will point out that there’s a glitch in the Webmin OpenVPN module. When you click on the VPN server list and then click on Start to start a server, the server name is supposed to turn from red to black, and the word Start is supposed to turn to Stop. For whatever reason, that doesn’t happen on our server… you can click Start until the cows come home and it still won’t turn black. It probably has something to do with the module configuration itself – for example there’s a setting for PID file path of running OpenVPN processes (*) which by default is set to /var/run, which may not be correct — however, when I changed it to /var/run/openvpn, which does seem to be correct, it made no difference. I just start and stop the server using the buttons at the bottom of the main “OpenVPN Administration” page, which seem to work fine.

Next up, in Part 3: Configuring the OpenVPN server using Webmin (or more specifically, the changes and additions you need to make to actually get it working as expected). More screenshots!!!

Leave a Comment

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

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:

Diagram showing position of "client side" and "server side" VPN devices

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

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.

tomatoIn 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 OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner — see my recent review of this 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

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:

Basic | Identification page

Basic | Identification page

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:

Basic | Time page

Basic | Time page

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:

VPN | Client page, Basic tab

VPN | Client page, 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:

VPN | Client page, Advanced tab

VPN | Client page, 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:

VPN | Client page, Keys tab

VPN | Client page, Keys tab

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

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

Advanced | Routing page

Advanced | Routing page

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.

Comments (2)

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

Cover of OpenVPN: Building and Integrating Virtual Private Networks

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 (Packt Publishing link)

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 book, and the links in this article are not affiliate links (that is, I do not get paid anything because you click on a link, even if the link goes to the publisher’s site).  I did, however, receive a complementary (free) review copy of the book from the publisher, for which I am most grateful – but apparently the Federal Trade Commission considers that “compensation”, which bloggers are now required to disclose. I can only say that I would not write a good review of a sucky book just because I got a free copy (I can’t be bought in that manner, and even if I could, I wouldn’t sell myself out that cheaply!) but still, the FTC apparently wants you to know that I got “compensated” with a free book.

Comments (1)

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 7 – Addendum

Although I have technically finished up the series on the Atcom AG-188N (sold in North America by CIGear), I wanted to open a post to answer any questions or comments that may arise.

One thing that came up in another thread was that I didn’t say much about how the AG-188N unit can be remotely provisioned by a service provider. That’s because I was primarily writing the review from the end user’s point of view. I’m not a provider, and I guess I assumed that any provider that would be purchasing these units in quantity would be talking to the manufacturer or the distributor with questions about provisioning. I can tell you that there is a page explicitly for setting up provisioning, which looks like this:

Atcom AG-188N Auto Provisioning Configuration screen

Atcom AG-188N Auto Provisioning Configuration screen

Here’s what the fields contain:

  • Current Version —  the current version number is displayed
  • Server Address — FTP/TFTP server address
  • Username — FTP server user name
  • Password — FTP server password
  • Config File Name — The name of configuration file
  • Config Encrypt Key — The encrypt key of configuration file
  • Protocol Type — The protocol type used for upgrading — choices are FTP, TFTP, or HTTP
  • Update Interval Time — The AG-188N  will check for a new configuration file at the specified interval
  • Update Mode — auto provision mode — choices are:
    • Disable — Will not auto-update
    • Update after reboot — Will auto update after a reboot
    • Update at time interval — Will auto update at the specified interval

The normal way you’d use this is that you’d first create a “master” settings file by making a backup of the settings from one AG-188N that has been configured the way you want it (that is, with whatever “default” settings you want all users to have).  You’d use “Backup Config” to save this as a plain text file.  You can then open this file in any plain text editor (but use one that preserves the existing line endings, or you may have issues when you attempt to re-upload it). Note the first line of the default file contains this line:

<<VOIP CONFIG FILE>>Version:2.0001

When you change the  configuration file, you should bump the version number — presumably that’s how the unit would know there’s a new version. Then, for each unit, you’d customize the file (changing the values that are unique to each extension), and then save the file to your server with a unique filename and the .cfg extension.  For example, if you had an extension 200, you might name the edited file 200.cfg, and make sure that filename also is placed in the “Config File Name” field in the configuration file itself. You could upload the customized configuration file to the device the first time by using the Web Update page on the AG-188, or if the unit had already been sent to a customer site, you could send them an e-mail with the settings to enter on the above page.

The question was asked, is there a nice configuration tool such as is supplied for some other adapters?  Not to my knowledge, but if you look at the actual format of a configuration file, you’ll realize how easy it would be for any competent programmer to create such a tool. As an example, here’s a sample IAX2 configuration section from the file:

<IAX2 CONFIG MODULE>
Server   Address   :myserver.dyndns.com
Server   Port      :4569
User     Name      :200
User     Password  :securepassword
User     Number    :200
Voice    Number    :
Voice    Text      :
EchoTest Number    :
EchoTest Text      :
Local    Port      :4569
Enable   Register  :1
Refresh  Time      :60
Enable   G.729     :0

All you would need to do is do a search-and-replace on each line in the file — find the values that need to be unique for each extension and then change them.  You could do this using a Bash or Perl or PHP script, or probably any of a number of other scripting languages (you could even do it in BASIC, if that’s the language you’re most comfortable using).  Or you could get fancy and build a database of settings for each extension, allowing you to change values globally (for example, if changing a server name) or for one extension or a group of extensions. If you do that, and you don’t mind sharing it, please post a link in the comments, because I’m sure there would probably be others who would appreciate such a tool.

I know someone will ask, “How do I use the Config Encrypt Key?” And my answer to that is, doggone if I know, but if encrypting the file is that important to you, you’re probably going to be buying in sufficient quantity that you will be talking directly with the distributor and/or the manufacturer, so ask them.  As I said, I wrote this series primarily for end users, and while some end users may want to be able to auto-provision their devices (and there is even some talk of a provisioning tool or module possibly coming in a future version of FreePBX), there are few that would actually need the configuration file to be encrypted, provided that all users are internal and that your FTP or TFTP server (the one used to serve configuration files) is not accessible from the Internet.

Of course, if you have remote users, then you may be concerned about having them FTP or TFTP a plain text configuration file that shows their SIP and/or IAX user name(s) and password(s) with no encryption whatsoever — and if you are not concerned, you probably should be!  For those users, I think I’d at least compress the file with a password (using ZIP or some other format that allows password protection of files), then e-mail the compressed file to the customer, and then use some other medium (such as phone or fax) to get the file password to them.  They can then uncompress the file, and use the Web Update page on the AG-188N to get the .cfg file into their AG-188N.  I realize that’s not very convenient, so if I ever find out how the Config Encrypt Key is implemented, I’ll definitely edit this post to show the information.

Setting up a dial prefix for local calls

Reader Bill asked the following:

I have a couple of the 188N and been trying to get it to prefix 1916 my provider requires all local calls to have a the prefix of your area code to dial local numbers. So far I am failing in how to get this to work.

Can someone point me in the right direction?

Actually, it’s easy, but slightly non-intuitive. In the left-hand menu click on Dial-Peer – again, I know it looks like it’s not a clickable link, but it is. That will bring up the Dial-Peer page, as shown in Part 3 of this series. Now, click the Add button, and you should see this dialog:

Atcom AG-188N Dial-Peer screen: Add rule

Atcom AG-188N Dial-Peer screen: Add rule

You need only fill in the three fields shown here. The Phone Number field contains the pattern for a seven digit call — [2-9]xxxxxx (don’t add a trailing T in this case because you want it to match only if exactly seven digits are dialed). The Call Mode should match the mode you normally use for outgoing calls – I used IAX2 in this example but if you normally use SIP then select that.  In the Alias field, I entered the modification that Bill wants to make to seven-digit numbers — add:1916 to add the leading 1 plus 916 area code. Enter those values, click Submit, then click on Save Config and you should be all set.

There are actually four different keywords you can use at the start of an alias:

add: As shown here, add is used to add a prefix to the phone number, so (as in this example) you don’t have to dial leading prefix digits on local calls.
all: Replaces the number dialed with the number following the all keyword – this is how you can make a speed dial code.
del: Deletes the first N numbers. N is set in the Delete Length field.
rep: Replaces the first N numbers. N is set in the Delete Length field. Typical example: You’re in a country where the international dialing prefix code is 011 but you are using a carrier that expects you to send 00, followed by country code and number.  In the Phone Number field you’d put 011T, then in the Alias field you’d put rep:00, and set the Delete Length to 3. Whenever a user dials a number starting with 011, it will then be changed to 00.

The use of the Dial-Peer page is explained more fully in the AG-188N manual, in the section How to use the dial rule? near the back of the manual.

As I said, this post is intended to be open-ended, in case any other questions or comments about the AG-188N require a response. So if you are interested in this device, you might want to check back from time to time, to see if anything else has been posted.

Disclosure: CIGear provided me with an Atcom AG-188N for review purposes, and allowed me to keep it after I was finished writing this series, and for that I am most grateful.

Previous Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Comments (2)

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 6 – Final Thoughts and Summary Review

In yesterday’s installment of this series we discussed the internal router and other networing capabilities of the Atcom AG-188N (sold in North America by CIGear). The one thing that had me a bit puzzled was the implementation of VPN Tunneling. I’ve since been informed that the UDP method of VPN tunneling was implemented for a specific customer, and only works with that customer’s servers. However, the LT2P method does use standard L2TP, but without IPSec, which means it’s not a secure tunnel (there is no encryption used by default with L2TP). The most likely reason for using an L2TP tunnel would be to overcome NAT firewall issues, if for some reason you can’t use the IAX protocol and must use SIP instead. I’ve since added some information to yesterday’s article that includes a link to a blog post that shows how to setup an L2TP server on a Linux box. I’d still be interested in hearing from anyone that actually gets this working, since I haven’t really had the time to experiment with it yet.

Anyway, here are my final thoughts on this unit:

Let me state at the outset: I’m highly impressed with the AG-188N. Please keep that in mind as you read the paragraphs below, because reviews often tend to focus on areas where a product does not meet the reviewer’s expectations. In the case of the AG-188N, my expectations were met and for the most part, far exceeded. The one area where that was not the case was the documentation, and I’ll talk about that in a moment. But in my testing, this unit performed at least as well as any other VoIP adapter I’ve used, and I actually perceived the audio quality to be better than what I hear when using the venerable Linksys/Sipura adapters.

Atcom AG-188N

Atcom AG-188N

The Atcom AG-188N is a solid, well-built unit in an attractive charcoal-grey case.  It’s very similar in size to the popular Linksys PAP2, and could be a drop-in replacement in any situation where only a single line (phone port) is required. What most impressed me during my testing was that everything I tested worked at it was supposed to, although not always exactly in the same manner as it would on a Linksys adapter (the need to press the star key to complete a 3-way call being one example). The device supports up to two SIP accounts, but in addition it supports one IAX account (something rarely found in a VoIP adapter in this price range), and you can also connect a PSTN line to the PSTN port on the back to use for calls to emergency services, local calls, etc. If a call comes in using any of the supported methods the phone will ring and you can talk, but call waiting does not appear to work “across technologies” (that is, if you’re on an IAX call and a call comes in on one of your SIP accounts, the device will report BUSY rather than giving you the call waiting beeps).

Call quality is excellent, although out of the box the incoming receiver volume was a bit low, but that was easily adjusted in the device’s configuration.  I had no problems using this device with an Asterisk/FreePBX server, it worked as expected and was easy to configure (I daresay easier than the Linksys/Sipura adapters I’ve set up in the past).  It does not have as many configuration options as the Sipura, but the settings that are missing are for the most part ones you’d probably never change from the defaults anyway.  Actually, about the only settings I really wished for that I did not find were the ability to manually tweak certain tones (in particular, the tone that is sent when you leave the accidentally leave phone off the hook — this unit just provides a fast busy signal at roughly normal volume, which isn’t going to alert anyone that the phone is off the hook) but I’m probably the one person in 1,000 that would even care about that.

Honestly, I’m surprised that this unit hasn’t gained greater acceptance among VoIP users and service providers. Probably the greatest drawback of the unit is that many buyers will compare this with the Linksys PAP2 and notice that the PAP2 has two phone ports, while the AG-188N only has one.  But on the other hand, the PAP2 does not support the IAX protocol, and does not include a router with DHCP support and a NAT firewall, not to mention QoS and VPN tunneling, if you can figure out how to configure the latter two. The Atcom AG-188N supports all of this, at a very reasonable price.

The documentation that is provided with this unit, to put it charitably, could be much better.  No printed documentation is provided at all, but the included mini-CD contains documentation on several Atcom products including the AG-188N.  Unfortunately, it’s in .doc format, which may not be readable if you don’t have Microsoft Word (although there are free online services that can convert .doc files to other formats — Zamzar comes to mind, but there are many others). You can go to the manufacturer’s web site to find PDF versions of the documentation, but at least in the case of the AT-188N, that documentation appears to be older than the .doc files on the disk.  You may find that reading the previous articles in this series fills in some of the holes in the documentation.

Two specific issues with the documentation are that 1) it was apparently poorly translated from Chinese, with numerous spelling, punctuation, and syntax errors, not to mention being borderline incomprehensible in a few places (although it’s far from the worst translation I’ve ever seen), and 2) It is silent in some places where it should be more explanatory.  For example, there’s an entire section of the manual on QoS (Quality-of-Service) configuration, but it’s titled “VLAN implement” (so many users would have difficulty finding it) and worse, it really doesn’t explain which of several possible configurations should be used in any given situation.  For example, if you are using VoIP but you also have a computer (or a switch with multiple connected computers or devices) connected to the LAN port, how do you make sure that the VoIP packets get priority?  That’s the sort of thing that needs to be explained in clear, easy-to-understand language.

And, there are some settings on which the manual is inexplicably silent. Worse yet, the entire section on VPN gives such sparse information that I sincerely doubt that anyone could figure out how to set up a VPN tunnel without getting additional clarification. It doesn’t help that they picked two of the most obscure VPN methods to support – one that’s used only by a single customer (though they don’t mention that in the manual) and the other an implementation that you rarely see anymore (L2TP with IPSec is somewhat common, though still not nearly as popular as some other methods, L2TP without IPSec much less so, although in a perverse way that may be a blessing in disguise – everything I’ve read about IPSec indicates it’s kind of a bear to install).  I’m told that Atcom actually has a working OpenVPN implementation, but that it won’t fit in the flash memory and RAM of the device.

But really, none of this will matter to the typical user – there is a Quick Start Guide on the mini-CD that will be enough to get the average user going (or, you could refer to the previous articles in this series!) using IAX or SIP.  Most of the router configuration on the AG-188N is fairly self-evident — if you’ve ever set up a router before, you shouldn’t have any difficulty with the one in this device.  The places where things get somewhat complicated tend to be mostly places where typical users would fear to tread anyway.

If I could make a suggestion to Atcom, it would be this — For the next iteration of this device, please consider the following:  1) Enough memory for proper support of additional VPN tunneling methods, including OpenVPN,  2) More than one LAN port on the back of the unit (I know this will make it a bit larger, but you already have the AT-188N for those who need the smaller form factor) – it would be good to have at least four LAN ports,  3) the ability to select whether each individual LAN port is tunneled or not tunneled (when a VPN tunnel is active),  4) AT LEAST two phone ports, preferably four (if for no other reason than to make your device competitive with all the other two-line units),  5) Simpler QoS setup — build some default profiles for various situations, or better yet, let users assign QoS priorities on a per port basis (phone ports would default to high priority, LAN ports to medium priority, but each could be changed by the user with simple “radio button” selection),  6) A “greener” power supply — the “wall wart” you’re supplying with the AT-188N throws off too much waste heat,  7) And PLEASE, get someone who is a native English speaker to write or edit the English version of your manual (using proper grammar, spelling and punctuation!), and make sure you document ALL the settings on EVERY screen.

But even with whatever faults it may have, I think that any buyers of a single-line VoIP adapter (ATA) would be extremely happy with this device.  It truly delivers more value than you’d expect for such a low price. When the worst thing you can say about a unit is that the documentation could be improved (and how many other products suffer from the same problem nowadays?), that’s really not much of a criticism.

One other thing that surprises me is that the sort of people who like to hack routers and/or network storage devices, and install rewritten and improved firmware, haven’t discovered this unit.  When you consider all the energy that’s been put into modifying the firmware and then developing software packages for a device like the Linksys NSLU2, I’d have to think this device would be at least as attractive for that purpose.  Sure, it doesn’t have any USB ports, but it’s a network connected device, which means that potentially it could store anything too large to fit in RAM on a network-attached storage device.  Maybe the Atcom folks would not appreciate me mentioning the possibility that the firmware could be improved upon, but since the unit does have telnet access I have to think there’s a good chance it’s running some form of Linux “under the hood” — although I could be wrong about that — and I’m just a little bit shocked that those who enjoy digging into the internals of this type of device haven’t (yet) found the AG-188N attractive.

This is a device that really needs additional exposure among the VoIP community, which is one reason I wanted to review it.  Sometimes it’s hard to get “word of mouth” going on a new device, but in my opinion this one deserves it. It’s a great, well-built device in any case, but with the ability to use IAX protocol and to tunnel its SIP connections via L2TP, you have two ways to handle those tough situations where most other adapters will connect to your server, and you can make their phone ring, but you only get one-way audio (or even no-way audio in some cases).

I’m going to close this article, and this series, with the list of features and specifications for this unit, from CIGear’s web site, but with the caveat that they probably got this from the manufacturer and I don’t believe it’s 100% accurate (just one example: Both this list and the AG-188N manual say that “Reverse polarity” is supported. But there’s no setting to turn it on or off, and I can tell you that it doesn’t appear to be on by default). So if a particular feature is really important to you, look back through the the screenshots in the previous articles of this series and if you don’t see that feature mentioned, there’s a chance it might not be implemented. This is just another example of a disconnect between the documentation and the actual unit.

Features

Enterprise, small office and residential applications

Key features:
Support two sip servers running at the same time.
Redundancy sip server support.
Support T.38 fax function
Support IAX2 protocol
NAT, Firewall.
DHCP client and server.
Support PPPoE, (used for ADSL, cable modem connecting).
Support major G7.xxx CODEC.
VAD,CNG.
G.165 compliant 32ms echo cancellation
E.164 dial plan and customized dial rules
Support Lifeline.
Hotline.
Call Forward, Call Transfer, 3-way conference calls
Call ID display
DND(Do Not Disturb),Black List,Limit List
Reverse polarity
Voice prompt
Increase Vlan and automatically upgrade configuration file encryption function
support IAX2 and FAX
Increase the time zone function

Data Features
Static/Dynamic WAN IP Addressing
PPPoE

Management
Web, telnet and keypad management.
Adjustable user password and super password
Upgrade firmware through HTTP, FTP or TFTP.
Telnet remote management.
Upload/download setting file
Auto-provision.
Safe mode provide reliability

Interface
Two RJ45 ports, one for WAN, one LAN.
One RJ11 PSTN port for lifeline
One RJ11 FXS port for analog phone.

Data Networking:

MAC Address
TCP:Transmission Control Protocol
DHCP:Dynamic Host Configuration Protocol
PPPoE:PPP Protocol over Ethernet
SNTP, Simple Network Time Protocol
STUN – Simple Traversal of User Datagram …
MD5 Message-Digest Algorithm
DNS:Domain Name Server
RTP: Real-time Transport Protocol
RTCP:Real-time Control Protocol
Telnet:Internet’s remote login protocol
HTTP:Hyper Text Transfer protocol
FTP:File Transfer protocol
TFTP:Trivial File Transfer Protocol

Call control /voip Features
SIP RFC3261,RFC 2543
Tone generation and Local DTMF re-generation according with ITU-T
G.711(A-law or u-law)
G729
AGC(Auto Gain Control)
G.168/165 compliant 16ms echo cancellation
AEC(Auto Echo Cancellation)
VAD (Voice Activity Detection)
CNG(Comfort Noise Generation

Enviromental

Electric requirements
Voltage: 9V ~ 24V
Power adapter: output DC 12V/450 mA

Operating requirement
Operation temperature: 0 to 40° C ( 32° to 104°F)
Storage temperature: -30° to 65° C (-22° to 149°F)
Humidity: 10 to 90% no dew

Regulatory compliance
CE, FCC part 15

Thank you to the folks at CIGear for their patience in answering my questions as I wrote this series of articles!

Disclosure: CIGear provided me with an Atcom AG-188N for review purposes, and allowed me to keep it after I was finished writing this series, and for that I am most grateful.

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Comments (12)

Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter) – Part 5 – Networking and Internal Router

In our previous installment we completed setting up the VoIP portion of the Atcom AG-188N (sold in North America by CIGear), touching on some of the other screens in the process. But there’s a whole other side of this great device that I have avoided touching on until today. If I were a TV infomercial pitchman, this might be the point where I’d take a dramatic pause and say, “You’d think there wouldn’t be anything more that we could pack into this small of a package — but wait, there is more —it’s ALSO a ROUTER!!!” And then the studio audience would applaud on cue!

And when I say router, I mean that it includes a DHCP server, NAT (port forwarding), QoS (Quality of Service), and even some limited VPN (Virtual Private Network) Tunneling support. Now, one reason I’ve sort of avoided talking about this is because of all the things I understand with regard to computing and VoIP, the area where my knowledge is weakest is networking.  The whole process of getting packets from point A to point B over the Internet is sort of a “black hole” for me.  And I’m not one of those reviewers that tries to convince you that I’m smarter than everybody else, and know everything about everything – if you’ve ever taken even one networking class, you’re probably way ahead of me.  So what I’m going to do here is show you the screenshots and tell you what I can, but if I make some wildly inaccurate statement, kindly let me know in the comments, okay?

In Part 2 of this series, I showed you the WAN configuration page.  Let’s take one more look at it:

Atcom AG-188N WAN configuration screen

Atcom AG-188N WAN configuration screen

As you see, you can enter static IP information, dynamically obtain an IP address, or use PPPoE.  Depending on which you choose, you may need to fill in additional information in the text boxes.  Most users will simply pick DHCP to obtain an address from an “upstream” router and be done with it — if you’re like me, you may not understand exactly how it works, you’re just glad it does. But, if you need or want to assign a static IP, or need to use a PPPoE server, you have that ability.  Most VoIP adapters will let you use DHCP or a static IP address, but I can’t recall seeing any others that offer PPPoE support.

As I mentioned in the previous article, the manual is silent on the usage of the “Mac Authenticating Code” field, but the most likely use is for “cloning” the Mac address of another router or computer, in the unlikely event that your ISP actually cares what you plug into their cable or DSL modem.

Now let’s look at the LAN configuration settings:

Atcom AG-188N LAN configuration screen

Atcom AG-188N LAN configuration screen

If you are sending this unit to someone in a remote location and you don’t know whether they are going to plug a computer, a switch, a router, or nothing at all into the LAN port of this device, the default settings are probably the safest – as long as whatever’s plugged into the LAN port gets its address using DHCP, it should work. Providers could send a unit to a customer, knowing that if the customer simply unplugs the network cable from the back of the computer and plugs it into this unit, then uses another network cable to go from this device to the computer, it will still work in most cases (provided they don’t swap the WAN and LAN port connections, anyway).

In the specific case where the WAN port of this device is connected to another router, it’s true that having two routers “stacked” may not be an optimum situation, since you are doing two levels of Network Address Translation (NAT) — therefore this configuration could interfere with certain services (perhaps ironically, one of the things that would be most likely to be affected adversely would be any SIP-based softphone client running on a computer behind the two levels of NAT). But for most typical end users, the defaults are probably the safest if you have no idea what they are going to do on their end.

However, for those who know what they are doing, you can tweak the settings for a more optimum configuration. The available settings are

  • Bridge Mode: You’d probably want to enable this if you know that the AG-188N will be connected to an “upstream” router, rather than directly to a cable or DSL modem.  When this is checked, the AG-188N will not assign IP addresses for devices connected to its LAN port — the AG-188N and any devices plugged into the LAN port will all be on the same network. This would avoid the “double NAT” problem mentioned above. Note that this setting will not take effect until you save the config and reboot the device.
  • IP: The base IP address for the local network. This is also the address that you can use to access the AG-188N configuration pages from devices connected to the LAN port. Normally it should always be in one of the “private” IP address ranges and should always end in .1.  In almost all situations it is safe to leave it at the default — the one exception is if the “upstream” network also uses the 192.168.10.x address range, in which case you might want to change the “10″ to some non-conflicting address. You almost certainly must change this if there is already an upstream device (such as an upstream router) using 192.168.10.1.
  • Netmask: If your IP is in the 192.168.x.x range then leave this at the default.  If you change the IP to something outside that range, I assume you know what needs to be used here.
  • DHCP Server: Enables DHCP service in LAN port. Leave this checked unless you are using “Bridge Mode”, or have a specific reason for turning it off (such as, ALL connected devices use a fixed IP address).
  • NAT: Enables Network Address Translation. Also leave this checked unless you are using “Bridge Mode.”

Note that it may not hurt anything to leave the DHCP Server and NAT enabled when using “Bridge Mode”, but I simply prefer to leave no doubt that we want the “upstream” router to handle these functions. I discovered that enabling “Bridge Mode” does not seem to totally disable the internal LAN, as evidenced by the fact that even though my computer received its IP address from the “upstream” router (in the 192.168.0.x range), I could still access the AG-188N’s web pages on either the 192.168.10.1 address, and that was true even if I disabled the DHCP Server and NAT.  So since I don’t know exactly how things are being handled internally, I just felt it best to tun off those services when running in “Bridge Mode.”

Now let’s look at the DHCP Service configuration page:

Atcom AG-188N DHCP Service configuration screen

Atcom AG-188N DHCP Service configuration screen

I didn’t change anything on this page, and I don’t advise that you do so either unless you know what you are doing. Note that by default, the DHCP server will assign addresses in the range 192.168.10.1 through 192.168.10.30 (with 192.168.10.1 normally being the AG-188N itself), so if you want to assign any device a fixed IP address you’re safe in assigning it anything from 192.168.10.31 through 192.168.10.254 (of course, you’d have to connect the LAN port to a switch in order to connect multiple devices). For the most part the settings seem pretty self-explanatory.  The one thing I didn’t fully understand is the setting for “Update Mode”, which has three choices: None, Update firmware, or Update config file.  I turned to the manual for enlightenment and this is what it had to say:

Update Mode: Using DHCP updated model, None expressed are not updated, Update firmware update firmware is used to DHCP. Update file is used to configure DHCP updated configuration files.

Um, okay then.  Seems like the default choice of “None” is probably right for most users. So, since there’s really nothing to see here (for most users, anyway), let’s move along to the NAT configuration page:

Atcom AG-188N NAT configuration page

Atcom AG-188N NAT configuration page

Again, I didn’t change anything on this page, and most users won’t need to either. The exception would be if you need to map a port to a particular device — this is where you’d do it. Just fill in the blanks for your new port mapping rule, click add, and you’re all set. Under “Transfer Type” your choices are TCP or UDP. Oh, and in case you’re wondering about the first three checkboxes, ALG apparently stands for Application-Level Gateway, and if you click on the link it will take you to a Wikipedia article on the subject.

The Net Service page lets you change certain default port settings used by the AG-188N, and shows you a table of all devices that currently have DHCP leases:

Atcom AG-188N Net Service and DHCP Lease Table screen

Atcom AG-188N Net Service and DHCP Lease Table screen

Most users will not want to change any of these, and I certainly would not advise doing so, but you can if you really want to. If you change the HTTP port and then forget what you changed it to, you probably will not be able to access the Web interface, so be careful here!

The next page we’ll look at is the QoS page:

Atcom AG-188N QoS configuration page

Atcom AG-188N QoS configuration page

QoS stands for “Quality of Service”, and is a method for giving certain packets priority over others. Of all the screens on this device, this is the one of the two that I comprehend the least, and I get the distinct impression that either the author of the manual didn’t fully understand it either, or else felt that anyone changing the parameters on this page would know what they were doing.  Here’s what it has to say about this screen (slightly edited to clean up obvious spelling/punctuation/syntax errors):

AG188 implements QoS based on 802.1p. The QoS is used to mark the network communication priority in the data link/MAC sub-layer.  AG188 will sort the packets using the QoS and send them to the destination.

  • VLAN Enable — Disable/Enable VLAN function
  • VLAN ID Check Enable – not defined by the manual
  • Voice/Data VLAN differentiated — what the manual has to say about this is borderline incomprehensible, but basically you have three choices Undifferentiated, Tag differentiated, and Data untagged. Here’s the actual, verbatim phrase from the manual: “undifferentiated for Date and voice VLAN is not distinction VLAN tag, Tag differentiated for Date and Voice VLAN is distinction VLAN tag, Date untagged for Date VLAN is distinction VLAN tag.”
  • DiffServ Enable — Disable/Enable Diffserv service
  • DiffServ Value — Configure the Diffserv parameter. The permissible range of values is: 0×28, 0×30, 0×38, 0×48, 0×50, 0×58, 0×68, 0×70, 0×78, 0×88, 0×90, 0×98, 0xb8.  The default is 0xb8, which stands for best fast transmission; 28-30 is guarantee for the transmission priority for the 1st rank, 48-58 is guarantee for the transmission priority for the 2nd rank, 68-78 is guarantee for the transmission priority for the 3rd rank, and 88-98 is guarantee for the transmission priority for the 4th rank.
  • Voice VLAN ID — configure the Voice/signaling VLAN ID
  • Data VLAN ID — Assign VLAN id for data stream.
  • Voice 802.1p Priority — Configure the priority of the voice packets in 802.1p protocol.
  • Data 802.1P Priority — Configure the priority of the data packets (non-voice/signaling data) in 802.1p protocol.

There’s also a separate section in the manual on VLAN implementation, which shows several screen captures that will hopefully aid you in setting this up.  Honestly, I’d welcome comments from anyone who can further enlighten me on the correct way to set this up. If you don’t use the LAN port, or if you are not pushing much data through the LAN port while on calls, it’s probably okay to leave this not enabled.  But if you do use the LAN port, and you experience voice breakups and other weirdness while you are on the phone, the best advice I can give you is to try the various sample configurations in the “VLAN implement” section of the manual. If anyone is an expert on QoS implementation, please leave a comment and help us understand the correct way to configure this!

There’s one more networking-related page to talk about, and it’s the other one that I have relatively little understanding of, although I’d definitely like to increase my knowledge.  Let’s look at the VPN Tunnel page:

Atcom AG-188N VPN Tunnel configuration screen

Atcom AG-188N VPN Tunnel configuration page

The AG-188N supports VPN (Virtual Private Network) tunneling using either UDP (apparently a custom format for one specific customer) or L2TP (without IPSec).  Unfortunately, it does not support other popular methods, such as IPSec, PPTP, or OpenVPN.  For those who may not understand why you’d want to use a VPN tunnel, I’m going to quote an excerpt from the Wikipedia article on VoIP VPN here, since it explains this far better than I could (just replace the reference to “IPSec” with “UDP or L2TP”):

A VoIP VPN combines Voice over IP and Virtual Private Network technologies to offer a method for delivering secure voice. Because VoIP transmits digitized voice as a stream of data, the VoIP VPN solution accomplishes voice encryption quite simply, applying standard data-encryption mechanisms inherently available in the collection of protocols used to implement a VPN.

The VoIP gateway-router first converts the analog voice signal to digital form, encapsulates the digitized voice within IP packets, then encrypts the digitized voice using IPSec, and finally routes the encrypted voice packets securely through a VPN tunnel. At the remote site, another VoIP router decodes the voice and converts the digital voice to an analog signal for delivery to the phone.

…..

Security is not the only reason to pass Voice over IP through a Virtual Private Network, however. Session Initiation Protocol, a commonly used VOIP protocol is notoriously difficult to pass through a firewall because it uses of random port numbers to establish connections. A VPN is one solution to avoid a firewall issue when configuring remote VoIP clients. The VPN virtually moves users inside the same network local as the VoIP server.

Edit: Unfortunately, it turns out that the AG-188N uses L2TP without IPSec, which means that the comments about voice encryption in the above excerpt aren’t applicable – L2TP alone does not offer any form of encryption. However, the final paragraph of the excerpt, talking about how a VPN tunnel could overcome difficulties with firewalls when SIP is used, would still be applicable.

Here’s the explanation of the settings on this page:

  • VPN IP — After the AG-188N has registered successfully on the VPN, the VPN server will assign an IP address to the device. If there is a IP address other than 0.0.0.0 shown here, it means that you are successfully registered on the VPN.
  • UDP  Tunnel and L2TP settings — These are obvious from the text field labels. Only fill in the settings for the protocol you plan to use (probably L2TP unless you can somehow reverse-engineer the UDP method).
  • UDP  Tunnel and L2TP radio buttons — Click the one corresponding to the type of tunnel you plan to use.
  • Enable VPN — Enable the VPN server — you must choose either UDP or L2TP type in advance.

Some of you may be wondering – if you set up a VPN tunnel, does all traffic get routed through it (including any traffic on the LAN port), or only VoIP traffic?  And, if only VoIP traffic, will it route both SIP and IAX protocols over the tunnel, or just one or the other?  And unfortunately, I simply don’t know the answer to that at this point.  I also don’t know how to set up a VPN using either UDP or L2TP on an Asterisk/FreePBX server, otherwise I might give this a go. If if any of the more popular forms of VPN tunneling were supported (such as IPSec, PPTP, or OpenVPN) I might be able to set those up and administer them using Webmin, but it appears that there are no Webmin modules available to help configure L2TP or UDP tunnels.

Edit: After receiving some clarification that this uses L2TP without IPSec, I Googled a bit and found a blog post entitled “Use Linux to Setup L2TP Server (without IPSec)” that appears to give server installation and configuration  instructions that should work under CentOS (the opening paragraph is in Chinese, but the actual steps are all in English, and if you’re curious about that opening paragraph you can always view the Google translation). However, I think I’d try using yum install l2tpd rather than using rpm in the first instruction; if that doesn’t work you can always try the rpm method. It looks like it should be a pretty simple installation, but I have not actually attempted it yet.

At this point, this may be my only real letdown with the AG-188N – I was enthused when I saw that it supported VPN, but that enthusiasm rather quickly deflated when I saw that it really didn’t support any of the more widely-used VPN protocols (Edit: and in particular, none that offer encryption). And granted, my disappointment may be in part based on my lack of proficiency in setting up a VPN server, or some other lack of understanding — feel free to enlighten me! — and in any case, my disappointment here is tempered by the knowledge that no other ATA’s (to the best of my knowledge) support any form of VPN tunneling. The vast majority of users of this device are probably not going to care whether it supports VPN or not, let alone which “flavors” of VPN, but it’s just something that had particular appeal to me.

This is a subject I’d obviously like to know more about — some readers may recall my post, New Products Wanted, part 1: Simple VPN devices (switches and/or routers) — so I welcome any comments that might help me set up one of the supported forms of tunneling, especially if there is a web-based GUI administration utility available (sorry, Linux gurus, I don’t share your affinity for config files and the command line).

There are a few other configuration pages on the AG-188N that I have not discussed separately, either because their purpose and usage is fairly self-evident (Clear Config, Backup Config, WEB Update — the latter lets you upload new firmware or restore backup configuration files) or are of interest primarily to service providers and other “system administrator” types (FTP/TFTP Update, Auto Provisioning).  If you really want to see screenshots of any of these, leave a comment and I’ll post them in a followup article.

In the next installment, I plan on wrapping up this series (for now, anyway) with some final thoughts and a summary review. I hope you’ve enjoyed this exploration of the AG-188N up to this point as much as I have!

Disclosure: CIGear provided me with an Atcom AG-188N for review purposes, and allowed me to keep it after I was finished writing this series, and for that I am most grateful.

Previous Installment | Next Installment

Articles in the series: Review of Atcom AG-188N IAX+SIP ATA (VoIP adapter)

Part 1 – The unboxing
Part 2 – Initial setup using IAX
Part 3 – Setting the time and configuring outbound dialing
Part 4 – Setting up SIP, and securing the adapter
Part 5 – Networking and Internal Router
Part 6 – Final Thoughts and Summary Review
Part 7 – Addendum

Leave a Comment