Author: Admin

Some notes on creating a home theater PC using the Acer Aspire Revo

January 1, 2010 by Admin

Important

This is a heavily edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally published in January, 2010. Things have changed considerably since then, and most of what was shown in the original article is no longer necessary. You install Ubuntu, then you install XBMC, and it pretty much just works. And if you want an even better experience, you might want to look into installing XBMCbuntu. There may be a few hints in this article that are still applicable but you are very likely going to find that most things just work. One thing you may (or may not) need to do is completely uninstall and then reinstall lirc, because it may not show you the window that lets you select your remote (assuming you have purchased an infrared remote that has a receiver that connects to the USB port), and on the re-install of LIRC you should see the selection window and be able to pick your correct remote. Or, better yet, you can skip the removal/reinstall by running dpkg-reconfigure lirc from a terminal prompt (which will bring up the remote control selection window).

Another thing that you might want to do is consider using Linux Mint rather than Ubuntu, particularly if you hate the new Unity interface.

The original genesis of this installation was an article at the Lifehacker site entitled Build a Silent, Standalone XBMC Media Center On the Cheap. While that article is probably outdated, you may still want to read it first, then come back here.

The first thing you need to know is that there are several different models of the Acer Aspire Revo out there. You want the highest powered model you can get, and in particular, the most memory and highest number of processors. Even the high-end ones are very reasonably priced if you shop around, and even moreso if you can score a good, gently-used unit. Note that you CAN buy an Acer Aspire Revo with some version of Windows installed, but it will cost you more and (especially in the higher end models) and for a standalone media center, Linux works better anyway, so why pay extra for an operating system you may never use?

You’ll need a wireless or USB keyboard and mouse during the setup phase. Some Revo sellers include a wireless keyboard and mouse, while others don’t, so just be aware of that when ordering. Read specifications VERY carefully and know what you are buying! Also consider, if you get a defective keyboard (we did), will it cost more to ship it back than what you’d spend to buy a replacement locally (probably yes, if you buy from an overseas seller)? Don’t overlook pre-owned Revo’s — as long as they are still in good working condition and have a model number in the 3000 series or above, they should be fine (the main thing to make sure of is that they have the maximum amount of memory). Be aware that some early models did not have a digital audio output, so if that’s important to you (and it probably is in this application), be careful what you buy.

Also, the Lifehacker article wants you to install the operating system from a thumb drive. If you have an external CD or DVD drive (that connects using a USB port) do yourself a favor and use that (just install from the distribution CD). By the way, speaking of USB ports, at least some Revo models have a sixth (hidden) USB port. It’s right next to the power switch, on the narrowest part of the case — if you see a small, rubbery insert with a USB logo on it, you can peel that off with your fingernail to reveal the hidden USB port (not that you’d want to unless you really need the sixth port).

Probably the most important thing in that Lifehacker article is the BIOS tweaks. Note that most newer Revos don’t seem to have the “Boot to RevoBoot” option, so if you can’t find that setting, don’t worry about it. Also, if you get a newer, higher end unit with more memory, set the iGPU Frame Buffer Size to 512MB, not the 256MB that the article suggested for the low-end unit that Lifehacker used for their build.

Installing Ubuntu is easy; you basically answer the few questions asked during the installation, and stay with the defaults when you are not sure how to answer. You probably do want it to take over the entire hard drive, so make sure you have saved anything you might want from that drive before you begin the install. We strongly recommend using a 32 bit version of Ubuntu – even though the Revo technically supports a 64 bit operating system, we have found that many things simply don’t work right with the 64 bit OS. If you insist on trying the 64 bit version, you’l probably at the very least need to work through several issues.

If you’re totally inexperienced with Linux, you probably should grab the latest full install disk image of Ubuntu and burn it to a CD, or if you really want to try installing it from a USB memory stick, a visit to the Pen Drive Linux site may help you get the image onto the USB stick in the first place. We used the Ubuntu Minimal CD Image for the install, to save time downloading a huge CD image that is mostly replaced during the software update process. If you go that route, be sure to read the instructions on that page carefully, or you’ll be scratching your head wondering why it’s not working! When you type “tasksel” to select the system to install as instructed, you’ll want to install the standard Ubuntu Desktop but there may be other options you’ll want to install as well, such as an ssh server and/or samba server (those might already be present in the Ubuntu desktop install, but it won’t install anything twice, so I just checked those to be on the safe side).

If you do as most users probably will, and download an ISO file, burn it to a CD, and install from that (using an external CD or DVD drive), just be sure that you check any boxes to install additional codecs or to use additional repositories, if offered any such options.

After installing the operating system, if the nVidia drivers were not installed (very unlikely unless for some reason your video hardware wasn’t detected properly), the next task is to install them. The system should offer to do this automatically (look for an icon in the top panel).

You can install Software using the Ubuntu Software Center, but not all available software is available there. You can also install Synaptic if you wish, from the Ubuntu Software Center or using apt-get install synaptic from a terminal window. When I mention installing software, I suggest you try the Ubuntu Software Center first, and if you don’t find it there, then try Synaptic or apt-get.

You might want to start by installing mc (Midnight Commander) – I wouldn’t have a Linux box without it, but that’s just me.

In newer versions of Ubuntu you may also want to consider installing ClassicMenu Indicator, which is a notification area applet (application indicator) for the top panel of Ubuntu’s Unity desktop environment. It provides a simple way to get a classic GNOME-style application menu for those who prefer this over the Unity dash menu. Like the classic GNOME menu, it includes Wine games and applications if you have those installed. It looks like this:

If you want to be able to access your HTPC from other computers on your local network using SSH, install openssh (you don’t need to do this if you installed an ssh server using the minimal install, or if you find that ssh already works) and (optionally) sshguard. Then edit /etc/ssh/sshd_config and change the PermitRootLogin value from “yes” to “no” (for the sake of system security).

Another thing you want to do is make sure that the system time be kept synchronized with Internet servers. Right click on the clock applet in the top panel, then select Time & Date Settings, and make sure everything looks right there (especially that the option to set the time “Automatically from the Internet” is selected).

Now it’s time to install XBMC. If you don’t find it in any of the standard repositories or want to make sure you get the latest release version, then do this from the terminal window:

sudo add-apt-repository ppa:team-xbmc
sudo apt-get update
sudo apt-get install xbmc
sudo apt-get update

You might also want to install MythTV, or at least a MythTV frontend. See Links: A complete guide for setting up MythTV from start to finish for more information on that. Note that MythTV can be installed from the Ubuntu Software Center, and that’s the only recommended method, since they tend to offer a more stable version.

If you happen to have a Wii remote control, see the document Building an ION powered HTPC with XBMC and in particular, Module 6 : Using a Wii remote control. The following notes on an IR remote do not apply if you are using a Wii remote!

If you have an infrared remote control and infrared receiver (these generally come together as part of a package; check the XBMC forums to see which are recommended), run XBMC at least once and then run dpkg-reconfigure lirc from a command prompt (terminal window) to select your particular model of remote control.

You will likely want to be able to launch XBMC using the remote. As a PRELIMINARY way to accomplish this, we opened or created (can’t recall which) a file called .lircrc (note the leading dot character) in the user home directory and put the following lines in:

begin
 prog = irexec
 button = KEY_BLUE
 config = xbmc --standalone &
 repeat = 0
end

begin
 prog = irexec
 button = KEY_POWER
 config = /usr/bin/gnome-session
 repeat = 0
end

begin
 prog = irexec
 button = teletext
 config = sudo shutdown -r now
 repeat = 0
end

This starts XBMC if you push the blue button on the remote. It also returns to the desktop if you push the power button (however, it may leave whatever program you were in running in the background), and reboots the system if you push the teletext button, but for the latter to work, you must add the following line to the end of your /etc/sudoers file:

%admin ALL = NOPASSWD: /sbin/shutdown

EDIT: In later versions of Ubuntu the above line does not always work as shown, however, substituting the user name for %admin apparently does. So for example, if you had users named larry, moe, and curly on your system, you could do this (if you wanted all of them to be able to use the remote button to reboot the system):

larry ALL = NOPASSWD: /sbin/shutdown
moe ALL = NOPASSWD: /sbin/shutdown
curly ALL = NOPASSWD: /sbin/shutdown

Note that this is just to get you started — you can do more complex operations by running an external script rather than the selected program directly, to make your remote work the way you want it to.

By the way, the irexec program must be running for the above to work, so you can use the Ubuntu Startup Applications program to make it run at startup. You should run it with the -d option, e.g. irexec -d in order to make it run as a background process. Note that you need to do this even in newer versions of Ubuntu.

Startup Applications — Add Startup Program

You will probably want to set up one or more shared folders on your system so you can move videos, etc. into those folders. Be aware that you do have to enable file sharing for each folder you want to share. This is pretty straightforward in Ubuntu — select the folder you want to share, right click on the folder icon, click on “Sharing Options”, and then give the share a name and check the appropriate boxes:

Check “Share this folder” and give the share a name (I called this one “shared”). Check “Allow others to create and delete files in this folder” even if you are going to require a valid login to do so, otherwise even you will not be able to copy files to that folder or delete existing ones from a remote location. Check “Guest access” if you want anyone on your local network to have access without the need to supply a user name and password.

If you are trying to get VNC screen sharing (in Ubuntu it’s called Desktop Sharing, but it’s actually VNC) to work, when setting up Desktop Sharing Preferences, make sure that “You must confirm each access to this machine” is UNchecked (it is checked by default).

Desktop Sharing Preferences - UNCHECK "You must confirm each access to this machine" — Desktop Sharing Preferences – UNCHECK “You must confirm each access to this machine”

Then, use the CompizConfig Settings Manager (see How To Change The Settings Of Ubuntu Unity With CompizConfig Settings Manager) and uncheck all the options under “Effects” (except that “Window Decoration” is okay to keep). Apparently, the use of any visual effects is enough to make the remote desktop non-functional:

The nice thing about this is that even if you have the overscan issue discussed below, when you access the shared Desktop you see the full screen including the top and bottom panels, so you don’t have to guess where you’re clicking! In theory, you could disconnect the keyboard and mouse from the Revo, and just use the Remote Desktop when you need to do system maintenance work, or whatever.

One major issue you may encounter when using a HDTV as the display device is something called “overscan” – that means the desktop is actually larger than the area shown by the HDTV display, meaning you can’t actually see your top panel, etc. While XBMC has a ways to correct for overscan, it’s better to correct it for the entire system. In recent Ubuntu versions, the NVidia drivers are installed when Ubuntu is installed (probably only if the installer detects you have NVidia graphics hardware), and the newer drivers do sometimes expose an Overscan Compensation slider that can be used to correct the problem:

Screenshot-NVIDIA X Server Settings — NVIDIA X Server Settings (Overscan Compensation slider near bottom)

This slider doesn’t always appear for some reason, and even when it does, you really should try NOT to use it (except, perhaps, during initial setup and configuration) because if set to anything other that “0” it WILL degrade picture quality somewhat. The proper place to cure overscan is at the HDTV itself. Most HDTV sets have a setting that will fix overscan, but the problem is that there is no standard name for this setting — I’ve seen it called things like pixel-to-pixel, dot-to-dot, 1:1 display, exact image, etc. It’s often buried a submenu or two deep (remember that owner’s manual you got with your TV? Now might be a good time to dig it out!). I’ve found that if you look hard enough, most newer TV’s have this setting, although some do a pretty good job of hiding it (the Sharp LC-42SB45U being an extreme case – it won’t even display the option unless the timing of the signal you send meets certain specifications!). You really should try very hard to find this option, because it’s much better to correct the problem at the hardware end than by using any software method (that includes the software overscan correction built into XBMC) – you’ll get a sharper picture and quite likely fewer issues with video flickering, etc. Even if you have to resort to building an xorg.conf file to make it work, that’s better than trying to do software overscan compensation in the video driver or XBMC — use that method only as a last resort.

If your TV set just doesn’t have a setting such as the one mentioned above — and some don’t — there is a page of instructions to help fix the overscan problem here. We originally wanted this for the aforementioned Sharp LC-42SB45U TV and wasted a huge amount of time trying to find an overscan fix, and you can read what we finally came up with for that particular make and model TV only here: An overscan fix for the Sharp LC-42SB45U television set when connected to a computer with a Linux operating system (Ubuntu, etc.) (and if you have that model TV, it’s preferable to use the xorg.conf file given at that link rather than the Overscan Compensation slider). No matter what, you can see the full screen if you use the VNC/Desktop Sharing service mentioned above, and some have even resorted to using a little workaround to make the overscan less annoying, assuming you don’t find the workaround more annoying than the original problem! And for the more technically astute, it’s always possible to tinker with the ModeLine in xorg.conf (which, again, is preferable to using the Overscan Compensation slider).

Note that the following few paragraphs (up to, but not including, the one about HDMI audio issues) were applicable at the time this article was originally written, but are likely no longer valid due to updates in the nVidia driver and in Kodi (the new name for XBMC).

Irregardless of whether you have overscan issues, if (and ONLY if) you can see any flickering or “tearing” or other weirdness during video playback, it would probably be a good idea to follow the instructions one of these three posts: Either Howto achieve judder free perfectly synced playback at 23.97/59.94 Hz, XBMC and fixing the 24p issue, or HOW-TO setup XBMC and Linux with correct resolution (xorg.conf) (and I’d recommend them in that order — start with the first, and only go on to the second or third if you still have unresolved issues, except that if after trying the technique in the first link, you still see a bit of flicker during the playback of video files then I’d jump right to the third link — that’s the one that fixed it for us on one installation) — in those articles they tell you to modify /etc/X11/xorg.conf and add a couple of lines. I’d suggest a few additional modifications there, if not already mentioned in whichever article you used — under Section “Device” add one or both of these lines

Option "HWCursor" "false"
Option "DynamicTwinView" "false"

The first of those lines is a “blinking cursor fix” and it’s supposed to help if you find an unwanted blinking cursor you can’t get rid of (I haven’t encountered that particular problem yet). The second line enables 1080p 24Hz mode for smoother playback of certain videos (probably most of them, actually). That line can actually go in either “Device” or “Screen” section – I added it to both just to be safe, but that’s probably overkill. Also, at the bottom of the xorg.conf file, add this:

Section "Extensions"
     Option         "Composite" "Disable"
EndSection

That’s supposed to provide better H264 acceleration.

If you added the “DynamicTwinView” “false” option as shown above, and you know for a fact that your monitor supports 1920 x 1080 @ 60 Hz (you should be able to determine that if you followed the instructions in the aforementioned post) then that mode should become available in XBMC — in the XBMC GUI, go to Settings | System | Video Output to select your desired output mode, and see if that mode is available. If, for some reason it is still not available, you might be able to force the issue (you really should not need to do this if you started with the posts linked above, but I’ll leave this information here anyway in case someone needs it) – in order to do that, open a terminal window and do this:

cd /etc/X11/Xsession.d
sudo touch 45custom_xrandr-settings
sudo nano 45custom_xrandr-settings

Paste into this file the following lines, but take the parameters for the first line from the Modeline you created in the previous step, except use “1920x1080_60.00” instead of “1920×1080”. The first line below is an example (do not copy it verbatim, use the settings from your Modeline) but the second and third can be copied and used as is:

xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
xrandr --addmode default 1920x1080_60.00
xrandr --output default --mode 1920x1080_60.00

One other thing that might improve the video quality in XBMC is to go to Settings | Video | Playback settings and change the setting Adjust display refresh rate to match video to On start/stop (you could also try Always). This fix may be of particular help if you are trying to watch Live TV, or recorded TV from a PVR backend, and the picture doesn’t appear quite as sharp as it should. Leave Pause during refresh rate change set to Off. Obviously, this would be most noticeable if you are trying to view a 1080p source. In some areas you may need to play with the de-interlacing options as well, but that is beyond the scope of this article, and we didn’t find a need to do that.

If you are having audio issues when trying to send audio via HDMI, first of all open a terminal window and enter alsamixer and when it comes up press F6 to select your sound card (most likely HDA nVidia) and then make sure that none of the S/PDIF outputs are muted (this will me indicated by “MM” whereas an unmuted one will show “00”). Pay particular attention to S/PDIF 1 as it is often the culprit – use the arrow keys to select it and then press M to unmute it, then ESC to exit. I know this doesn’t make sense since you are trying to send audio out the HDMI port and not the optical audio port, but trust me, you need to do this. Then, if you are finding that audio is coming from the wrong speakers (center and LFE channels are mixed up with left and right surround channels) go to this page: HOW-TO:Remap HDMI audio on Gen 1 ION – Linux – I suggest using the settings under “1.3.1 ALSA Configuration” and below, but read the entire page first to get the full overview. Note that after following the instructions on that page, if you are also running the MythTV frontend you may have to set the audio to use ALSA:hdmi_direct and that this will NOT appear in the dropdown – you should first select one of the other compatible HDMI card options and then edit the Audio Output Device field to show ALSA:hdmi_direct. This is all necessary because the NVIDIA MCP79/7A HDMI hardware has incorrect channel mapping. This problem does NOT appear when using the S/PDIF (optical) output.

If you want to use a web browser to view videos that require the Flash plugin (such as many YouTube videos), particularly if you will be trying to view them in fullscreen mode, you should know that the Flash plugin will not use the Revo’s onboard nVidia graphics unless you tell it to. But, if you don’t do that the videos will most likely be too jerky to watch. So here is what you need to do from a Linux command prompt:

sudo mkdir /etc/adobe/
sudo nano /etc/adobe/mms.cfg

Now insert the following two lines into the file you’ve just opened:

EnableLinuxHWVideoDecode=1
OverrideGPUValidation=true

Then press CTRL+X followed by Enter to save the new file.

Note that this fix does not work absolutely perfectly, so you might still see some video issues now and then, and it might not work on all sites or in all browsers (it does work in Firefox, however). In many cases the video will be far more watchable than without the fix, but on some systems this fix could cause browser crashes and if those become frequent you may need to try removing the /etc/adobe/mms.cfg file. Also, note that this fix will only improve videos played using the Flash plugin.

If you need to (re)format a hard drive to use with your system, and you don’t want any wasted space on the drive, be sure to read this: Free Disk Space by Reducing Reserved Blocks

If you want your system to have a fixed IP address on your local network, click on the networking icon in the top panel (up and down arrows side by side), then Edit Connections, then find the connection you are using and edit it appropriately. For example, under the Wired tab I see Wired Connection 1, and if I click on that and then click the Edit button, I can then select the IPv4 Settings tab, change the method to Manual, and then enter the appropriate settings for my local network.

You may find that you need to go to the “Misc” section of /etc/samba/smb.conf and set domain master = no — otherwise you may find that certain network shares randomly disappear from other computers on your network. If you don’t have the problem of shares disappearing from other computers on your network, or if you don’t have any other servers or computers that are also trying to assert themselves as a master browser, then this may not be an issue for you.

If you have Macs on your local network and would like to use AFP (Apple File Protocol) to move files around, see How to set up AFP filesharing on Ubuntu.

If you hate typing in a password each time you ssh into your Revo, see Stop entering passwords: How to set up ssh public/private key authentication for connections to a remote server.

If you want to reduce startup time when using Ubuntu or Mint (and you do not have more than one operating system installed), do this:

sudo nano /etc/default/grub

Then look for this line:

GRUB_TIMEOUT="10"

Change this line to read:

GRUB_TIMEOUT=0

Then follow the instructions at the top of the file: “If you change this file, run ‘update-grub’ afterwards to update.” This also must be done as root, so after you save the file and exit nano, do this:

sudo update-grub

If you allow the Update Manager to install certain types of updates (particularly nVidia driver updates) — and you should update your software when updates are available — you may find that XBMC won’t start up, but instead displays a message that stats with the words, “XBMC needs hardware accelerated OpenGL rendering.” Typically, simply rebooting the system will fix that issue.

If you are using the Perl script we posted a couple of years ago that monitors a Linksys or Sipura VoIP device and provides Caller ID popups when a call comes in, you may be interested to know that by adding one line to the Perl script and making some minor configuration modifications, you can also have Caller ID popups in XBMC. See our article BETA Perl script for Caller ID popups when using Linksys/Sipura devices for information. Alternately, if you have an Asterisk server, you can send Caller Id information to XBMC by adjusting the XBMC configuration as in the aforementioned article, and then adding a line to your Asterisk dial plan in the form:

exten => extension-number,n,TrySystem(wget -b -O /dev/null -o /dev/null "http://HTPC-IP-address:8080/xbmcCmds/xbmcHttp?command=ExecBuiltIn&parameter=XBMC.Notification(Call%20from%20%22${URIENCODE(${CALLERID(name)})}%22%2C${CALLERID(number)}%20calling%20extension-number%2C15000%2C%2Fhome%2Fusername%2Fphone.png)")

Note that is all one line, and be sure to change the bold, italicized values to something appropriate for your configuration, and also be sure to see the aforementioned articles for XBMC configuration information and to get the phone.png icon.

If you would like to occasionally play music without the need to have the TV running, you might want to install a program called Audacious. The nice thing about Audacious is that it offers a LIRC plugin (under the General plugins section) and if you enable that, and then add a section to your .lircrc file (for an example, follow this link and then scroll down to the section “Configure Audacious(2) to use Lirc“), you can control the program using your remote.

If you set Audacious to “Continue playback on startup” (under the Playback section of the preferences), and then create a .lircrc entry to start Audacious, you could use your remote to turn on Audacious and resume wherever it left off on your playlist. This is really beyond the scope of this article, but I just thought I’m mention it for those who have your Revo hooked up to a receiver and would like to be able to play audio without wasting electricity running a TV you’re not watching.

Addendum for those who wish to use Boxee under Ubuntu 12.04:

Boxee has discontinued support for desktop platforms, but you might be able to install the last Linux desktop version by following the instructions on this page to install Boxee (note particularly the unmet dependency that must also be installed), and then if you are using a MCE remote, you must also follow the instructions in this post to make the remote work correctly with Boxee.

Review of Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing)

December 21, 2009 by Admin

Important

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

This article was originally published in December, 2009.

Cover of Building Enterprise Ready Telephony Systems with sipXecs 4.0

Regular readers of this blog may recall that I recently reviewed another Packt Publishing book, FreePBX 2.5 Powerful Telephony Solutions by Alex Robar, and that my review was generally positive. However, I have wondered for a while if there was going to be any serious competition for Asterisk and FreePBX that would also be open source, and freely available to anyone that cares to download it. Well, this book discusses one contender – sipXecs by SIPfoundry. You can look over their web site to get some idea of what sipXecs is, but in one respect it’s along the same lines as FreePBX, in that it provides a web-based GUI that allows you to do all the work of configuring your phone system from any web browser. The book is called Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher.

I’ve never personally so much as laid eyes upon a working sipXecs installation, so this isn’t going to be a review of sipXecs per se. But I suppose some are wondering what the difference is between sipXecs and FreePBX. The impression I got from reading this book is that the two have some differences in features, and even where there is feature overlap, there are differences in the way those features are implemented. If you are just counting features, FreePBX probably offers more, and many of those features have more configuration options. FreePBX would probably work very well in a home or small office. sipXecs, on the other hand, seems to have been designed by folks with experience in networking and larger business installations. If you were trying to link several branches of a medium-sized to large corporation together, and it’s crucial to have 100% uptime (or as close to that figure as possible), sipXecs might be a better choice (at least until someone high in the corporate food chain demands a feature it doesn’t offer). And if you’re a networking professional, you might find sipXecs more appealing. This is definitely NOT to say that sipXecs could not be used in a home or small office setting, nor that FreePBX could not be used in a large corporation for that matter, just that each may fill a particular niche better than the other.

So I will concentrate on the book itself, and I’ll let the publisher have the first word. Here is how they describe this book:

A clear and concise approach to building a communications system for any organization with the open source sipX Enterprise Communications Server

In Detail

Open source telephony systems are making big waves in the communications industry. Moving your organization from a lab environment to production system can seem like a daunting and inherently risky proposition. Building Enterprise Ready Telephony Systems with sipXecs delivers proven techniques for deploying reliable and robust communications systems.

Building Enterprise Ready Telephony Systems with sipXecs provides a guiding hand in planning, building and migrating a corporate communications system to the open source sipXecs SIP PBX platform. Following this step-by-step guide makes normally complex tasks, such as migrating your existing communication system to VOIP and deploying phones, easy. Imagine how good you’ll feel when you have a complete, enterprise ready telephony system at work in your business.

Planning a communications system for any size of network can seem an overwhelmingly complicated task. Deploying a robust and reliable communications system may seem even harder. This book will start by helping you understand the nuts and bolts of a Voice over IP Telephony system. The base knowledge gained is then built upon with system design and product selection. Soon you will be able to implement, utilize and maintain a communications system with sipXecs. Many screen-shots and diagrams help to illustrate and make simple what can otherwise be a complex undertaking. It’s easy to build an enterprise ready telephony system when you follow this helpful, straightforward guide.

What you will learn from this book

• Understand the complexities of an IP Telephony and Voice over IP network
• Build a clear process for migrating existing phone systems to an IP based system
• Deliver a solid foundation for any IP based phone system
• Quickly and easily get a sipXecs open source PBX running
• Deploy phones quickly and easily.
• Utilize Internet Telephony Service Providers to reduce monthly telephony bills
• Develop training materials to help successfully teach your users how to use the system
• Leverage sipXecs Automatic Call Distribution Queues to handle basic Call Center needs
• Operate and Maintain a reliable communications platform

Approach

This book was written to be a step by step approach to building a communications system for any organization. Care was taken to clearly illustrate with diagrams and screen shots all of the steps and concepts along the way. [Emphasis added – I’ll have more to say on that point!]

Who this book is written for

This book is written for network engineers who have been asked to deploy and maintain communications systems for their organizations.

And here’s the chapter list:

Preface
Chapter 1: Introduction to Telephony Concepts and sipXecs
Chapter 2: System Planning and Equipment Selection
Chapter 3: Installing sipXecs
Chapter 4: Configuring Users
Chapter 5: Configuring Phones in sipXecs
Chapter 6: Connecting to the World with sipXecs
Chapter 7: Configuring sipXecs Server Features
Chapter 8: Using sipXecs—The User Perspective
Chapter 9: Configuring Advanced sipXecs Features
Chapter 10: Utilizing the sipXecs ACD Service
Chapter 11: Maintenance and Security
Appendix: Glossary
Index

See the Table of Contents page to get a more detailed chapter breakdown.

Now, when I review a book, the thing I am looking at is whether the author accomplishes what he or she set out to do. In this case, the intent of the book is to instruct someone in how to set up a working sipXecs PBX. So, I look at whether the author seems to have a good grasp of his subject matter, and whether he can communicate his knowledge to the reader in a clear and understandable manner. A third consideration is whether the book is a good value for the money. Technical books often aren’t inexpensive, so I tend to mark them down if I perceive that there’s a lot of “filler” material in the book.

It’s difficult for me to decide how to rate this book. Does the author understand his subject matter? Yes, it certainly appears that he does. Does he effectively communicate it? Yes, the book was an easy read — I really didn’t feel like I was in “over my head” at any point in the book. Could you set up a working sipXecs phone system after reading this book? I think I could, but I can’t speak for anyone else. In fact, in many ways, this was one of the clearest and most understandable technical books I’ve read.

You sense a “but” coming, don’t you?

Well, there is, and it’s a big one. Did you notice above where the publisher said that “Care was taken to clearly illustrate with diagrams and screen shots all of the steps and concepts along the way”? Well, the book definitely contains screenshots — a LOT of screenshots. And normally, that would be very good thing, because as the saying goes, a picture is worth a thousand words. A screenshot would not add value to a book only in the case where it was useless “filler” material, and it’s pretty apparent that none of the screenshots in this book were intended to just be “filler.”

But, for a screenshot to be useful and not “filler”, it has to be readable. And in that regard, this book has a serious problem. If you buy the hardcopy edition of the book, I’d strongly urge you to also buy a good magnifying glass, because you’re going to need it to get anything out of those screenshots, unless perhaps you have perfect vision. Apparently the author (or whoever took the screenshots) has a widescreen monitor, and was running their web browser in full screen (or at least full width) mode. As a result, most of the text in the screenshots borders on microscopic, and some of the smaller print is unreadable (by me, anyway). When you take those extra-wide screenshots and reduce them to about five inches in width on a printed page, you need very good eyes (or good glasses) to make out the text. After trying to decipher the details in those screenshots for a while, I started to get a headache!

At first I thought maybe it was my eyes going bad — I am getting older, after all — but then I opened up some of the other books I have in my collection, including other Packt Publishing books, and none of them suffer from this problem. Frankly, if I were the publisher I’d stop the presses on this book immediately, and not let another copy go out the door until all the screenshots were re-done, but then that’s just me.

Now, that said, the book is not totally without value. I think that perhaps the author just might have realized he had a problem, because in many cases he repeats in the text most of what’s in the screenshot (at least the portion to which he’s calling your attention), so not being able to actually read the screenshot isn’t always such a loss — but unfortunately, it also relegates the screenshots more toward the category of “filler.”

So, would I recommend this book? Yes, for two classes of readers in particular:

Those thinking about setting up an Asterisk/FreePBX system that would like to know about available alternatives. It may be that the particular combination of features that you deem essential can only be found in one of either sipXecs or FreePBX, and by reading this book and the aforementioned FreePBX book, you’d have a pretty good idea of the differences in capabilities between the two.
Those thinking of installing a VoIP PBX in a larger organization, where reliability and scalability are far more important than the actual feature set. My impression from the book is that sipXecs is designed with larger businesses and higher call volumes in mind. That’s no reason that someone with a small business should shy away from it, but if you are very concerned about reliability and high “uptime” then you probably should at least give sipXecs some consideration. And if your organization is large enough to have people with degrees in computer networking in your employ, they might prefer working with sipXecs. This is not to say you can’t do a large installation using Asterisk, but now you have another choice, and this book can help you decide which is best in your particular situation.

If it weren’t for the screenshot issue, I’d be giving this book very high marks. The focus of the book is deployment in a business setting, and the author takes you through the steps for planning and implementing the system, whether you are replacing an existing PBX or starting from scratch. Having some knowledge of computer networking would be helpful, but as I noted, I’m no networking expert and yet I didn’t feel totally lost. In fact, if you know telephone systems but don’t know all that much about networking, you’ll find that just about everything you really need to know is explained, but without going into extraneous detail. You get the information you need to get the job done, but if you want to become a networking guru, you’ll need some other book for that.

I’m just really sorry that the bad screenshots marred an otherwise fine book, but I have to call ’em as I see ’em, and in my opinion they really are that bad. Whether that would matter to you is something only you can decide. I should mention that I was provided a hardcopy edition of the book for review, but Packt also offers an e-book edition in Adobe PDF format on their web site, and if you are comfortable reading e-books, I’d definitely go that route with this book, because most PDF readers will let you magnify sections of a page. So, the nearly unreadable screenshots might actually be very readable in the e-book edition. Also, if you do go the e-book route, be sure to scroll down the page and look for the offer, “Buy this eBook with FreePBX 2.5 Powerful Telephony Solutions eBook and get 50% discount on both. Just enter sip40xecs in the ‘Promotion Code’.” Seems like a good deal, especially if you’re wanting to compare FreePBX and sipXecs.

Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing link) (Amazon affiliate link)

Review of FreePBX 2.5 Powerful Telephony Solutions by Alex Robar (Packt Publishing)

September 23, 2009 by Admin

Important

This article was originally published in September, 2009.

Cover of FreePBX 2.5 Powerful Telephony Solutions

FreePBX 2.5 Powerful Telephony Solutions by Alex Robar (Packt Publishing) explains how to set up, configure, and maintain a powerful VoIP PBX using FreePBX. For those not familiar with FreePBX, it’s a “front end” for the Asterisk PBX software. Asterisk can be thought of as the “engine” that runs the PBX, but FreePBX is the user interface. It basically saves you the effort of writing Asterisk configuration files and dial plans by hand. Instead, you enter all the requisite information in FreePBX’s web-based GUI, and then when you apply the configuration changes (by clicking an orange bar at the top of the screen), FreePBX (re)writes the Asterisk dial plan and configuration files on the fly. This means that making significant changes to the call flow within the PBX, or adding new extensions or trunks, can be accomplished in a matter of seconds or minutes. It also means that you can have a fully functional PBX up and running in a few hours (perhaps even less than an hour if you’re exceptionally quick and it’s not your first installation).

As I like to do in reviews, before I begin I’ll give you a thumbnail description of what’s in each chapter (condensed from information on the Packt Publishing web site):

Chapter 1: Installing FreePBX – Installing FreePBX on CentOS 5.2 or Ubuntu Server 8.10
Chapter 2: Module Maintenance – how to install and update modules
Chapter 3: Devices and Extensions – explains the difference between Extensions mode and DeviceAndUser mode, and explains how to set up extensions and users. Also explains the different types of endpoints, and how to set up voicemail for a user or extension
Chapter 4: Trunks – discusses trunk types, setting up a new trunk, and checking trunk status
Chapter 5: Basic Call Targets – explains various ways to terminate calls on a FreePBX system, including Extension and Voicemail, Ring Groups, Conferences, Day Night Mode, and Phonebook Directory
Chapter 6: Advanced Call Targets – discusses Queues, Time conditions, and the setup of an IVR (Digital Receptionist)
Chapter 7: Call Routing – discusses Inbound routing, Follow Me and the VmX Locater, and Outbound routing and Least Cost Routing
Chapter 8: Recording Calls – focuses on everything you need to know about recording calls that pass through a FreePBX system
Chapter 9: Personalizing Your PBX – discusses Custom Music on Hold, Custom voice prompts, Directory search options, Customizing feature codes, Callback, Direct Inward System Access (DISA), CallerID Lookup Sources, PIN Sets, Misc applications, and Misc Destinations
Chapter 10: System Protection, Backup and Restoration – how to protect your system against failure, discussing both hardware methods (a good UPS and redundancy) and backups and restoration
Chapter 11: Security and Access Control – explains how to upgrade your operating system and Asterisk, plus various ways to secure your system against attacks

There are also four appendices:

Appendix A: FreePBX Modules
Appendix B: Feature Codes
Appendix C: Voicemail.conf Options
Appendix D: Common Trunk Configurations

I’m coming from a slightly different place in my review of this book than with other books I’ve reviewed. In this case I’ve already very familiar with the subject material, having helped set up and configure a FreePBX system that belongs to another member of my family. I was a bit afraid that because I’m already so familiar with the subject, I’d find several glaring errors or oversights. Happily, that proved not to be the case – this book is a good, solid treatment of setting up and configuring a FreePBX system. In fact, the title should have been “How to set up and maintain a FreePBX system”, because that’s exactly what this book explains.

The first thing that impressed me about this book is that there was no “filler” material. Very often, with technical books, the author really only has about 75 to 100 pages of actual material, but because publishers like to publish books that have somewhere around a couple hundred pages, the author will flesh out the book with a history of the software, a profile of the developers, comparisons with competing products, and (if they are really desperate for material) a history of the Internet. 🙂 That is not the case here. After a very short preface, the author jumps right into the subject material, starting with how to install FreePBX and then continuing through subsequent chapters with virtually everything you need to know about configuration. While not every chapter may be meaningful to every reader (personally, I’ve never had the need to record a call — so far — but it’s nice to know that FreePBX can do it), the book at least touches on all the major features of FreePBX.

If I had to make one criticism of the book, it’s that in some places it reads a little bit too much like an instruction manual. And that’s not necessarily a bad thing, because FreePBX has badly needed a good manual to assist first time users in getting it set up and running. This is the manual that should have come with FreePBX. That said, the author really doesn’t touch some of the problems frequently encountered by new users. For example, in the discussion of SIP endpoints, he notes that “SIP can be problematic when traversing firewalls and other NAT devices” and that “Configuration can be particularly troublesome if both the endpoint and the FreePBX system are behind their own firewalls” (p. 44). And there he leaves the reader hanging. There is no discussion of how to overcome the problem, nor is there a pointer to the FreePBX FAQ’s or How-To’s anywhere in the book. While many readers may not encounter this issue, a fair number will, and it would have been nice if they’d been thrown a bone, if only in the form of a pointer to the FreePBX page that addresses the issue.

In my opinion, perhaps the biggest omission is in the discussion of Trunk setup in Chapter 4. This was really the only chapter in which I got the distinct feeling that the author may have been in just a bit over his head, and perhaps did not fully grasp the subject matter covered in the chapter. Not only are there errors in his examples of dial pattern usage (p. 81 – under no circumstances would you use two pipe characters in the same dial pattern, as is shown for some of the toll-free number examples), but when discussing IAX2 and SIP trunks (p. 83), only cursory information is given about how to populate the PEER details and USER details fields. Nor is it explained that with many commercial VoIP providers, the USER context and USER details fields are not used, and should be left blank. However, in the author’s defense, I suspect that I understand why this may have happened — there probably aren’t ten people on the face of the earth that can give you a full explanation of all the options that could possibly be used in the trunk PEER and USER details fields, and when and how each option should be used. Trunk configuration is probably the most difficult part of setting up FreePBX, precisely because there’s no definitive guide on how to do it correctly. In most cases, I suspect that finding the correct options to use with any particular provider is a matter of trial and error — you make educated guesses about which options might be needed and how they should be configured, and if you find a combination that works, perhaps you post it so that others can use it. Some of the known working trunk configuration settings appear in Appendix D of the book, but there are more sample configurations available at the FreePBX web site.

I only mention this because I was hopeful that maybe someone would finally provide a really good how-to on setting up FreePBX trunks, since this is something that almost always confounds new users, and even causes experienced users to get a few (more) gray hairs on occasion. Had I been writing such a book, and had I really understood the subject, I might have given several pages to the subject of trunk configuration in general, and PEER and USER details in particular, not just a few cursory paragraphs. On the other hand, most users will probably seek out a tested and working trunk configuration for whatever provider(s) they use. It’s not as though there isn’t any online help on the subject, but — and this is another minor criticism — for some reason the book barely mentions the availability of online help (for example, unless I missed it there is no specific mention of the FreePBX How-Tos that address several of the issues encountered by new users). This is why I say that at times the book reads like an instruction manual — it gives you all the basics, but seldom touches the “edge cases”, the little quirks and problems that may be encountered by a significant subset of users, but not by all.

However, I don’t want to leave you with the idea that this book is simply a rehash of information that could be found online — even if that were the case, it presents that information in a logical manner that is easily understandable by the reader. But, many essential functions of maintaining a FreePBX system happen outside of the FreePBX interface. For example, you cannot update your operating system or Asterisk from within the FreePBX GUI, but the book explains how to do both. Chapters 10 and 11 (on System Protection, Backup and Restoration, and Security and Access Control) deal with functions that are at least partially handled outside of FreePBX. In some instances the author provides useful shell scripts that automate particular tasks (for example, deleting old, outdated backups to avoid filling up the hard drive). And in many cases, the book does explain things that new users need to know, but might not know that they need to know — for example, the explanation of Codecs and the penalty involved (both in terms of system performance and call latency) in transcoding between codecs.

Anyway, the bottom line is this: Let’s say your boss wants you to set up a new office phone system using Asterisk, and gives you a couple of weeks to do it. If you have no prior experience with Asterisk, you will almost certainly want to use FreePBX (the alternative is writing dial plans and configuration files by hand, and trust me, you don’t want to do that unless you are the sort of person who enjoys writing source code for major projects, and even then you probably don’t want to do it if you’re under any sort of time deadline). And if you’re going to use FreePBX, and you don’t want to spend hours and even days ferreting out information on the Internet, you need this book. Get your boss to buy it (there’s even an e-book version if you need it right now), then just follow the instructions, chapter by chapter. In a few days time, you’ll be well on your way to becoming a FreePBX expert. That’s partly because FreePBX is so easy to use in the first place, but also because the book tells you pretty much everything you need to know, in a very understandable manner. If you get stuck, help is available at the FreePBX web site and at other various locations on the Internet.

If you are a long-time FreePBX user, you may find that you already know much of what’s in this book, but then again it might surprise you how much can still be learned. For example, I found several good suggestions for adding additional security to a FreePBX system in Chapter 11 of the book — and let’s face it, many of us are probably a bit lax about securing our systems to the greatest possible extent (and that could be a very costly mistake).

One other point I should make — as the title of the book implies, it deals with a particular version of FreePBX, namely version 2.5. Of course, as so often happens with a book about software, the ink is barely dry on the paper when a new version comes out. FreePBX 2.6 has already been offered as a release candidate, and beta versions of FreePBX 3.0 are being made available. From a user’s standpoint, version 2.6 will be nearly identical to 2.5 – there may be a few added options and such, but for the most part they are not things that you would need to worry about, or that would detract from the accuracy of this book. However, FreePBX 3.0 will be a major rewrite, but it’s only available in an early beta version, and unless you are an experimenter that wants to be on the bleeding edge, you don’t want it yet. Whenever you do move to FreePBX version 3.0 — and I’d be very surprised if a full release version is much closer than a year away — much of what you’ve learned about FreePBX 2.5 and subsequent versions will still be applicable (and also, I suspect that people will be using FreePBX 2.x versions for quite some time to come).

FreePBX 2.5 Powerful Telephony Solutions by Alex Robar (Amazon affiliate link)

How to use fiber optic cable for short runs between buildings (and why you should)

September 7, 2009 by Admin

Important

Have you ever been in a situation where you want to extend a local network (or maybe an Internet connection) from one building to another that’s separated by some distance, say anywhere from several feet to a few hundred feet? Many people use wireless in this situation, and that’s a perfectly acceptable solution if it works, but it also brings with it a host of security issues. Any signal that is put into the airwaves is one that can potentially be intercepted, particularly if you’re not really familiar with wireless security. I’m not saying you should or should not use wireless, but I do know that some folks aren’t crazy about the idea. Also, there are distance limits on wireless links that can mean that no useable signal will be available where you want it.

Unfortunately, the only alternative to a wireless link between buildings is a physical link (if you ignore more esoteric alternatives that depend on both buildings getting their electrical service from the same power transformer) and there you have two choices, copper or fiber. Assuming you are going to bury a line between the two buildings, how do you know which to use?

I know there are people who would never recommend copper under any circumstances. The reason is that during electrical storms, there can be a difference in electrical potential between two buildings. This can cause serious amounts of current to flow, especially if lightning strikes nearby, damaging equipment (and in an extreme case, possibly even starting a fire). Even in cases where the equipment at the endpoints doesn’t seem damaged, the connection can turn very flakey after a lightning strike, with very high packet loss.

The only situation where you might get away with running underground Cat5e (or Cat 6, if you can find it) is to a very nearby building, and then only if you put very good approved lightning protection at both ends of the cable. The further away the building, the more important that the lightning protectors become (and if the buildings get electrical power from different sources, such as different electrical transformers, then the lightning protection becomes even more essential), and of course good lightning protection costs money. And even then, if lightning hits very close, it can fry the lightning protectors, meaning the Internet connection will likely be out of service until you can obtain and install replacement protectors.

One other problem to note: You have probably heard that the theoretical maximum distance for a run of Cat5e/6 cable on a wired network is 100 meters. That may be true indoors, in a dry environment. It’s not always true when the cable runs underground and/or is partially exposed to outdoor climatic conditions. On a run that’s close to the theoretical maximum in length, you may find that a connection that works beautifully during the cold winter months suddenly starts showing high packet loss during the heat and humidity of summer.

The alternative to Cat 5e/6 cable is fiber optic cable. Fiber is a great alternative because it uses glass fibers rather than copper wire to carry the signals. Since glass doesn’t conduct electricity, the only way lightning could ever affect it is in a direct strike, where it heats the ground so hot that the glass melts (this actually occasionally happens in areas with sand dunes, where the lightning creates glass sculptures by melting the sand into glass, but it’s very unlikely to happen on regular flat land).

The trouble with trying to use fiber is that just about everyone with any networking experience knows how to use Cat 5e or Cat 6 — you just plug it in to your equipment at each end, or if it doesn’t have plugs then you either use a tool to attach them, or your bring the wire to a modular jack and use a punchdown tool to make the connections (some lightning protectors have punchdown terminals as well). You can cut the cat 5e or 6 cable to the exact length you need. It’s something many people are familiar with, whereas fiber may as well have been pulled out of an alien spacecraft for all anyone (outside of those in the telecommunications industry) seems to know about it. If you go searching for pages on the Internet explaining how to install a fiber link between two buildings, good luck in finding anything useful!

Part of the probable reason there aren’t too many general how-tos on the subject is that there are so many variables — there are many types of fiber available, each of which is good for certain specific uses, with many different types of end connectors. And then you need equipment at each end to connect the fiber to the wired network, and you can’t just run down to the local office supply or big box electronics store to find that. But don’t despair, because I’m going to tell you one way to set up a short range fiber optic link. The caveat here is that I am by no means an expert on this — I’ve been involved in an installation ONCE, but I learned a lot in the process. Still, if you have questions that aren’t answered on this page, I’m probably not the guy to ask. But I figure that if you’re searching for online information on the subject, any information is better than none!

So let me start by telling you some things you need to know about fiber optic cable:

This fiber still worked! (Photo credit: Paul Timmins)

It comes in two varieties (that you are likely to encounter), singlemode and multimode. Singlemode fiber usually has a yellow jacket (plastic coating, like the insulation on a copper wire) whereas multimode cable generally has an orange jacket. For most short run applications (by that I mean distances measured in meters or feet, not kilometers or miles) you’ll use a paired multimode fiber (two fibers side by side, in a jacket that looks a bit like the type of electrical cord used with a table lamp, except the jacket is bright orange and it’s a lot smaller). If you’re a phone or cable company (or connecting to one) then you might have occasion to work with singlemode, but that’s not what we are talking about here. Singlemode is a lot more fragile than multimode – you can do this (photo at right) with multimode and it will probably still work (although anything remotely close to this tight of a bend is definitely NOT recommended – remember this is glass fiber that you’re bending, and if it breaks the cable becomes worthless!)

EDIT by TechNotes editor (March, 2021): Although the above paragraph was true when it was originally written, times change and now the orange jacketed cable, technically designated as OM, OM1, or OM2 cable, is basically obsolete. Nowadays you should probably be buying at least OM3 cable, or OM4 cable or OM5 cable if you can get it, which comes in different colors. More on that in a bit.

You can’t cut and splice fiber (unless you buy some really expen$ive supplies and equipment, and learn how to use them). You buy the length you need, with the connectors at each end already attached. If it’s too long, you coil up the excess (not TOO tightly) but you never cut it nor try to splice it, unless you have the specialized equipment that allows you to do so. If a cable is too short and you need to extend it, you can use a device called a fiber optic coupler (instead of “coupler” it may also be referred to as an “adapter” or “joiner”) which is a small plastic device that simply joins two fiber cables together so that the light from one travels into the other. These contain no electronics and therefore are very inexpensive, and can be used in just about any dry location, but there is a small amount of insertion loss that generally won’t matter unless you have an exceptionally long run of fiber or you use too many of them in one fiber run. There are both singlemode and multimode versions of these devices.

At each end, the fiber plugs into a device called a media converter. The media converter (or the SFP module that plugs into the converter — more on that in a moment) contains a laser, and a receiver. It transmits on one fiber of a pair, and receives on the other. The one thing you must never do, if you value your eyesight, is look into the laser while the unit is operating. That also means you can’t plug a fiber cable into the media converter, then look into the other end of the fiber to see if it’s working. If you think you might forget this important safety precaution, just try to remember that not looking into the laser is as important as not touching a live electrical line — and if that doesn’t scare you, take a course in reading Braille, because you’re probably going to need it.

It’s also possible to buy gigabit switches that can directly accept fiber. This eliminates the need for a separate media converter at one or both ends, but such switches tend to be a bit on the expensive side, although they also tend to offer more ports than most typical home switches (24 ports, for example). But there is sometimes a cost in terms of power consumption – for whatever reason, standalone media converters often tend to draw far less power than switches that have fiber ports.

Fiber is somewhat fragile, and it can break (and be rendered useless) if it is subjected to too much strain. You can’t just pull it over a very long length without taping it to something else (that you’ll also be pulling) at regular intervals to relieve the strain. You can buy special, relatively inexpensive network pull string for the purpose, or if you don’t have any of that you can use any high tensile strength string (not twine, it breaks too easily, and avoid stretchy string because that sort of defeats the purpose – you want the string to help pull the fiber, not the other way around). The fiber I’ve seen needs to be inside something to protect it (no direct burial) – you can use cheap irrigation pipe for the purpose, as long as it’s large enough for the connectors at the ends to pull through (don’t try to be thrifty and undersize the pipe, but at the same time realize that fiber with the small LC connectors has plenty of room inside a standard one inch irrigation pipe, assuming you’re not pulling several multiple fiber pairs or other wires and cables). Also, you should use pulling lubricant on long pulls to prevent damage to the fiber jacket.

EDIT by TechNotes editor (March, 2021): Once again, the above was true when originally written, but now you can buy cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” that is not nearly as fragile as the orange stuff.

When you buy the fiber, it will have connectors attached at each end (at least it had better have, if you want to actually use it — don’t buy bulk cable that doesn’t have the connectors attached!). These connectors usually have two-letter designations. Popular types are LC (the smallest you’re likely to encounter, which makes it very popular these days), SC, and ST. The media converter (or switch) has to be able to accept the type of connectors your cable has. If your media converter has an ST connector and the cable has LC connectors, you’re out of luck. Sometimes you can buy cable with different connectors on each end, so be careful that it matches your media converters. If you find that your cable has one type of connector and your media converter expects another, you may be able to use a fiber optic coupler/adapter and then a very short fiber cable (sometimes referred to as a patch cable) that has the two different types of connectors on the two cable ends. So for example, if your cable is a duplex multimode type that has LC connectors but your media converter accepts ST connectors, you would need a LC-LC duplex multimode fiber optic cable adapter/coupler and then a LC to ST duplex multimode fiber patch cable. You just need to make sure that the patch cable has the same specifications as the cable you are trying to join it to.

If you want to know more about fiber on a technical level, see the Reference Guide To Fiber Optics.

SFPs and GBICs

According to Wikipedia:

A gigabit interface converter (GBIC) is a standard for transceivers, commonly used with Gigabit Ethernet and fibre channel. By offering a standard, hot swappable electrical interface, one gigabit ethernet port can support a wide range of physical media, from copper to long-wave single-mode optical fiber, at lengths of hundreds of kilometers.

The appeal of the GBIC standard in networking equipment, as opposed to fixed physical interface configurations, is its flexibility. Where multiple different optical technologies are in use, an administrator can purchase GBICs as needed, not in advance, and they can be the specific type needed for each link. This lowers the cost of the base system and gives the administrator far more flexibility. On the other hand if it is known that a switch will mostly have one port type (especially if that port type is copper) purchasing a switch with that port type built in will probably be cheaper and take up less space per port.

The GBIC standard is non-proprietary and is defined by the SFF Committee in document # SFF-8053i.

A variation of the GBIC called the mini-GBIC or SFP exists as well. It has the same functionality / modularity but in a smaller form factor.

(Source)

and

The small form-factor pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunication and data communications applications. It interfaces a network device mother board (for a switch, router, media converter or similar device) to a fiber optic or copper networking cable. It is a popular industry format supported by several network component vendors.

SFP transceivers are designed to support SONET, Gigabit Ethernet, Fibre Channel, and other communications standards. The standard is expanding to SFP+ which will be able to support data rates up to 10.0 Gbit/s (that will include the data rates for 8 gigabit Fibre Channel, and 10GbE. SFP+ module versions for optics as well as copper are being introduced. In comparison to Xenpak, X2 or XFP type of modules, SFP+ modules leave some of the circuitry to be implemented on the host board instead of inside the module.^[1])

(Source)

Okay, in case you weren’t following along, a mini-GBIC, also known as a SFP, is a module that plugs into a media converter or a compatible switch. What this means to you is that you can buy a media converter, then plug in the SFP that matches the type of fiber and connectors that you have. So let’s say you have fiber with LC connectors – you get a SFP with LC connectors to match. Now suppose that at some point you need to replace that fiber with some that has ST connectors – you don’t have to throw out the entire media converter or switch, but instead you just get a new SFP. Not all media converters accept SFP’s, but many of the newer ones do. Also, not every manufacturer’s SFP will work with every media converter – if you buy an SFP you have to make sure it’s compatible with the media converter (or switch) that you own. It has become increasingly common to find fiber media converters sold with a compatible SFP as a bundle.

If you go the SFP route, you have to make sure of three things: That the connectors match the connectors on your fiber cable, that it’s intended for use with multimode rather than single-mode fiber, and that it’s for intermediate or short reach use (IR or SR — you may also find the designation SX or 1000Base-SX used to indicate a short to intermediate range SFP). In particular, you don’t want one with long reach optics because unless you use fiber attenuators you’ll overload and probably burn out the receiver at the other end (also, there’s a much greater chance of eye damage if you accidentally glance at the laser). To give you an idea of the difference, the short range optics are generally specified for runs up to a few hundred meters in length, while long range optics have distances specified in kilometers (sometimes as much as 80 km or more!).

So lets say that you want to run a fiber optic cable between two buildings that are a reasonably short distance apart — what do you need?

The first thing you need is a pipe or conduit of some kind between the two buildings. Irrigation pipe (the stuff you find at any home improvement store, or anyplace that sells underground lawn sprinkling supplies) is fine – remember you aren’t running anything electrical if all you are running is a fiber cable! The main thing is that the pipe or conduit that you use should be relatively smooth inside to minimize pulling resistance. Try to keep bends in the pipe to an absolute minimum. And yes, the pipe could be above ground as long as it’s sunlight resistant and not in a place subject to physical damage (but be aware that black pipe could get VERY hot in direct sunlight, so keep it out of the sun if at all possible). The purpose of the pipe or conduit is to protect the fiber. The pipe must be large enough for the connector (at the fiber cable’s end) to fit inside, with space to spare. If you have to splice sections of pipe together, the connectors may have a smaller inner diameter, so plan accordingly – you don’t want to get halfway through a pull and realize that the diameter at the splice point is too small to continue!

This article isn’t about burying pipe, but I will just suggest that you think about routing it far away from anyplace that people might be digging in the future, if at all possible — and if that’s not possible, then consider burying it as deep as possible, to minimize risk of backhoe failure (or on a farm, of getting plowed up!).

You need network pull string and electrical tape. The string must be longer than the fiber cable – if it’s twice as long then you could pull just the string through the pipe to use for pulling (a good shop vac and a small wad of paper tied to the end of the string is often enough to get the string started through the pipe), and still have enough left on the far end to tape the fiber cable to the string for the entire length. Do that every few feet, making sure that there’s a little slack in the fiber (not too much) when the string is pulled tight. Be sure to tape the leading end of the fiber connector (with the protective cap on) firmly to the string so it can’t try to flip over or do something equally undesirable during the pull. Note that if you are also pulling any kind of wire through the pipe on the same pull, you could tape the fiber to the wire rather than a string, assuming the wire is strong enough to not stretch during the pull.

EDIT by TechNotes editor (March, 2021): For short runs of cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” you may not need the pull string and tape, since that cable is less fragile than the orange fiber cable referenced in this article. But for longer runs, or if your pipe or conduit is undersized, I’d still consider using the pull string and tape, to avoid putting too much tension on the cable.

You need pulling lubricant — any electrical supply store sells this stuff. But note that this stuff can dissolve the adhesive on electrical tape (we found this out the hard way), so when you tape the cable to the string, try not to leave the adhesive side exposed. The trouble is that to really do it right you should use plenty of pulling lubricant, yet at the same time if you do, if you taped carelessly then you may have issues with the tape not holding as it should. That’s not a reason to apply less lubricant, but rather a reason to use a little extra tape and to make your tape wraps nice and tight, so the lube can’t get between the layers of tape (especially at the very start of the pull).

We used some blue gel stuff called Ideal Aqua-Gel II and used a paintbrush to apply it liberally to the fiber cable, after first using a funnel to dump some down the pipe. You can get a gallon pail of this stuff for between $15 and $20 at most electrical supply stores (the places the electricians shop), though you might wind up with another brand. We found that a gallon was really excessive, we could have easily got by with a quart of the stuff (on a 100-meter pull). On the other hand, it was much easier to dip a paint brush into the gallon pail, then slop it onto the fiber cable and down the pipe. You really don’t want to be stingy with it, since friction in the pipe can damage the fiber jacket.

EDIT by TechNotes editor (March, 2021): If you are using cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” and the run is short, you may not actually need the pulling lubricant, but it is always a good idea to reduce friction.

You need the fiber cable itself. The type of multimedia fiber cable that we are talking about here comes on a ridiculously small spool (and to me, it always looks larger in photos than it really is, which for years led me to think that it wouldn’t fit through the existing pipe that was used in this situation) — this is what 100 meters of dual fiber looked like before the bubble wrap was removed:

The fiber we used was described as “Advanced Interconnect 100 Meter LC-LC Duplex MultiMode Fiber Optic Cable. This Advanced Interconnect cable part number 038-001-964 REV A. Cable is 50/125 OFNP Micron Fiber.” It was obtained from eBay seller isellcables. If you are wondering what a dual LC connector looks like, there is a good photo here. Note that the connector comes with a protective cap, which should be left in place during the pulling process.

EDIT by TechNotes editor (March, 2021): As mentioned earlier, this orange jacketed fiber cable is now considered old technology. What you probably want to use is cable designated as “Outdoor Armored Duplex Fiber Optic Cable” and OM3 or better. Strictly as an example (this is not a recommendation), in 2021 Amazon sells a product called Jeirdus 100Meters 328ft LC to LC 10G OM3 Outdoor Armored Duplex Fiber Optic Cable Jumper Optical Patch Cord Multimode 50/125 100M LC-LC for $128, with other lengths from 5 meters to 300 meters available. Something like that would definitely be preferable to the unprotected orange jacketed cable for outdoor runs, although I would note that because the cable is armored that means it could conduct electricity, even though the fiber connections at each end would still be electrically isolated. For additional electrical isolation you could add a length of unarmored cable at each end, using a LC-LC duplex multimode fiber optic cable adapter/coupler to join the cables together, but you would need to make sure the fiber optic cables you are joining have the same specifications (in particular, don’t connect singlemode to multimode cable).

You need a couple of fiber media converters, one for each end, and if they use SFP modules you’ll need a couple of those as well. They look like this:

Notice (if you can actually see it in these photos) that the fiber cable is plugged into the SFP module, which in turn is plugged into the media converter — here’s an enlarged and enhanced closeup, where you can just see the end of the SFP (the small chrome part) sticking out of the media converter:

Fiber connects to SFP module, inserted into media converter

This media converter was described on eBay as “Gigabit Fiber media converter multimode MM, 1000Base SX” and “The FIB1-1000ES MM is a Gigabit Ethernet copper to multimode 850nm LC connector fiber media converter. It has an SFP (Small Form Pluggable) slot occupied by an MM 850nm multimode module, Ethernet 1000Base-SX compatible. The Copper interface is an auto negotiating 10/100/1000 BaseT RJ45 interface with auto MDI/MDI-X detection. …” I would point out that it’s important that it actually says 10/100/1000 BaseT if your network runs at anything less than 1000BaseT speeds, because not all media converters will handle multiple speeds or speed conversions. As Paul Timmins told me, “it’s VERY possible for something to ONLY support Gigabit. When you get down to media converter territory, the reason they get cheaper is they have less guts to convert stuff between 1000T and 100T (you need buffers, ability to send gigabit pause frames when your buffers are full, etc).”

EDIT by TechNotes editor (March, 2021): As time has passed newer equipment has become available that can handle speeds up to 10 Gigabits. That may be serious overkill for most home users, but if you are doing heavy video editing or anything else that produces very large files, you may want to look into the higher speed equipment.

As it happened, this eBay sale included a LC SFP with each converter, so those didn’t have to be purchased separately. The seller on these was sales_fo4all. If you search on Amazon or eBay using a phrase such as Fiber Media Converter LC Multi-Mode you should be able to find something similar, possibly at a better price than what we paid.

Below is an individual SFP in its packaging – you can’t see the model number but it’s SFM-7000-S85, which is described as a “1000Base-SX, multi-mode, 550m, 850nm SFP transceiver” and additionally, that “The capacity of SFM-7000-S85 module is 1.25Gbps (Gigabit rate). The transceiver extended range allows operation on either 50/125um or 62.5/125um multi-mode fiber for up to 550m distance. (Note: for 62.5/125um fiber, maximum operating distance is only 275m).” Since our cable was the 50/125 stuff, we could have gone a much greater distance (about 1800 feet) if necessary, and if we’d had a cable that long! In the picture below, the black part on the left is a small protective cap that is removed before you plug in the fiber cable.

A better picture of a SFP module can be found here. If you are observant, you may note that both the fiber converter and the SFP module shown above are made by the same company (CTC Union Technonlogies in this case). You may wonder, as I did, if you can use one manufacturer’s SFP with a different manufacturer’s media converter or SFP-compatible switch. According to Paul Timmins, “they’re theoretically universal but there’s absolutely nothing preventing them from vendor lockin (they’re active devices with internal serial numbers, etc, that help negotiate the capabilities of the optics with the device itself, and many vendors will refuse to work with another vendor’s GBIC/SFP).” I’m also told that a certain big name networking equipment manufacturer takes measures to prevent you from using competitor’s SFPs (which can often be overridden with undocumented commands). So if at all possible, when buying new equipment try to buy the media converter and SFP module as a matched set, or failing that, make sure that both the media converter and the SFP module come from the same manufacturer (unless there is some guarantee of compatibility, or the cost difference is great enough that you are willing to take the gamble that it will work). Then all you have to worry about is whether the SFP has the correct connectors to match your cable, and whether it’s the correct power level for the range you are using (again, don’t get anything that’s rated for use with cables of multiple kilometers in length, unless your cable really is that long!).

After you pull the fiber cable, connecting everything up is fairly straightforward. The SFP plugs into the media converter or switch, and the fiber cable plugs into the SFP. You then simply connect the media converters to your existing network at both ends using a Cat 5e or Cat 6 patch cable. Then apply the power to the media converters at both ends (if you don’t apply the power until everything is plugged in, you can’t accidentally look into the laser!).

If you happen to get the type of media converters shown above, you may notice that there are dip switches on the unit. There are for manually setting the port speed, and full or half duplex mode. We left these in the factory default position (all up, which is indicated as “UDP/NWAY” mode) and it works fine. Another thing you might wonder is whether you can connect a computer directly to the media converter at the distant end of the connection, and of course the answer is yes, though many people will prefer to connect a switch so that multiple devices can be used. And remember, you do have the option to buy a switch that accepts one or more SFP modules directly, which may mean you won’t need the standalone media converter at that end — but before you do, check the power requirements. As mentioned above, I found that such switches tended to be a bit power-hungry compared to the standalone media converters shown above.

What about the cost?

The upfront cost of running fiber is more expensive than using Cat 5e or Cat 6 underground, although if you add in the cost of good lightning protection at both ends (or replacing equipment that gets fried by lightning if you don’t use great lightning protection) then the cost difference is less significant. Today you can get 100 meters of fiber optic cable on eBay for about $80, including USPS Priority Mail shipping. The media converters and SFPs are still the expensive items — as I write this, they are going for $127 per set (media converter and SFP) on eBay, plus shipping. Add in the price of incidentals (pipe or conduit, pulling lubricant, network pull string) and you can expect to pay around $400 or perhaps a bit more for a 100-meter run (less if you can re-use existing pipe or conduit, more if you have to pay someone to dig a trench or otherwise run the cable through a difficult place). Of course you would have these same costs when running Cat 5e or Cat 6 underground, except for the media converters, so as a rough rule of thumb the price difference is the added price of the media converters and SFPs, minus the cost of the excellent lightning protection that you won’t need because fiber optic cable doesn’t conduct electricity.

EDIT by TechNotes editor (July, 2020 and March, 2021): It has taken years for prices to drop on these units but it appears the shift toward lower prices has finally begun. Amazon now sells some fiber media converters and SPF’s at significantly lower prices, for example you can get a Gigabit Ethernet Multi-Mode LC Fiber Media Converter (SFP SX Transceiver Included), up to 550M, 10/100/1000Base-Tx to 1000Base-SX from Amazon for under $40 at the time of this edit. We have not tested this item, but think it would work in the same way as the media converter and SPF shown above. Be sure to read the reviews before buying any item, since you probably don’t want to buy units that have a tendency to fail after a few weeks or months of use. You can also now buy fiber media converters and SPF’s rated at 10 Gigabits, though as you may expect the prices for those will be higher. And also, switches that directly accept SPF’s (eliminating the need for a separate standalone Fiber Media Converter) are now starting to become more common.

And it finally looks like the price of fiber optic cable has started to fall just a bit as well, a 100 Meter Multimode Duplex Fiber Optic Cable (50/125) – LC to LC – Orange purchased from Amazon will run you just a bit under $65, and you may even be able to find better deals than that on eBay or from some other source. But as noted above, you would probably be much better off to use cable that is designated as “Outdoor Armored Duplex Fiber Optic Cable” which although a bit more expensive, should be far more resistant to damage, and will probably last longer. And even if you don’t go the armored cable route, you would do well to consider avoiding the older technology orange cable shown in this article, in favor of cable designated as OM3 or OM4, or better if available. (End of edit.)

I figure that in practice, the fiber install will cost anywhere from about the same amount to an extra $150 compared to an equivalent Cat 5e/Cat 6 install (again, we’re talking a 100-meter run here), but it will be worth it the next time you have an intense electrical storm nearby and realize that you’re probably not going to lose a lightning protector, computer, or router because of a surge coming in over the network cable. It will also be worth it if the run is long enough that every hot and humid day results in a degraded connection when using Cat 5e or Cat 6 underground.

I do expect that the use of fiber will become more common in the future, since we will want ever-faster connections and there is a theoretical maximum on connection speed using copper. At some point, I expect the prices of fiber equipment to fall (the day they start selling it in the big office supply chain stores is the day you will see the price drop to more reasonable levels). But for now, the prices aren’t that unreasonable (especially compared to a few years ago). By the way, if you want to be the next millionaire, design a system that allows people to reliably attach their own connectors to bulk fiber cable, and that sells for under $100. It’s ridiculous that anyone should have to pay four-figure sums just to be able to attach ends to fiber cable.

One other thing I think would help with fiber acceptance is to make an ultra-strong fiber cable that’s designed for difficult pulls – something with enough integral strength that you could pull the cable itself and not have to worry about breaking the glass fibers, and with a thick enough and tough enough jacket to withstand pulls over rough or uneven surfaces. Basically, fiber cable that could take a lot of abuse without breaking (not that the stuff we used is all that fragile, but still, it would be nice to not have to worry that it can be easily damaged, especially when you’re paying around sixty to seventy bucks for a 100-meter roll).

Thanks and acknowledgements

I want to thank Paul Timmins (the creator of the very useful TelcoData.us Telecommunications Database) for his help and patience in helping me understand all this stuff. This article could not have been written without his assistance. Also I want to thank my oldest son, who probably doesn’t want me to mention him by name, for his help and for letting me photograph some of the components in a recent installation.

My purpose in writing this article was to try and help de-mystify some aspects of using fiber optic cable in place of Cat 5e/6 for runs between nearby buildings. Again, I am NOT an expert in this, and I may have left some questions unanswered. If you have questions or need clarification on some point, or if you see where I’ve made a glaring error, feel free to leave a comment. If I don’t respond, it probably means that I don’t know the answer, but maybe someone else with more expertise than I will chime in and help.

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

June 24, 2009 by Admin

Important

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

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

I had mentioned in Part 3 some of the things that needed to be done if, from machines on the server side of the VPN tunnel, you wanted to be able to access machines at the client network (where the router with the Tomato firmware is located) that are on the WAN port side of the router. Bear in mind that anything connected to one of the LAN ports on the router is considered to be part of your VPN, but sometimes you might wish to access a machine or device (such as an “upstream” router) on the WAN side of the router with the Tomato firmware. To do this, you need to add the route to the WAN side network in the server configuration (in the “up” and “down-pre” script sections at the bottom of the Webmin server’s configuration page, using an additional “route add” and an additional “route delete” statement), and then on the client configuration page you must add an additional iroute statement – all of those take the same format as the lines you added to access the network on the LAN side of your client. At that point, you can access machines on the WAN port side of the Tomato router, but it’s not reciprocal – they can’t access machines on the server side.

Now, I need to make an important distinction here – I’m talking about machines connected to the WAN side of the Tomato-firmware router. Anything connected to one of that router’s LAN ports should already have full access to your network (on the server side). But the thing to remember is that ANY traffic sent out by a client connected to the LAN side will go through the tunnel. In some cases that may not be the desired behavior – you might have a few devices that should use the local Internet connection for all outgoing traffic (that is, as a rule they DON’T send their traffic through the tunnel), BUT you’d like to make an exception so that they can access only the local network on the server side of the tunnel, so that “local” traffic CAN be routed through the tunnel. So, you’d have such devices on the WAN port side of the Tomato-firmware router (that is, connected to the same “upstream” router or switch as the Tomato-firmware router) so they don’t use your tunnel for the bulk of their traffic.

So the question then becomes, is it possible to allow those devices to use your tunnel ONLY for traffic to the local network on the server side of your tunnel? Well, it is, but it’s a bit tricky to set up. Note that you MUST first have it working in the opposite direction (that is, at a machine connected to the server side of the network, you can reach machines on the WAN port side of your Tomato-firmware router – that’s what I was talking about a couple of paragraphs up). If you can’t do that, you’re not going to get it working in the opposite direction. If you CAN do that, then here are the additional steps:

In the Tomato-firmware router, click on “Advanced” (in the left-hand menu), then “Firewall”, then check the box next to “Respond to ICMP ping.” You should now be able to ping the Tomato-firmware router from another device on the WAN side of the network (which may be important for testing and troubleshooting).

Next, click on “Administration”, then “Scripts”, then click the “Firewall” tab. You should see a big text entry box with (probably) nothing in it. Enter lines similar to the following:

iptables -t nat -I PREROUTING -s 192.168.10.0/24 -d 192.168.0.0/24 -j ACCEPT iptables -t filter -A wanin -s 192.168.10.0/24 -d 192.168.0.0/24 -j ACCEPT iptables -t filter -A wanout -s 192.168.0.0/24 -d 192.168.10.0/24 -j ACCEPT

In this example, addresses on the WAN port side of the Tomato-firmware router are in the 192.168.10.x range, while addresses on the server-side LAN are in the 192.168.0.x range. If either is different on your system, be sure to change all three instances of the appropriate base address.

Then click the Save button at the bottom of the page. After that it should look like this:

Administration | Scripts page | Firewall tab

Reboot the router (or you can ssh in and manually enter each of the lines from a command prompt, if you want to avoid the reboot). Now any traffic for the server-side LAN that reaches the Tomato-firmware router will get passed through the tunnel, but you still need to instruct the individual machines or devices to route that traffic correctly (which may be easier said than done for some machines). I don’t know how you do it from a Windows box, but I can tell you how it’s done on a temporary basis (that is, it survives until the next reboot) on a Linux-based or Mac OS X based machine. For the sake of these examples, assume the Tomato router is at (and can be pinged at) 192.168.10.50:

From a Linux box:
sudo route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.10.50 eth0
(eth0 is the name of the interface used to connect to your local network)

From a Mac OS X box:
At a terminal prompt enter:
sudo route add -net 192.168.0.0 -netmask 255.255.255.0 192.168.10.50
Then, if there are shares on server side of the network that you want to connect to, and you know the host machine’s IP address, open a Finder window, click on “Go” in the top menu bar, and enter this as the destination (substituting the correct IP address for the target machine):
smb://192.168.0.xx:139
Note that in at least some cases, the connect attempt will fail if you don’t explicitly specify the port (:139) – this is apparently some kind of bug in recent versions of OS X.

If anyone knows how this is done on a Windows box, or how to make these route statements persist after a reboot (remember, they must be run by the root user or a user with root-level privileges, which is why the sudo statement is used — and you can’t put sudo in a script because it prompts for a password), please leave a comment and share your knowledge!

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 – Amazon affiliate link)

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

EDIT: Create a VPN with the Raspberry Pi

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.

EDIT (November 30, 2011): While I’m not really wanting to reopen this project at this late date (this still remains about the hardest thing I’ve ever tried to do with a computer, and I have a distinct aversion to revisiting it), I did receive an e-mail today from James R, which I will post verbatim here. NOTE THAT THIS IS NOT TESTED BY ME, SO USE AT YOUR OWN RISK:

From: James R (address redacted)
Subject: OpenVPN in bridged mode
Date: November 30, 2011 11:32:40 AM EST

The following is a script to fix the problems with getting bridged mode OpenVPN working with PBX in a Flash (CentOS 5.7 with Webmin). First you install the third party Webmin OpenVPN module, then use the script below. I haven’t tested it yet, but I believe it should work if not explain what actions needed to be done to repair it. Be kind, as my scripting skills are quite poor.

#! /bin/bash


wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm

sleep 30

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

sleep 1

rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm

sleep 1

rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm

sleep 1

yum -y install bridge-utils

sleep 30

yum -y install tunctl

sleep 30

yum -y install openvpn

sleep 60
echo "start_cmd=/etc/init.d/openvpn start

openvpn_pid_path=/var/run

openvpn_servers_subdir=servers

zip_cmd=/usr/bin/zip

stop_cmd=/etc/init.d/openvpn stop

openvpn_path=/usr/sbin/openvpn

openvpn_clients_subdir=clients

log_lines=200

openvpn_version=2.0_rc16

openvpn_keys_subdir=keys

openvpn_home=/etc/openvpn

openssl_version=0.9.7e

openssl_path=/usr/bin/openssl

openssl_home=/etc/openvpn/openvpn-ssl.cnf

down_root_plugin=/usr/share/openvpn/plugin/lib/openvpn-down-root.so

br_end_cmd=/usr/libexec/webmin/openvpn/br_scripts/bridge_end

br_start_cmd=/usr/libexec/webmin/openvpn/br_scripts/bridge_start

tail_cmd=

log_refresh=

default_server=

" > /etc/webmin/openvpn/config
cat /usr/libexec/webmin/openvpn/br_scripts/bridge_start | sed

'2iPATH=$PATH:/sbin:/usr/sbin' >

/usr/libexec/webmin/openvpn/br_scripts/bridge_start

cat /usr/libexec/webmin/openvpn/br_scripts/bridge_end | sed '2iPATH=$PATH:/sbin:/usr/sbin' > /usr/libexec/webmin/openvpn/br_scripts/bridge_end

(End of James R’s e-mail. I fixed some punctuation and capitalization in the first paragraph, but otherwise it’s the way he sent it. I was NOT sure if the final couple of sections were really supposed to be three lines each, or one line each that got broken up by the e-mail software. I suspect the latter, but I’m leaving them as is in case I’m wrong about that. Again, please remember that the above is UNTESTED by me.)

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!

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

June 22, 2009 by Admin

Important

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 (Amazon affiliate link) 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.

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

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:

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:

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:

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:

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:

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:

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

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:

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:

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.

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

June 22, 2009 by Admin

Important

Continued from Part 1…

EDIT (Jaunary 2011): Since I originally wrote this article in 2009, a new project has appeared called Easy OpenVPN, which is described as “a collection of bash scripts which will install and configure the Open VPN software on your PBXIAF server. Also includes scripts for creating client certificate files.” The project’s page further notes that these scripts are compatible with the security models used in, and have been tested with PBX In A Flash and Elastix, and that they may be compatible with other PBX distributions, but have not been formally tested. It also notes that the scripts do not interact directly with Asterisk or FreePBX. I have NOT tested these scripts, but it sounds as if it they might work on just about any CentOS-based OS. Certainly, if you are using one of those distributions, it’s worth looking into — it might be a faster and easier way to set up OpenVPN on your server than the procedure I outline here. Some instructions can be found in this thread. Even if you go that route, you might still want to read the rest of this series, since it gives some explanations and usage tips that may come in handy if the scripts don’t configure OpenVPN the way you’d like. FURTHER EDIT: If you want a dedicated OpenVPN server, check this out: Create a VPN with the Raspberry Pi (from Linux User & Developer).

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). Older versions of OpenVPN will not work with these instructions. Just type openvpn from a command prompt and at the top of the resulting output it should show you what version you have, if it is installed. It will look something like this:

OpenVPN 2.2.0 i686-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Jun 6 2011

2.2.0 is the version in this example. But on a recent CentOS install, just doing yum install openvpn only offered to install version 2.0.9, which is too old to work with these instructions! Here is how I installed a newer version (edited July 27, 2011 to reflect a better way):

Add the dag repository if you haven’t done so already. In the /etc/yum.repos.d directory, create a new file called dag.repo:

touch /etc/yum.repos.d/dag.repo

Edit the file using any text editor (for example, nano /etc/yum.repos.d/dag.repo) and add the following lines exactly as shown:

[dag]
name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1

Save the edited file and then from a command prompt import the repository’s key:

rpm –import http://apt.sw.be/RPM-GPG-KEY.dag.txt

Now if you do

yum install openvpn

You should get the latest version plus any dependencies (it should offer to upgrade your current version if it is older). 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: 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.” If their suggested download method doesn’t work, use the download link on this page to download it to your local machine, then in Webmin install the module “From uploaded file” rather than “From ftp or http URL” as the article suggests. 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. EDIT: See Leon Baker’s comment in the comments section below for a fix for this problem. Thanks, Leon!

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!!!

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

June 22, 2009 by Admin

Important

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Settings portion of Basic | Network page

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

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

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

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

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

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

keepalive 10 120
float

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

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

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

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

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

Administration | Scripts page | WAN Up tab

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

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

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

route add -host 192.168.100.1 gw `nvram get wan_gateway`

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

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

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

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

June 16, 2009 by Admin

Important

Cover of OpenVPN: Building and Integrating Virtual Private Networks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mini-review of Asterisk Gateway Interface 1.4 and 1.6 Programming

April 8, 2009 by Admin

Important

This was originally posted in April, 2009.

I am NOT currently a PHP coder, so it’s a bit difficult for me to comment on this book. Not that the book is exclusively for PHP coders, but virtually all the examples are in PHP, so if you really want to understand what’s going on, you probably have to know at least some PHP.

So before I continue, let me run Packt Publishing’s little blub, to get the cover photo and linking out of the way:

Asterisk Gateway Interface 1.4 and 1.6 Programming

Design and develop Asterisk-based VoIP telephony platforms and services using PHP and PHPAGI

Develop voice-enabled applications utilizing the collective power of Asterisk, PHP, and the PHPAGI class library
Learn basic elements of a FastAGI server utilizing PHP and PHPAGI
Develop new Voice 2.0 mesh-ups using the Asterisk Manager
Add Asterisk application development skills to your development arsenal, enriching your market offering and experience
Up to date for Asterisk version 1.6 and covers all previous versions

http://www.packtpub.com/asterisk-gateway-interface-programming/book

Okay, that’s the publisher’s word on the book. Now here’s my take: The one thing I thought was not right about this book was how many pages you have to go through before you get to what is supposed to be the book’s subject. The first chapter is about Installing a ‘Vanilla’ Asterisk. Now really, if someone is contemplating the purchase of this book, don’t you think it’s likely that they have Asterisk (in some form) already installed?

The second chapter is on Basic IVR Development: Using the Asterisk DialPlan and while I suppose this chapter is somewhat useful in laying the groundwork for what is to come, by the time you are through with it you are already up to page 53. And then comes the next chapter: More IVR Development: Input, Recordings, and Call Control. And that chapter ends on page 73. This is a problem because the last regular page of the book, at the end of Chapter 10, is page 191 – which basically means that nearly half the book is devoted to installing Asterisk from scratch, and then creating an IVR the old-fashioned way (if I want an IVR I’ll create it in FreePBX, thank you very much). And there is virtually nothing about AGI programming in those initial three chapters.

Finally, in Chapter 4, starting on page 75, we get into A Primer to AGI: Asterisk Gateway Interface – and this is where the book hits its stride and keeps on going. If you know PHP but know next to nothing about Asterisk AGI programming, this book will teach you the basics of what you need to know to start writing AGI code – but perhaps just as important, it will teach you good coding practices. It explains when you should try to put code in the Asterisk DialPlan as opposed to putting it in an AGI script. It explains why certain languages are much better than others when you are writing an AGI script. And it will teach you the fundamental rationale behind AGI scripts – if you are a seldom-coder like me, you probably think that calling an AGI script is simply calling a bit of code written in some other programming language. Nothing could be further from the truth.

AGI scripts are actually quite a bit more powerful than many Asterisk users realize – I think that theoretically you could do most of your Asterisk programming from inside an AGI script, but that doesn’t mean you should. One of the things that the AGI shines at is obtaining data that’s not normally available to Asterisk – for example, information from a local or remote database, or even from a FTP server or web-based service. You’ve seen web-based “click to call” services like Jajah? That’s basically obtaining data from a web server so that Asterisk can initiate a callback, and this book shows you how something like that is set up.

I’ve heard it said that in many books there is one chapter that epitomizes the entire volume. In this case, there are about five chapters that are the heart of the book, but you will learn a great deal in those five chapters. Even without knowing a lick of PHP, I came away with a greater understanding of what AGI scripts are, and when and how they should be used. Had I actually been able to understand the PHP examples, I think I’d have had a much greater appreciation for the book. The author definitely knows his subject; and perhaps that’s why once he gets into it you feel like you’re getting solid information.

So I guess I would say this: If you judge the value of a book solely on page count, and you don’t need to know how to install Asterisk from scratch or set up an IVR, then you may feel a bit disappointed by this book (if that’s really the case, do yourself a favor and skip the first three chapters). But if you judge a text on how quickly it can bring you up to speed on a subject, and you want to learn Asterisk AGI programming, I think you’ll like it. Since the book relies so heavily on PHP, I think the first three chapters might have been better spent on an introduction to PHP – if the author would have covered that as well as he covers the Asterisk Gateway Interface, I’m sure I would have had a greater appreciation of this volume.

One other thing I noted is that this book seems to be very current – It’s not talking about Asterisk as it was two years ago. It was first published in January, 2009. That’s important when you are looking for information related to Asterisk, which can change quite a bit in a couple of years.

Asterisk Gateway Interface 1.4 and 1.6 Programming (Amazon affiliate link) by Nir Simionovich
Chapter List:

Table of Contents
Preface
Chapter 1: Installing a ‘Vanilla’ Asterisk
Chapter 2: Basic IVR Development: Using the Asterisk DialPlan
Chapter 3: More IVR Development: Input, Recordings, and Call Control
Chapter 4: A Primer to AGI: Asterisk Gateway Interface
Chapter 5: AGI Scripting with PHP
Chapter 6: PHPAGI: An AGI Class Library in PHP
Chapter 7: FastAGI: AGI as a TCP Server
Chapter 8: AMI: The Asterisk Manager Interface
Chapter 9: Final Programming Project
Chapter 10: Scaling Asterisk Applications
Index

Or if you’d like to see a complete Table of Contents with subheadings, in outline form, go here.

Author Nir Simionovich’s blog

Author: Admin

Some notes on creating a home theater PC using the Acer Aspire Revo

Like this:

Review of Building Enterprise Ready Telephony Systems with sipXecs 4.0 by Michael W. Picher (Packt Publishing)

Like this:

Review of FreePBX 2.5 Powerful Telephony Solutions by Alex Robar (Packt Publishing)

Like this:

How to use fiber optic cable for short runs between buildings (and why you should)

Like this:

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

Like this:

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

Like this:

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

Like this:

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

Like this:

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

Like this:

Mini-review of Asterisk Gateway Interface 1.4 and 1.6 Programming

Like this:

Recent Posts

Recent Comments

Archives

Categories

Meta